سير عمل واستخدام Git المتقدم

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

سير عمل Git

عندما بدأت في استخدام Git ، أدركت أنني أعرف كيفية استخدامه بشكل صحيح. كان أسلوبي المثالي هو إجراء جميع التغييرات في مكان واحد بدون فروع ثم إلزامها بالمستودع ومواصلة العمل.

على الرغم من أنه كان أفضل من عدم استخدام التحكم في الإصدار ، فقد استغرق الأمر بعض الوقت لأدرك أنني لم أكن أستخدم معظم الطاقة التي يوفرها Git. للحصول على Git يعمل من أجلي ، كنت بحاجة إلى استراتيجية للتفرع ودمج تغييراتي.

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

لكن git-flow لا يناسب كل السيناريوهات ، لذا بينما سنلقي نظرة عليه سنلقي نظرة أيضًا على بعض الطرق الأخرى للحفاظ على تنظيم مشاريع Git الخاصة بك بما في ذلك كيفية إدارة مشاريعي كمطور وحيد.

تدفق بوابة

بالنظر إلى git-flow الآن ، أقر بأن مشهد البرامج قد تغير بشكل كبير في 10 سنوات وأن git-flow قد لا يكون الخيار الأفضل لفريقك. عندما تمت كتابة git-flow ، كان من النادر نشر تطبيق عدة مرات في اليوم. بدلاً من ذلك ، من المحتمل أنك قمت بعمل رقم إصدار رئيسي وإصداره كل بضعة أشهر أو أسابيع إذا كنت ضمن فريق رشيق بشكل خاص.

دعونا نلقي نظرة على ما هو git-flow.

إذا كنت ترغب في رؤية الشرح العميق الكامل مع المخططات وأوامر Git لـ Git Flow ، فيجب عليك قراءة هذا المنشور.

في git-flow ، فرعين لهما عمر لانهائي. أولاً ، الأساسي الذي يجب أن يعكس الكود الجاهز للنشر في بيئة الإنتاج / الحية الخاصة بك.

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

خارج الفرعين الرئيسيين ، هناك ثلاثة أنواع من الفروع الداعمة.

1. الميزة

يمكن إنشاء فرع مميز من فرع التطوير فقط. يجب إعادة دمجها في فرع التطوير. يمكن أن تكون التسمية أي شيء وصفي للميزة التي تعمل عليها.

عندما يكون العمل جاهزًا للإصدار التالي ، يتم دمجه مرة أخرى في فرع التطوير حيث ينتظر وقت الإصدار.

2. الافراج

يتم تصنيع فروع الإصدار من فرع التطوير ويجب دمجها مرة أخرى في كل من التطوير والرئيسي. تقوم بتسمية فرع تحرير باستخدام اصطلاح Release-x. من الناحية العملية ، يعني هذا عادةً أنك ستسمي فرعًا برقم الإصدار الذي تخطط لاستخدامه مثل هذا: الإصدار 2.2

يمكنك استخدام فرع التحرير كطريقة للقيام بالإعداد النهائي لإصدار برنامجك. قد يشمل ذلك رفع رقم إصدار الملفات ، والتأكد من إتمام ترجماتك ، أو التحقق من الشفرة النهائية.

3. الإصلاح

يتم إنشاء فرع الإصلاح العاجل من الفرع الرئيسي ويستخدم لاحتواء التغييرات التي يجب التعامل معها في التطبيق المباشر على الفور. قد يكون هذا خطأ يجب إصلاحه أو مشكلة أمنية يجب التعامل معها.

بمجرد إصلاح المشكلة ونشرها في الفرع الرئيسي لديك ، يمكنك وضع علامة على الكود الخاص بك برقم الإصدار المناسب.

السبب الأكبر الذي يجعل الفرق لا تستخدم git-flow الآن هو أن الطريقة التي نصدر بها البرامج قد تغيرت. بدلاً من الإصدارات الكبيرة بمعدل أقل ، يمكنك إصدار تغيير على أحد التطبيقات عدة مرات في اليوم. أعلم أنني أقوم بدفع العمل إلى مواقع عملائي عدة مرات في الأسبوع بمجرد أن يصبح جاهزًا. لا نقوم بعمل أرقام إصدارات من الموقع ، بل نواصل تحسينه.

لا يُقصد من git-flow القياسي استيعاب هذا.

تدفق جيثب

