منطق قاعدة العمل مع التحكم في المصدر في Localhost + Mercurial

Question

أنا جديد جدا في Mercurial - فعلا جديد في التحكم في المصدر.

لدي مشاريع في المحلي، وهو ~ / MAMP / HTDocs. أريد أن أعمل كل المحلية. هناك نقطة أنا مرتبك حول:

يجب أن أبقى مستودع في مسار مختلف من HTDocs وأعتقد، لذلك قمت بإنشاء مجلد "/ reps /" وإنشاء مجلدات لكل مشروع تحت هنا، ونسخ جميع الملفات من مجلد مشروع HTDocs إلى REPS.

علي سبيل المثال؛ Project01.

نسخ الملفات من ~/mamp/htdocs/project01/ ل /reps/project01/

لكنني أعمل في LocalHost (HTDocs) لتغيير الملفات، إلخ. فكيف يمكنني ربط هذه التغييرات /reps/?

من الواضح أنني أفتقد بعض النقطة الواضحة للغاية حول التحكم المصدر. هل صنعت بداية خاطئة؟

جميع البرامج التعليمية التي وجدتها عبر الإنترنت تتطلب نوعا من المعرفة الأساسية، أعتقد؛ لا أحد منهم يروي أي شيء من معنى صفر نقطة! : /

Answer 1

أبسط طريقة، إذا كنت ترغب في تعديل ملفاتك في ~/mamp/htdocs/project01/ (لأنني أوافق أيضا على أنه سيكون من الجيد أن يكون لديك نوع من منطقة التدريج حيث يمكنك اختبار التغييرات الخاصة بك قبل نشرها على خادم الإنتاج، ولكن ربما يكون جهازك بدقة منطقة التدريج، لذلك كل شيء على ما يرام بعد ذلك: - )) هو:

1. تثبيت mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (كل ما تريد إدارته)
5. hg commit -m"initial version"

بعد أن فعلت hg init, ، هناك مستودع في .hg دير تحت ~/mamp/htdocs/project01/ في لا يمكن تجنب هذا (حتى الآن على الأقل) مع HG: إذا كان لديك مصادر في Project01، فأنت بحاجة إلى الحصول على Repo في Project01. وهذا كاف لأنه يمكنك الاستفادة من عنصر تحكم الإصدار مع ذلك، كلما قمت بتغيير ملف، يمكنك إلزامه وإعطاء رسالة سجل لإخبار النظام بما قمت به، على سبيل المثال،

• <edit> a.html
• hg status (سيخبرك بالملفات المعدلة حاليا)
• hg diff (سوف اقول لك الاختلافات مع الإصدار المحفوظ)
• hg commit -m"what-has-changed-message" (حفظ نسخة جديدة)

حتى لو لم يكن من الضروري الحصول على ريبو آخر في مكان آخر (على سبيل المثال، في / ممثلون) إذا كنت اريد ان, ، على سبيل المثال أن تكون بياناتك في منطقة احتياطية، يمكنك فقط استنساخ واحد في $ الصفحة الرئيسية:

• cd /reps
• hg clone /home/name/mamp/htdocs/project01/ project01

والتي سوف تحصل في /reps/project01 نسخة محددة من ما قمت به: جميع التغييرات وجميع رسائل السجل الخاصة بك. الآن إذا قمت بذلك، كلما قمت بذلك "hg commit" لحفظ تغيير في ريبو الأساسي الخاص بك، تحتاج أيضا إلى القيام به "cd /reps/project01" و "hg pull" من أجل إعادة توجيه التغييرات في / ممثلين إذا كنت تريد أن تبقى متزامنة.

آمل أن يكون بسيط بما فيه الكفاية ..

Answer 2

هناك العديد من الأساليب / الأساليب المختلفة. وبعد إليك كيف أعمل:

1. التطور: أتحقق (استنساخ في حالة Mercurials) من ملفاتي إلى "بيئة التنمية" الخاصة بي للعمل عليها ثم ارتكب / دفع / إلخ. في نفس المكان.

2. المراحل التالية: بمجرد أن أعتقد أنها جاهزة للاختبار / الإنتاج / الإنتاج / أو مهما كانت المرحلة التالية، فيمكنك إما توزيع التعليمات البرمجية الخاصة بك ك

   2a. الحزمة (يمكن أن تكون مضغوط بسيط من أحدث ملفاتك) أو

   2b. تحقق منها في دليل المرحلة التالية.

3. ترسيمات أخرى: بمجرد أن تكون مرتاحا للعمل مع سيناريوهات الاستخدام الرئيسية، يجب عليك التفكير في الآخرين مراجعة التحكم في المراجعة مثل وضع علامات, المتفرعة و دمج

Answer 3

يجب أن تبقي عادة VCS (نظام التحكم الإصدار) الخاص بك (نظام التحكم الإصدار) وملفاته منفصلة عن بيئة خادم الإنتاج الخاصة بك (وهو ما أطلب منك أن تسأل عن ذكر ذكر HTDocs).

لدى العديد من أنظمة الويب (على الأقل من الوقت القديم) منطقة انطلاق حيث يمكنك نسخ المواد من النظام المصدر، والتي يمكنك التحقق بعناية باستخدام خادم ويب آخر (غير قابل للوصول علنا). عندما تكون واثقا من أن الرمز صحيح، يمكنك نقله إلى الإنتاج.

هذا السيناريو لديه ثلاثة مجالات:

• منطقة العمل (التطوير) مع VCS، إلخ؛ ربما يمكن الوصول إليها عبر خادم ويب آخر).
• منطقة التدريج (لا VCS، لا وصول عام؛ اختبار والتحقق من الصحة).
• منطقة الإنتاج (لا VCS، وصول الجمهور).

يبدو قليلا كما لو كنت تخلط بين هذه الثلاثة - سيناريو شائع في تجربتي المحدودة. حتى إذا قررت الاستغناء عن منطقة التدريج، فأنت بحاجة إلى فصل أنظمة التطوير والإنتاج. وتستخدم VCS (Mercurial) في منطقة العمل.