نشر اضافة ووردبريس مع جيت

إذا كان لديك مكون إضافي مستضاف في مستودع WordPress ، فستكون على دراية بـ SVN وبعض أوامره. في هذا البرنامج التعليمي ، سأوضح لك كيف يمكنك استخدام Git ، وهو نظام آخر للتحكم في الإصدارات شاعته GitHub ، لنشر المكوّن الإضافي والمحافظة عليه.

ما هو جيت؟

Git و SVN هما مثالان على أنظمة التحكم في الإصدارات. يستخدم مستودع ووردبريس هذا الأخير (إذا كان لديك برنامج إضافي مستضاف على WordPress فستصبح على دراية بـ "تسجيل الوصول" لإجراء تغييرات على هذا المستودع).  كلاهما يسمح لك بتتبع التغييرات في شفرتك ، لكن هناك اختلافات كبيرة بينهما حول كيفية القيام بذلك.

يعتمد SVN على "مستودع مركزي" واحد من الكود (في سياقنا: مستودع المكونات الإضافية لـ WordPress). في كل مرة تريد فيها تحرير المكون الإضافي ، تحتاج إلى عمل نسخة محلية ، وإجراء التغييرات ، ثم "إيداع" هذه التغييرات في مستودع WordPress.

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

في هذا البرنامج التعليمي ، أفترض أن لديك برنامجًا إضافيًا مستضافًا في مستودع WordPress plug-in ، أو على الأقل قد تمت الموافقة على طلب الاستضافة الخاص بك. إذا لم تكن متأكدًا من كيفية الحصول على المكون الإضافي الذي تستضيفه WordPress ، أقترح عليك قراءة مقالتنا حول كيفية النشر إلى مخزن WordPress .

ما هي مزايا استخدام Git Over SVN؟

هناك العديد من الحجج المؤيدة والمعارضة باستخدام Git عبر SVN (بالإضافة إلى أنظمة التحكم في النسخ اللامركزية بشكل عام). العديد من هذه تنبع من الطرق المختلفة بشكل أساسي Git و SVN. يمكن العثور على تحليل معمق ممتاز لـ Git و SVN في مقالة Git vs SVN CodeForest ، لكن بالنسبة إلى مطور WordPress:

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

أحد عيوب استخدام Git ، هو الحصول عليه للعب بشكل جيد مع مستودع SVN. ليس من الصعب في الواقع ذلك بفضل git svn ، وهذه المقالة هنا لإرشادك من خلالها.

الخطوة 1 تنزيل Git

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

الخطوة 2 استنساخ المستودع المستضاف في WordPress

كما ذكرنا سابقًا ، مع Git ، لا تقوم بـ "سحب" نسخة من البرنامج الإضافي - يمكنك استنساخ المستودع ، مع استكمال تاريخ التغييرات التي تم إجراؤها ، وكل فروعها وعلاماتها. الخطوة 1 هي استنساخ المستودع المستضاف في WordPress. على سبيل المثال ، سأكون بصدد نشر رابط "Post Type Archives Link" استنادًا إلى برنامج تعليمي سابق. لذلك (بمجرد قبولك في مستودع WordPress) افتح واجهة سطر الأوامر ، وانتقل إلى المكان الذي تريد تخزين الإصدار المحلي من المكون الإضافي فيه. سأضعه داخل مجلد يسمى " المكونات الإضافية ". مرة واحدة هناك نريد أن نقول Git أين تجد المكون الإضافي لدينا. في وقت الكتابة ، هناك ما يقرب من 20000 مكون إضافي مستضافة في مستودع WordPress ، وأكثر من 500000 مراجعات. لا نريد أن ننتظر أن تقوم شركة Git بالبحث في كل من هذه الأدوات للعثور على المكون الإضافي لدينا. أولاً وقبل كل شيء ، نجد ما هي المراجعات التي يبدأ بها المكون الإضافي (نريده أن يكون السجل بأكمله). للقيام بذلك ، نحصل على السجل الأول للمكوّن الإضافي (عندما تمت إضافته في الأصل إلى المستودع):

1

2

