حسنًا ، أنت الآن تعرف Git! سنغوص في شيء أكثر تعقيدًا الآن :)
يحتاج المبرمجون في بعض الأحيان إلى العمل على مشروعين أو أكثر في نفس الوقت. لنتخيل أنه تم العثور على خطأ كبير ويجب إصلاحه في أسرع وقت ممكن.
لذا يتعين على المبرمج التوقف عن ما يعمل عليه حاليًا والعودة إلى إصدار سابق "مستقر" ، وإصلاح الخطأ وإصدار إصدار جديد للعملاء.
بعد ذلك ، تعود إلى المشروع الأصلي. ولكن قبل ذلك ، يجب عليك أيضًا دمج إصلاح الخطأ في الإصدار الذي تعمل عليه حاليًا.
يحتوي Git على ما يسمى بالفروع(branches) لهذا الغرض بالضبط. يمكنك العمل على "فرع (branch)" واحد ، ولكن يمكنك التبديل إلى فرع(branch) آخر (حتى أقدم) ، قم ببعض التغييرات ثم عد إلى الفرع الجديد واستمر ، أو دمج(merge) التغييرات.
تظهر فائدة التفرع(branching) أيضًا عندما يعمل المزيد من الأشخاص على نفس المشروع - يعمل كل شخص على فرعه(branch) الخاص وعندما يحين الوقت ، يتم دمج جميع التغييرات (merge) معًا.
بدلاً من نسخ الملفات من دليل إلى آخر. يخزن Git الفرع كمرجع لالتزام. بهذا المعنى ، يمثل الفرع طرف سلسلة من عمليات الالتزام - إنه ليس حاوية لعمليات الالتزام.
يمكنك التحقق من الفروع(branches) الموجودة في مستودعك(repository).
لهذا ، لدينا الأمر git branch
:
$ git branch
* main
يجب أن يكون لدينا branch واحد فقط وهو يسمى main
.
إنه اسم تقليدي للفرع "الرئيسي" للمشروع
في العامين الماضيين كان هناك تغيير شائع في اسم الفرع الافتراضي من master إلى main، لذلك في المشاريع القديمة لا يزال بإمكانك العثور على فروع master، بينما يقوم GitHub افتراضيًا بالفعل بإنشاء فرع main.
لإنشاء فرع جديد ، ستستخدم الأمر git branch
مرة أخرى.
ستقوم فقط بإضافة اسم الفرع ك (argument) أيضًا.
لذا إذا كنت تريد إضافة اسم المؤلف إلى القصيدة ،
يمكنك تسمية الفرع adding-author
.
$ git branch adding-author
$ git branch
adding-author
* main
قام هذا الأمر بإنشاء فرع(branch) جديد ، لكنه لم يتحول إليه بعد.
يشير رمز النجمة (*) في مخرجات git branch
، إلى الفرع(branch) الذي تعمل عليه.
في هذه الحالة ، لا يزال main
.
للتبديل بين الفروع(branches) ، تحتاج إلى أمر آخر:
$ git checkout adding-author
Switched to branch 'adding-author'
$ git branch
* adding-author
main
لذا ، فأنت الآن "على" فرع(branch) adding-author
. وهذا يعني أيضًا أن HEAD الخاص بك موجود هناك - HEAD يشير إلى أحدث التزام للفرع(branch) الذي تم فحصه حاليًا.
الآن أضف بعض أسماء المؤلفين إلى ملفك poem.txt
. وبمساعدة git add
و git commit
قم بأداء commit جديد.
ممتاز! يمكنك التحقق منه باستخدام git show
أو git status
أو git log
.
دعونا نترك إضافة مؤلف القصيدة للحظة.
عد إلى الفرع main
وقم بإنشاء فرع يسمى
adding-name
منه.
ثم قم بالتبديل إلى هذا الفرع الجديد.
$ git checkout main
Switched to branch 'main'
$ git branch adding-name
$ git checkout adding-name
Switched to branch 'adding-name'
$ git branch
adding-author
* adding-name
main
الآن أضف اسم القصيدة إلى الملف في محرر النصوص الخاص بك وباستخدام نفس الإجراء
كما كان من قبل باستخدام الأوامر git add poem.txt
، git commit -m "commit message"
احفظ الالتزام.
مرة أخرى ، تحقق من كل شيء باستخدام git show
أو git status
أو git log
.
هذا مثال بسيط على كيفية حل الموقف من المقدمة:
ترك العمل قيد التقدم ، والانتقال إلى الإصدار "المستقر" main
و
البدء في العمل في جزء مختلف تمامًا من المشروع.
يمكنك التبديل بين الإصدارات كما تريد ،
ولكن من الجيد دائمًا إجراء commit جديد:
(git commit
) وبمساعدة git status
تأكيد ،
أن كل شيء في مكانه الصحيح.
يعمل تعاون عدة أشخاص على نفس المشروع على نفس المبدأ تمامًا:
هناك قاعدة مشتركة (main
) ويعمل كل عضو
على فرعه الخاص حتى يتم إجراء جميع التغييرات المتوقعة.
عندما يكون فرع معين جاهزًا ، يمكن دمجه مرة أخرى في main
.
دعونا نرى كيف نفعل ذلك!
لن يكون من المنطقي تقسيم تاريخ المشروع ، إذا لم تكن هناك طريقة لدمجهما معًا مرة أخرى. لحسن الحظ بالنسبة لنا ، فإن الدمج في git سهل للغاية.
عد إلى main
واستخدم الأمر git merge
مع اسم الفرع(branch) الذي تريد دمجه.
سيقوم هذا ال commit بدمج(merge) الفرع(branch) الذي تريده في main
.
$ git checkout main
Switched to branch 'main'
$ git merge adding-name
Updating e929fb0..c982a81
Fast-forward
poem.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
تم الدمج(merge)! عبارة "Fast-forward" تعني أنه لم يكن هناك ما تم دمجه - لقد أضفنا للتو تغييرات جديدة من فرع(branch) آخر إلى الفرع(branch) main
.
يمكنك التحقق منه باستخدام git log
أو git status
.
والآن حاول دمج الفرع الثاني أيضًا -
git merge adding-author
.
هنا قد يكون الأمر أكثر تعقيدًا: قد يحدث أنه لا يمكن دمج التغييرات تلقائيًا
معًا وفي سطر الأوامر سنرى العبارة
merge conflict
. سبب ذلك هو أنه لا يمكن لـ git في هذه الحالة
معرفة "الطريقة الصحيحة 100٪" بأمان.
مثال شائع هو إذا قام التزامان في فروع مختلفة بتحرير نفس سطر التعليمات البرمجية. ربما ستعرف الطريقة الصحيحة ولكن git عادة لا يمكنه ذلك ، حيث يمكن أن يكون هناك ثلاثة خيارات: احتفظ فقط بالتغييرات من ال commit الأول ، واحتفظ فقط بالتغييرات من ال commit الثاني أو قم بإجراء تغييرات مخصصة (والتي عادة ما تعني استخدام كلا التغييرين ولكن تكييف الكود قليلاً).
افتح الملف في المحرر وسترى محتوى كلا الإصدارين
المميز بعلامات (">>>" عادةً) والتي تشير إلى الموقع الدقيق الذي حدث فيه التعارض.
قم بتغيير الملف ليكون كما ينبغي (قم أيضًا بإزالة العلامات) ، واحفظه وقم بالالتزام
git commit
.
سواء كان هناك تعارض أم لا ، سيكون هناك التزام دمج (merge commit) خاص
$ git merge adding-author
Auto-merging poem.txt
Merge made by the 'recursive' strategy.
poem.txt | 2 ++
1 file changed, 2 insertions(+)
هل نجح كل شيء؟
إذا كان الأمر كذلك ، يمكنك حذف الفروع (branches) القديمة - جميع تغييراتها موجودة داخل main
وعادة لا يوجد سبب لمواصلة العمل عليها. يمكنك دائمًا إنشاء فرع(branch) جديد لاحقًا مرة أخرى.
$ git branch -d adding-author
Deleted branch adding-author (was 0e213cd).
$ git branch -d adding-name
Deleted branch adding-name (was c982a81).
$ git branch
* main
تهانينا ، أنت الآن قادر على استخدام الفروع(branches) ودمجها (merge). هذا يقربك أكثر في مغامرتك في التعرف على git كأداة تعاون في البرمجة.