GIT Workflow للحفاظ على تحديث البرامج المصدر المفتوحة المعدلة حسب الطلب؟

Question

توفر جامعتنا استضافة الويب إلى أقسام الحرم الجامعي على الخوادم التي نديرها. يتطلب تثبيت برامج الطرف الثالث مفتوح المصدر تعديل أذونات الملفات والرمز في البرنامج قبل تشغيله. (نحن نستخدم Suexec ، إذا كنت مألوفًا.)

نقدم حاليًا WordPress عبر برنامج نصي للتثبيت. يقوم المستخدم بتحميل أحدث إصدار مستقر ، ويقوم بتشغيل برنامج نصي PHP من جانب الخادم عبر SSH. يعدل هذا البرنامج النصي PHP أذونات الملفات لجميع الملفات/المجلدات ، يضيف/يزيل بعض التعليمات البرمجية في مختلف الملفات ، ويقوم بإنشاء بعض الملفات الجديدة. هذا البرنامج النصي المثبت هو فعل موازنة مرهقة عند إصدار نسخة مستقرة جديدة.

أريد أن أبدأ في استخدام التحكم في الإصدار (على وجه التحديد GIT) لتتبع التغييرات المخصصة لدينا بدلاً من الاعتماد على البرنامج النصي لإجراء التغييرات ، لكنني غير متأكد من سير العمل. أنا على دراية بالتفرع والاندماج ، لكن لست متأكدًا من كيفية دمج تغييراتنا القديمة عند إصدار إصدار جديد.

ما الذي يجب أن يكون سير عمل GIT الخاص بي هو دمج التغييرات الجديدة من WordPress Core ، ولكن أيضًا الحفاظ على تغييراتنا المخصصة القديمة؟

Answer 1

أود أن أقترح الحفاظ على تغييراتك في فرع ، وإعادة صياغة هذا الفرع ضد الأحدث من WordPress كلما قمت بتحديث. في جدول زمني تقريبي ...

              +-- WordPress 1.0
              v
[master] --*--*
               \
[custom]        *--*--*     <- your customizations

عندما ترغب في تحديث WordPress ، قم بالتبديل إلى Master وقم التزامًا جديدًا بأحدث Souce (أو استخدم GIT-SVN للحفاظ على Master في المزامنة):

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
               \
[custom]        *--*--*     <- your customizations

الآن يمكنك أن تفعل git rebase master custom لإعادة تغيير التغييرات الخاصة بك ضد آخر ، حل أي صراعات على طول الطريق. سيبدو الجدول الزمني الخاص بك هكذا:

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
                     \
[custom]              *--*--*     <- your customizations

تحديث: لتوفير القليل من الأساس المنطقي ... أحب هذا النهج لهذا المشكلة لأنه يوفر تمايزًا واضحًا بين الكود من WordPress وتخصيصاتك. عندما تحصل على إصدار جديد من WordPress ، فأنت لست مهتمًا حقًا بـ "التكامل". أنت مهتم بإعادة تخصيصك على الإصدار الجديد من WordPress. من وجهة نظري ، يتم بسهولة القيام بهذا التكرار من خلال الالتزام من خلال Rebase. أي تعارضات تعني أن التخصيص قد اندلع على الأرجح ، وبالتالي فإن التزام التخصيص القديم هو القمامة على أي حال - من الأفضل إصلاح المشكلة في مصدرها والحفاظ على نظافة التاريخ المحدث.

بعد، بعدما master تم تحديثه و custom يتم إعادة صياغته ودفعه ، فإن المتعاونين سيقومون بإعادة صياغة عملهم في المقدمة ضد الأحدث.

هذا هو رأيي فقط ، باعتباره شركة Rebase> دمج المؤيد. جمال Git هو أن هناك إجابة واحدة صحيحة. فقط استمر في ضبط حتى تجد شيئًا يناسبك.

Answer 2

النهج العام هو أن يكون له فرعين ، upstream و master. قم بإنشاء مستودعك (الذي سيبدأ بك في master فرع) ، تحقق في أحدث نسخة من رمز المنبع الذي تستخدمه ، ثم إنشاء ملف upsteram فرع مع git branch upstream. أيضًا ، قم بإنشاء علامة تشير إلى إصدار المنبع الذي قمت باستيراده ، مثل git tag wordpress-1.0. عادةً ما أستخدم علامات خفيفة الوزن لهذا (تلك دون أي تعليقات توضيحية ، بل مجرد مؤشر لمراجعة).

[wordpress-1.0]               Key: [tag]
v                                  branch
* <- upstream                      * commit
^- master 

الآن ، بينما لا تزال في master فرع ، انسخ التغييرات الخاصة بك وتحقق منها. لديك الآن فرعين ، upstream الذي يحتوي على مصدر البكر في المنبع ، و master الذي يحتوي على التغييرات الخاصة بك ، مع تاريخ يظهر التغييرات التي أجريتها عليها upstream.

[wordpress-1.0]
v
* <- upstream
 \
  +--* <- master 

اجعل كل تعديلاتك في master فرع.

[wordpress-1.0]
v
* <- upstream
 \
  +--*--*--* <- master 

عندما يأتي إصدار جديد من رمز المنبع ، تحقق من upstream فرع (git checkout upstream) ، امسح كل شيء ما عدا .git الدليل ، ونسخ في إصدار المنبع الجديد. يستخدم git add -A لتنظيم جميع التغييرات في النسخة المنبع ، ارتكبها ، ووضع علامة عليها.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--* <- upstream
 \
  +--*--*--* <- master 

الآن ، تحقق من master, ، ودمج في تغييرات المنبع. في هذه المرحلة ، يمكنك اختيار كيفية الاندماج ، مثل أخذ إصدار المنبع الجديد ، أو أخذ نسختك ، أو أخذ تغييرات مدمجة ، تمامًا كما تفعل في دمج عادي.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--*--------+ <- upstream
 \           \
  +--*--*--*--* <- master 

لذلك ، تحدث جميع التغييرات الخاصة بك master, ، وترتكب جميع إصدارات المنبع تمامًا كما هي upstream. سيتيح لك ذلك رؤية أكثر بسهولة كيف يختلف التعليمات البرمجية الخاصة بك عن إصدار المنبع ، وسيساعد ذلك على تتبع التغييرات التي قمت بالفعل بدمجها مع إصدار المنبع ، وما إلى ذلك.

[wordpress-1.0]
|  [wordpress-1.1]
|  |           [wordpress-2.0]
v  v           v
*--*--------+--*-+ <- upstream
 \           \    \ 
  +--*--*--*--*----*--* <- master 

آمل أن يساعد هذا ، اسمحوا لي أن أعرف إذا كان لديك أي أسئلة أخرى.