svn log -r 1:HEAD --limit 1 http://plugins.svn.wordpress.org/your-plug-in-name

سوف يفكر لفترة من الوقت وبعد ذلك يجب أن نرى شيئا من هذا القبيل:

1

2

r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (Mon, 19 Mar 2012) | 1 line

هذا الرقم الأول ، "520657" للمكوّن الإضافي ، هو المراجعة الأولى. سنستخدمها في الأمر التالي الذي يخبر Git بنسخ سجل المكونات الإضافية. استبدل XXXXXX برقم المراجعة الخاص بك.

1

2

git svn clone -s -rXXXXXX --no-minimize-url http://plugins.svn.wordpress.org/your-plug-in-name

3

cd your-plugin-name

4

git svn fetch

5

git svn rebase

تشير " -s " إلى Git لتوقع تخطيط (Tag، Trunk، Branches) القياسي لمستودع SVN. يتوقف " --no-minimize-url " عن البحث خارج مجلد المكون الإضافي. تأكد من أنها ليست مفقودة . إذا تركته خارجًا ، فقد ينتهي بك الأمر إلى نسخ مخزن WordPress الإضافي بأكمله. يوضح -r- Git ما هي النسخة التي تريد البحث عنها. إذا تركت ذلك ، فسيبحث Git في سجل المحفوظات بأكمله. هذا أكثر من 500000 مراجعات. تركت هذا مرة واحدة واستغرق الأمر حوالي ساعتين. مع ذلك ، يجب أن يستغرق الأمر بضع دقائق فقط.

بمجرد الانتهاء من ذلك ، يجب أن تجد أنه أنشأ مجلدًا باسم " plug-in-name " داخل مجلد "Plugins". دعونا نستكشف قليلا. انتقل إلى مجلد " plug-in-name " وشغِّل أمرًا لمعرفة "الفروع" الموجودة:

1

2

git branch -a

هذا سوف يسرد جميع الفروع المحلية والبعيدة. يجب أن يكون الفرع المحلي الوحيد هو Master (تشير العلامة النجمية إلى أن هذا الفرع هو الفرع الذي تستخدمه).  الفرع الآخر (فروع) هي 'الجذع' ، وإذا كان لديك أي فرع لكل علامة (SVN يعامل العلامات كأغصان ، ولكن Git هو أذكى قليلاً من ذلك).

عند الانتقال إلى "المجلد المحلي" ، أو " المكونات الإضافية / اسم المكون الإضافي " ، يجب أن تشاهد ملفات المكونات الإضافية (في حالة وجود أي منها). قبل إنشاء أو تعديل أي ملفات هناك ، سنقوم بإنشاء فرع منفصل للعمل عليه.

يعكس الرمز أعلاه الآن 

الخطوة 3 (اختياري) اضغط على GitHub

إحدى فوائد استخدام Git هي أنه يمكنك بسهولة الاحتفاظ بنسخة من المكون الإضافي على GitHub.  هذا يجعل المكون الإضافي الخاص بك أكثر سهولة للوصول إلى المطورين الآخرين ، الذين قد يقترحون تحسينات أو حتى إجراء تعديلاتهم الخاصة التي يمكنك سحبها إلى المستودع الخاص بك. إذا تم إعدادك بالفعل باستخدام GitHub ، فقد ترغب في هذه المرحلة في دفع مكونك الإضافي إلى حسابك. للقيام بذلك ، قم أولاً بإنشاء مستودع تخزين جديد على حساب GitHub الخاص بك ، ثم قم بإضافة هذا الفرع إلى فرع بعيد إلى المستودع المحلي الخاص بك:

1

2

git remote add origin git@github.com:<your-user-name>/<your-repo-name>.git

" المستخدم الخاص بك اسم 'يشير إلى اسم المستخدم الخاص بك جيثب و" الخاص بك الريبو اسم ' يشير إلى اسم المستودع قمت بإنشائها على جيثب. ثم عليك فقط دفع المستودع المحلي الخاص بك:

1

2

git push origin master

الخطوة 4 تحرير المكون الإضافي الخاص بك: مخطط تفصيلي لسير العمل

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