الخيار الثاني الذي يستخدمه الكثير من الناس هو Github Flow.

القاعدة الكبيرة لـ Github Flow هي أنه يمكن نشر أي كود موجود في الفرع الرئيسي في أي وقت لأنه جاهز للإنتاج.

يتم إنشاء جميع الفروع من الفرع الرئيسي باسم وصفي لكل ما تفعله.

بمجرد أن تصبح التغييرات جاهزة ، يمكنك إنشاء طلب سحب.

تخبر طلبات السحب الآخرين الذين يعملون على نفس الكود أن العمل الذي تقوم به جاهز للمراجعة قبل دمج هذه التغييرات في الكود الرئيسي.

بمجرد إرسال طلب السحب ، يمكن للفريق الذي تعمل معه مراجعة التغييرات وتقديم الملاحظات. إذا تم اعتبار طلب السحب جاهزًا للدمج ، فسيتم دمجه في الفرع الرئيسي لمشروعك.

أحد عيوب تدفق Github لمطور واحد أو فريق صغير جدًا هو أن إدارة طلب السحب يمكن أن تخلق نفقات إضافية في إدارة المشروع. هذا هو سبب عدم استخدامها في عملي.

كيف يمكنني استخدام مهام سير عمل Git مع مشاريع العميل

في عمل موكلي ، عادةً ما أكون الشخص الوحيد الذي يكتب الكود يوميًا للمشروع. قد يقوم عميلي بتحديث مكونات WordPress الإضافية أو تغيير بعض CSS ، لكنهم لا يقومون بأي عمل ترميز رئيسي. هذا يعني أنه إذا ذهبت مع Github flow ، فسأقوم بمراجعة طلبات السحب الخاصة بي والتي لا تؤدي إلا إلى مشاكل إدارية إضافية. لنلقِ نظرة على النظام الذي أستخدمه ، والذي يشبه إلى حدٍ ما كل من git-flow و Github flow.

لدي فرعين رئيسيين يسمى الرئيسي والتقسيم المرحلي. يتتبع الفرع الرئيسي مع أي كود يعمل حاليًا على موقع الإنتاج. يتتبع فرع التدريج مع كل ما يتم اختباره على موقع التدريج الذي نستخدمه لاختبار التغييرات قبل دفعها إلى الموقع المباشر.

يتم إنشاء كل فرع من الفرع الرئيسي. يتم إعطاء الميزات الجديدة اسمًا مثل هذا: feature / 32-new-feature. في هذا السياق ، يتوافق الرقم 32 مع رقم التذكرة في نظام إدارة المشروع لدينا والكلمات التي تليها عبارة عن وصف موجز لما يتم العمل عليه. يتم تسمية إصلاحات الأخطاء بالمثل ، bug / 20-bug-name.

يتم دمج كل فرع تم إنشاؤه في فرعنا المرحلي أولاً ، ثم بمجرد الموافقة عليه من قبل العميل أو اختباره بنفسي ، يتم دمجه في الفرع الرئيسي. قد يبدو سير العمل هذا مثل هذا.

# دمج الميزة في فرع التدريج

ميزة دمج بوابة / 32 ميزة جديدة

# نشر واختبار الميزة

بوابة الخروج الرئيسية

ميزة دمج بوابة / 32 ميزة جديدة

# نشر الميزة على الموقع المباشر

في مشاريعي ، لديّ إعداد نشر مستمر مما يعني أنه في أي وقت أقوم بدفع الكود إلى العنوان الرئيسي ، يتم دفعه إلى الموقع المباشر تلقائيًا. تم إعداد نفس العملية لفرع التدريج.

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

أوامر Git المتقدمة التي أستخدمها

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

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

إضافة التغييرات حسب السطر

الأمر الوحيد الذي جعل استخدام Git عبر Terminal click بالنسبة لي هو git add -p. حتى تعلمت هذا الأمر ، استخدمت تطبيقات واجهة المستخدم الرسومية لأنني سأجري تغييرات في الكود الخاص بي ولكني أريد تقسيم أسطر معينة إلى التزامات مختلفة حتى أتمكن من شرح سبب إجراء التغيير. للقيام بذلك ، استخدمت واجهة المستخدم الرسومية لتحديد الخطوط ، لكن git add -p يرشدك عبر واجهة تفاعلية لإضافة التغييرات في الأجزاء.

أستخدم هذا عدة مرات كل يوم.