في الواقع ، من الجيد إنشاء فرع لكل ميزة جديدة تضيفها إلى المكون الإضافي. عند الانتهاء ، يمكنك دمجها مرة أخرى في الفرع الرئيسي. إذا تسبب هذا في أي "تعارضات" ، سيُطلب منك حل هذه المشكلات يدويًا.

أولاً إنشاء فرع يسمى "العمل":

1

2

git branch work

ثم "تحقق" (اذهب إلى) فرع "العمل":

1

2

git checkout work

ستخبرك رسالة بأنك انتقلت إلى فرع "العمل". استخدم الآن محرر النصوص المفضل لديك لفتح ملفات المكوّن الإضافي في مجلدك المحلي (أو أنشئها إذا لم تكن موجودة بعد). وبمجرد قيامك بضع مرات ، قد ترغب في معرفة الملفات التي قمت بتغييرها. تفعل هذا باستخدام الأمر البسيط:

1

2

git status

وهذه القائمة التغيرات في تعقب و لا يمكن تقفي أثرها الملفات. قد تكون هناك ملفات لا تريد أن تزعجها Git (مثل الملفات المؤقتة) ، ولكن إذا أضفت أي ملفات جديدة إلى المجلد ، فستحتاج إلى إخبار Git لتتبعها. يمكنك القيام بذلك باستخدام الأمر:

1

2

git add <file-name>

لقد قمت بإنشاء ملفين " post-type-archive-links.php " و " metabox.js " في المجلد المحلي الخاص بي ، لذا قمت بإضافتها لإخبار Git لتتبعها. يجب عليك التأكد من أنك تتبع ملف القراءة الخاصة بك .

يمكنك أيضًا عرض التغييرات منذ ارتكابك الأخير (هذا هو المكان الذي يصبح فيه برنامج GUI في المتناول)

1

2

git diff

بمجرد ما تريد الالتزام بالتغييرات في المستودع المحلي الخاص بك:

1

2

git commit -a -m "Did abc to xyz"

تقديم رسالة ( مفصلة ) للتغييرات الواردة في الالتزام.

في عملية إجراء التغييرات ، يمكنك (ويجب) أن تلتزم بأكبر عدد ممكن من المرات - ولكن بطريقة منطقية ، ويفضل أن يكون هناك التزام واحد لكل "شيء" تقوم به. يجب عليك التأكد من عدم وجود أخطاء واضحة في التزاماتك أيضًا. "التراجع عن الالتزام" سريع وغير مؤلم: يمكنك القيام بذلك عن طريق تنفيذ التزام آخر يعكس الالتزام السابق:

1

2

git revert HEAD

(ستتم مطالبتك برسالة تصف هذا الالتزام.)

الخطوة الخامسة الالتزام بمستودع WordPress

لنفترض أنك الآن في وضع تريد فيه دفع كل التغييرات إلى مستودع SVN. قبل القيام بذلك ، نحن بحاجة إلى أن نضع شيئًا في الاعتبار. Git يشجعك على الالتزام في كثير من الأحيان ، ومن الممارسات الجيدة أن تفعل ذلك ... من أجل التنمية . ومع ذلك ، يوجد مستودع plug-in الخاص بك للتوزيع . انها لا تحتاج الى كل التزام واحد. في الحقيقة ، إنها لاتريد ذلك ، كما يحذر أوتو (المساهم الأساسي في WordPress):

"إذا قبضتك عليه [دفع كل التزام على حدة] ، فحينئذٍ سأحظرك من WordPress.org. يحتاج SVN إلى نسخة العمل النهائية الخاصة بك فقط ، وليس التاريخ الكامل لمئات التغييرات التي أجريتها باستخدام Git. قم بتسوية التغييرات الخاصة بك إلى التزام واحد. "

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

أولاً ، نريد العودة إلى الفرع الرئيسي:

1

2

git checkout master

ثم قم بدمج تغييرات فرع العمل في الشريحة الرئيسية:

1

2

git merge --squash work

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

1

2

git commit -a -m "Made changes a,b,c,d"

أخيرًا ، نحذف فرع العمل