تتبع فرع Git البعيد

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

هناك بضعة طرق لفعل هذا.

# ضبط المنبع عند الضغط على جهاز التحكم عن بعد

التدريج الأصلي لبوابة الدفع

# تعيين المنبع

# يفترض أنك في الفرع الذي تريد تتبعه حاليًا باستخدام جهاز التحكم عن بُعد

فرع git -u الأصل / التدريج

فرع git --set-upstream-to = origin / staging

# إذا لم تكن في الفرع الذي تريد تتبعه ، فحدد الفرع في النهاية

فرع git - set-upstream-to = الأصل / التدريج المرحلي

حفظ التغييرات دون الالتزام بها

قد تكون في بعض الأحيان في منتصف بعض الأعمال التي ليست جاهزة للالتزام بها بعد ، لكنك تحتاج إلى حفظ حالتها. هذا هو المكان الذي يكون فيه git stash مفيدًا. هذا الأمر يخفي التغييرات بعيدًا عنك عن طريق إزالة التغييرات. يمكنك استعادتها باستخدام git stash pop. هناك عدد قليل من الأوامر لجعل المخبأ مفيدًا ، لكن هذين هما الأمران اللذان أستخدمهما بانتظام.

سحب التزام Git محدد

تحتاج أحيانًا إلى سحب التزام محدد في عملك الحالي. باستخدام رأس نظيف (لم تقم بإجراء أي تغييرات بعد) ، يمكنك تنفيذ التزام محدد باستخدام git cherry-pick. يمكنك العثور على الوثائق الكاملة حول git cherry-pick هنا.

لكل التزام ، يبني Git سلسلة طويلة من الأحرف والأرقام تسمى Git Object ، ويشار إليها عادةً باسم SHA. نظرًا لأن كل التزام يحصل على التزام ، يمكنك الإشارة إلى التزام بقيمة SHA الخاصة به. اقرأ المزيد عن Git Objects.

تخلص من التغييرات التي لا تحتاج إليها

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

إعادة تعيين بوابة - بجد

سيعيد الأمر أعلاه إعادة تعيين الكود الخاص بك إلى آخر التزام في الفرع الذي تعمل عليه حاليًا. يمكننا أيضًا استخدام <#commitSHA> مع هذا الأمر لإعادة التعيين إلى التزام معين إذا أردنا العودة إلى حالة قبل الالتزام الأخير. ربما تستخدم هذا لإعادة التعيين إلى تسجيل الخروج الأولي للفرع لأن قيمة عمل الفرع بالكامل ليست شيئًا تريد الاحتفاظ به ، ولكنك قمت بالفعل بتتبع بعض الأعمال.

لأخذ خطوة أخرى إلى الأمام ، يمكننا التخلص من أي ملفات أو أدلة لم يتم تعقبها في git بعد باستخدام الأمر git clean.

git clean -fd: تخبر العلامات f و d git برمي الملفات والأدلة التي لم يتم تعقبها.

إزالة الفروع

كل أسبوع أو أسبوعين ، أنظر إلى نتائج أمر git status وأجد أن لدي الكثير من الفروع لفهم ما يحدث في مستودعي بشكل معقول. هذا يعني أنه يمكنني إزالة أي فروع تتوافق مع التذاكر التي تم حلها بالأوامر التالية.

# يزيل النسخة المحلية

فرع git -d $ Branchname

# إزالة الفرع على جهاز التحكم عن بعد

git push $ remotename --delete $ Branchname

استخدم التحكم في الإصدار

على الرغم من أنك قد لا تكون خبيرًا في جميع أوامر Git التي ستستخدمها ، فمن المهم أن تتذكر أنه يجب عليك استخدام التحكم في الإصدار . حتى إذا كنت الشخص الوحيد الذي يعمل في مشروع ما ، فإن استخدام Git وسير عمل Git سيساعدك في الحفاظ على تنظيم مشروعاتك. لن تحتاج إلى الضغط على CTRL + Z حتى تقوم بإعادة تعيين عملك بعد كتابة التعليمات البرمجية التي لم تنجح.

ستكون قادرًا على الوثوق بنظامك والاستمرار في إنتاج العمل لمشاريعك.

جرب استضافة WordPress المُدارة بالكامل

هل تحتاج إلى استضافة محسّنة لـ WordPress؟ تحقق من خطط استضافة WordPress المدارة بالكامل من Nexcess اليوم.