1

2

git branch -D work

إذا كان لديك فروع متعددة ترغب في دمجها ، فيمكنك القيام بذلك لكل منهم. هناك طرق بديلة ، والتي لن أغطيها ، لتسوية تاريخك (مثل إعادة الرسم التفاعلي ).

في هذه المرحلة ، يمكنك ، إذا أردت ، إدخال أحدث التغييرات على حسابك على GitHub:

1

2

git push -u origin master

للدفع إلى مستودع ووردبريس ، نتأكد أولاً من أن مستودعنا المحلي "حديث":

1

2

git svn rebase

ستذهب Git بعد ذلك لجلب مستودع التخريب ودمج أي تغييرات هناك بالتغييرات التي أجريناها للتو. عادة ، لا ينبغي أن يكون هناك أي تغييرات في مستودع ووردبريس ، لذلك يجب أن ترى الرسالة: الفرع الرئيسي الحالي محدث .

الآن يمكننا دفع تغييراتنا إلى مستودع ووردبريس

1

2

git svn dcommit

قد يطالبك Git ببيانات اعتمادك في WordPress.org. بمجرد إدخال التغييرات ، سيتم الالتزام بمستودع WordPress. قريباً ، يجب أن تتلقى رسالة بريد إلكتروني من مستودع WordPress ، لإعلامك بالالتزامات.

الخطوة 6 وضع علامة على إصدار جديد

حاليا ، هذه التغييرات سوف يجلس في الجذع. ماذا لو أردنا وضع علامة على إصدار جديد من المكون الإضافي لدينا؟  عند إنشاء الإصدار التالي للمكوّن الإضافي ، يجب أن تكون قد قمت بتحديث الملف التمهيدي ، بحيث تشير العلامة المستقرة إلى نسختك الجديدة (قل '2.0'). يجب أيضًا تحديث معلومات رأس المكون الإضافي في ملف plug-in-name.php . إذا كنت قد نسيت القيام بذلك ، فمرور من خلال الإجراء أعلاه ، بعد إجراء هذه التغييرات.

بمجرد تحديث "صندوق السيارة" الخاص بك بالكامل (بما في ذلك أحدث معلومات الإصدار) ، سنحتاج ببساطة إلى إنشاء العلامة الجديدة في مستودع WordPress:

1

2

git svn tag "2.0"

هذا ينسخ كل شيء في صندوق البريد الخاص بك في العلامات / 2.0 (ما الذي تحققه عادة في SVN مع علامات svn cp trunk / 2.0 ).

إذا كنت تريد وضع علامة على الإصدار في المستودع المحلي الخاص بك:

1

2

git tag -a 2.0 -m"Tagging 2.0"

الخطوة 7 (اختياري) وضع علامة على إصدار جديد على GitHub

على غرار ما فعلناه مع مستودع WordPress ، تأكد من توافق مستودعاتنا ، ثم ادفع تغييراتنا وعلاماتنا:

1

2

git pull --rebase origin master 

3

git push origin master 

4

git push origin --tags

موارد مفيدة لأوامر بوابة

• مرجع Git (يحتوي على قسم جيد حول "كيف تفكر مثل Git")
• كتاب بوابة المجتمع
• كتاب برو جيت
• Git Ready (أقل من دليل ، مجموعة "مقتطف" أكثر)
• دورة SVN إلى Git crash (مفيدة إذا كنت قد استخدمت SVN لفترة من الوقت)
• جيت ماجيك (مقدمة ودية لجيت)

وأخيرا هناك زوجين من بوابة "ورقة الغش" التي قد تأتي في متناول اليدين: هنا و هنا .

واجهة المستخدم الرسومية اذهب إلى البرامج

شبابيك

• TortoiseGit (برنامج شائع يتكامل بشكل جيد مع Windows Explorer)
• msysgit

ماك

• برج جيت
• GitHub لنظام التشغيل Mac (من الذين جلبوا لك GitHub)

لينكس / عبر منصة

• GitG (هذا هو ما أستخدمه)
• ويجمع هذا القسم
• جيت كولا (منصة الصليب)