صفحة المشروع التي بنيتها في المقالات السابقة صار فيها عملُ أيّام: هيكلٌ، وتنسيق، وتصميمٌ متجاوب، وزرٌّ للوضع الداكن، ورابطٌ للتجاوز. والسؤال الذي يأتي بعد هذا كلّه بسيط: ماذا لو أفسدت شيئًا غدًا ولم تعرف كيف تعود إلى ما كان يعمل؟ أو لو تعطّل حاسوبك الليلة؟ أداتا هذا المقال تجيبان عن السؤالين: Git يحفظ تاريخ مشروعك على جهازك، وGitHub يحفظ نسخةً منه على الإنترنت ويفتحه لمن تريد أن يراه.
ستعرف هنا ما يفعله Git ولماذا وُلد، والمناطق الثلاث التي يمرّ بها كلّ تغيير، ثمّ تضع صفحة مشروعك تحت إدارته وترفعها إلى GitHub. وستتعلّم أيضًا ما تتركه أكثر الشروح العربيّة: لماذا يعرض Git أسماء ملفّاتك العربيّة رموزًا غريبة وكيف تصلح ذلك بسطرٍ واحد. وستعرف لماذا يقول لك master وأنت تريد main، وكيف تعود عن خطأٍ من غير أن تخاف.
ما هو Git؟
نظام Git برنامجٌ لإدارة الإصدارات، أي برنامجٌ يحفظ تاريخ مشروعك كلّه، لا آخر نسخةٍ منه فقط. ويصف كتاب Pro Git، وهو كتاب المشروع الرسميّ، طريقة عمله: يرى Git بياناته سلسلةً من اللقطات، ففي كلّ مرّةٍ تحفظ فيها يصوّر حال ملفّاتك كلّها في تلك اللحظة. وإن لم يتغيّر ملفٌّ بين لقطتين لم يخزّنه مرّةً ثانية، بل خزّن رابطًا إلى نسخته السابقة، ولهذا يبقى سريعًا وصغيرًا.[1]
والبديل الذي يعرفه كلّ مبتدئ مجلّداتٌ بأسماء مثل «المشروع» و«المشروع النهائيّ» و«المشروع النهائيّ فعلًا»، ولا تعرف منها ما الذي تغيّر بين نسخةٍ وأخرى، ولا متى، ولا لماذا. وإن عدّل زميلٌ نسخةً أرسلتها إليه وعدّلت أنت نسختك، صار دمج العملين نسخًا ولصقًا يدويًّا. أمّا Git فيحفظ مع كلّ لقطةٍ اسم صاحبها ووقتها ورسالةً تشرحها، ويدمج عمل اثنين في الملفّ نفسه من تلقاء نفسه، ما لم يعدّلا السطر نفسه.
وGit نظامٌ موزّع. ففي حاسوبك نسخةٌ كاملة من تاريخ المشروع كلّه، فتحفظ وتفتح الفروع وتقرأ التاريخ من غير إنترنت. والنسخة التي على GitHub، أو على حاسوب زميلك، نسخةٌ كاملة أخرى، تزامنها مع نسختك حين تريد.
من أين جاء Git
بدأ مشروع نواة لينكس سنة 2002 يستعمل نظامًا تجاريًّا لإدارة الإصدارات اسمه BitKeeper. وفي 2005، يروي كتاب Pro Git، انقطعت العلاقة بين مجتمع لينكس والشركة التي تملك BitKeeper، وسُحبت مجّانيّة الأداة، فقرّر مجتمع لينكس، ولينوس تورفالدس صاحب لينكس خاصّةً، أن يبنوا أداتهم.[2] وأوّل التزامٍ في مستودع Git نفسه كتبه تورفالدس في 7 نيسان 2005، ورسالته تسخر من الأداة التي يبنيها: «مدير المعلومات من الجحيم».[3] وهذه صورته بعد ذلك بتسع سنوات.[4]

وما زال المشروع حيًّا بعد إحدى وعشرين سنة. فأحدث إصدارٍ منه، 2.56.0، صدر في 28 أيلول 2026، والتغيير الكبير القادم في Git 3.0 يمسّك مباشرة: سيصير اسم الفرع الأوّل في كلّ مستودعٍ جديد main.[5] وستعرف بعد قليل لماذا يهمّك هذا الاسم.
المناطق الثلاث
أوّل ما يربك من يبدأ مع Git أنّ الحفظ فيه خطوتان لا خطوة. ويشرح Pro Git السبب: لكلّ ملفٍّ ثلاث حالات، معدَّلٌ لم يُحفظ بعد، ومجهَّزٌ اخترته ليدخل اللقطة التالية، وملتزَمٌ حُفظ في تاريخ المشروع.[1] وتقابلها ثلاث مناطق: مجلّد العمل، وهو ملفّاتك كما تراها في المحرّر، ومنطقة التجهيز، والمستودع، وهو المجلّد المخفيّ .git داخل مشروعك.
ومنطقة التجهيز هي ما يجعل تاريخك نظيفًا. تخيّل أنّك في ساعةٍ واحدة أصلحت خطأً في script.js، وأضفت قسمًا إلى index.html، وصحّحت لونًا في style.css، فمن غير منطقة التجهيز تحفظ هذا الخليط في لقطةٍ واحدة برسالةٍ مثل «تعديلات». ومعها تختار الملفّين المرتبطين بالقسم الجديد وتحفظهما لقطةً، ثمّ تحفظ إصلاح الخطأ لقطةً ثانية برسالتها، فيصير لكلّ تغييرٍ في تاريخك سببٌ واحد تقرؤه ولو بعد سنة.
وما هو GitHub؟
نظام Git برنامجٌ على حاسوبك، ومنصّة GitHub موقعٌ يستضيف مستودعات Git على الإنترنت. فهو أوّلًا نسخةٌ احتياطيّة: حين ترفع مستودعك إليه يبقى عملك سالمًا لو تعطّل حاسوبك. وهو ثانيًا مكان تعاون، يعمل فيه عدّة أشخاصٍ على مشروعٍ واحد ويراجع بعضهم عمل بعض. وهو ثالثًا واجهةٌ تعرض فيها مشاريعك لمن يريد أن يرى ما تستطيع.
وفي تقرير Octoverse الذي نشرته الشركة في 28 تشرين الأوّل 2025، يعمل على GitHub أكثر من 180 مليون مطوّر. وقد انضمّ منهم أكثر من 36 مليونًا في سنةٍ واحدة، أي أكثر من مطوّرٍ في كلّ ثانية.[6] وهو الأشهر، وليس الوحيد: فلـGit نفسه مواقع استضافةٍ أخرى مثل GitLab وCodeberg، والأوامر التي تتعلّمها هنا تعمل معها كلّها، لأنّها أوامر Git لا أوامر GitHub.
التثبيت والهويّة
على Linux ثبّت Git من مدير الحزم الذي تعرّفت إليه في مقال الطرفية. وعلى Windows نزّل المثبّت من git-scm.com واقبل خياراته الافتراضيّة، وعلى macOS يعرض النظام تثبيت أدوات سطر الأوامر حين تكتب أوّل أمر git. ثمّ تحقّق بالأمر git --version، وعلى الجهاز الذي كُتب عليه هذا المقال يطبع 2.53.0، فالإصدار الذي يأتي مع نظامك قد يتأخّر قليلًا عن أحدث إصدار، ولا بأس بذلك.

وقبل أوّل حفظ عرّف Git بنفسك، مرّةً واحدة على كلّ جهاز، لأنّه يكتب اسمك وبريدك على كلّ لقطة:
git config --global user.name "سلمى"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main
git config --global core.quotePath false
السطران الأوّلان هويّتك. والثالث يسمّي الفرع الأوّل في كلّ مستودعٍ تنشئه main. فالإصدارات الحاليّة من Git ما زالت تسمّيه master إن لم تقل لها غير ذلك، وتطبع لك تحذيرًا طويلًا تقترح فيه هذا الإعداد نفسه، كما ترى في لقطةٍ بعد قليل. وتوثيق git init يذكر الإعداد init.defaultBranch والخيار -b لهذا الغرض.[7] وأكثر مواقع الاستضافة اليوم تسمّي الفرع الرئيس main، وGit 3.0 سيفعل ذلك افتراضيًّا.
أمّا السطر الرابع فيخصّك لأنّك تكتب بالعربيّة. فإن سمّيت ملفًّا «صورة الغلاف.png» ثمّ كتبت git status، طبع Git اسمه هكذا: "\330\265\331\210\330\261\330\251 ..."، والنتيجة هنا منسوخةٌ من Git 2.53. والسبب في توثيق الإعداد core.quotePath: الأوامر التي تعرض المسارات تكتب كلّ بايتٍ أكبر من 0x80 بترميزٍ ثُمانيّ، وكلّ حرفٍ عربيّ في UTF-8 بايتان من هذا النوع.[8] وحين تجعل قيمته false يطبع Git الاسم «صورة الغلاف.png» كما كتبته. والإعداد يشمل أسماء المجلّدات أيضًا، فأيّ مسارٍ فيه حرفٌ عربيّ يُعرض بالطريقة نفسها.
التطبيق: صفحة المشروع تحت إدارة Git
افتح مجلّد my-first-site في VS Code، ثمّ افتح الطرفية المدمجة من قائمة Terminal أو بالاختصار الذي تعرّفت إليه في مقال VS Code، فالطرفية تحت الشيفرة تجعل التنقّل بينهما أسرع.
ثمّ اكتب git init. فينشئ Git المجلّد المخفيّ .git، وهو قاعدة بيانات مشروعك كلّها، فلا تعدّل ما فيه بيدك أبدًا. ثمّ اكتب أهمّ أمرٍ ستستعمله، git status، فيقول لك على أيّ فرعٍ أنت، وما الملفّات التي يراها ولا يتتبّعها بعد. وفي اللقطة التالية ترى ما يحدث إن لم تضبط init.defaultBranch: رسالة تحذيرٍ طويلة عن اسم master، ثمّ الفرع master فعلًا.

والحفظ خطوتان كما عرفت. git add . يجهّز كلّ ما في المجلّد، والنقطة تعني المجلّد الحاليّ، وgit commit -m "..." يحفظ اللقطة برسالتها. وتستطيع أن تجهّز ملفًّا واحدًا باسمه، مثل git add index.html، حين تريد أن تفصل تغييرين في لقطتين.
وكم مرّةً تلتزم؟ القاعدة العمليّة أن يكون كلّ التزامٍ خطوةً صغيرة كاملة: الصفحة تعمل بعده كما كانت تعمل قبله، وفيه تغييرٌ واحد تستطيع أن تصفه في سطر. فإن لم تستطع أن تكتب رسالته في سطرٍ قصير، فالتغيير أكبر ممّا يجب، فقسّمه. والالتزامات الصغيرة تجعل العودة عن خطأٍ سهلة، لأنّك تعود عن خطوةٍ واحدة لا عن يوم عملٍ كامل.

ورسالة الالتزام ما تقرؤه بعد ستّة أشهرٍ لتعرف لماذا تغيّر سطر. ويقترح كتاب Pro Git سطرًا أوّل في نحو 50 حرفًا يصف التغيير، ثمّ سطرًا فارغًا، ثمّ شرحًا أطول إن احتجت، وأن تكتب الرسالة بصيغة الأمر: «أصلح» لا «أصلحت».[9] وتستطيع أن تكتبها بالعربيّة، فـ«أضف رابط التجاوز» رسالةٌ صالحة تمامًا، وقد رأيت Git يحفظها ويعرضها كما هي. وحين تريد أن ترى التاريخ اكتب git log --oneline، فيعرض كلّ التزامٍ في سطرٍ واحد.
وقبل أن ترفع شيئًا، اعرف ما يجب ألّا يُرفع. فملفّات الإعدادات السرّيّة، ومجلّد node_modules الذي عرفته في مقال تجهيز بيئة العمل، وملفّات النظام مثل .DS_Store، لا مكان لها في مستودعك. ولهذا ملفٌّ اسمه .gitignore، يحدّد كما يقول توثيقه الملفّات غير المتتبَّعة التي يجب أن يتجاهلها Git عمدًا.[10] تكتب فيه اسم ملفٍّ أو نمطًا في كلّ سطر، مثل node_modules/ أو *.log، فلا يعرضه git status ولا يدخل لقطاتك.
من جهازك إلى GitHub
أنشئ حسابًا على github.com إن لم يكن لك، واختر اسم مستخدمٍ تقبل أن يراه صاحب عملٍ في المستقبل، فهو جزءٌ من عنوان كلّ مشروعٍ ترفعه لاحقًا. ثمّ أنشئ مستودعًا جديدًا من الزرّ الذي في أعلى الصفحة، وسمّه my-first-site، واتركه عامًّا ليكون جزءًا من معرض أعمالك، ولا تضف إليه أيّ ملفّ الآن، لأنّ ملفّاتك موجودةٌ عندك.

ويعرض عليك GitHub بعد إنشاء المستودع الأوامر التي تربطه بمستودعك المحلّيّ. الأوّل يضيف عنوان المستودع البعيد ويسمّيه origin، وهو الاسم المتعارف عليه، والثاني يسمّي فرعك main إن كان master، والثالث يرفع التزاماتك ويربط فرعك المحلّيّ بالبعيد:
git remote add origin https://github.com/اسم-المستخدم/my-first-site.git
git branch -M main
git push -u origin main
وحين تكتب git push أوّل مرّة سيطلب منك GitHub أن تثبت أنّك صاحب الحساب. ولا تكتب كلمة مرور حسابك هنا، فمنذ 13 آب 2021 لم يعد GitHub يقبلها في عمليّات Git.[11] تستطيع أن تنشئ رمز وصولٍ شخصيًّا من إعدادات حسابك وتكتبه بدل كلمة المرور. والطريق الآخر مفتاح SSH تنشئه مرّةً واحدة، فيتّصل جهازك بـGitHub بعد ذلك من غير أن تكتب اسمك ورمزك في كلّ مرّة، كما يشرح توثيق GitHub. والثاني أريح على المدى الطويل.
وفي اللقطة التالية الأوامر نفسها كما جرت فعلًا، ومعها خطأٌ لا بأس به. فقد كان origin مضافًا من قبل، فقال Git «remote origin already exists» ولم يغيّر شيئًا، وتابع الرفع كما يجب. فرسائل Git الحمراء في أكثر الأحيان تقول لك ما حدث بدقّة، فاقرأها قبل أن تقلق.

ثمّ حدّث صفحة المستودع على GitHub، وستجد ملفّاتك هناك، ومعها رسالة الالتزام الذي رفعته، ولغات المشروع محسوبةً في جانب الصفحة.
وأوّل ما يراه زائر مستودعك ملفٌّ اسمه README.md، يشرح ما في المشروع وكيف يُشغَّل. وتدعوك الصفحة نفسها إلى إضافته، فاكتب فيه سطرين عن الصفحة ولماذا بنيتها، فهو أوّل ما يقرؤه من يقيّم عملك. ويعرض GitHub محتواه تحت قائمة الملفّات مباشرةً، بعناوينه وقوائمه، لأنّه مكتوبٌ بلغة Markdown البسيطة. واكتب فيه أيضًا كيف تُفتح الصفحة: يكفي أن يفتح الزائر index.html في متصفّحه، فالصفحة لا تحتاج إلى خادم.

دورة العمل اليوميّة
الإعداد الأوّل أطول ما في Git، والعمل اليوميّ بعده ثلاثة أوامر تتكرّر: تعدّل ملفًّا وتحفظه في المحرّر، ثمّ تجهّزه وتلتزم به، ثمّ ترفعه:
git add index.html
git commit -m "غيّر عنوان الصفحة الرئيس"
git push
ولاحظ أنّ git push صار وحده، لأنّ الخيار -u في المرّة الأولى ربط فرعك بالمستودع البعيد. وقبل أن تجهّز، اكتب git diff، فيريك ما تغيّر في ملفّاتك سطرًا سطرًا منذ آخر لقطة. والنظر في ما تغيّر قبل أن تلتزم به عادةٌ تمنع كثيرًا من الأخطاء قبل أن تدخل التاريخ.
والعمل يسير في الاتّجاه الآخر أيضًا. فـgit clone متبوعًا بعنوان مستودعٍ ينزّله إلى جهازك بتاريخه كلّه، كأن تعمل على مشروعك من حاسوبٍ آخر. وgit pull يجلب ما رفعه غيرك إلى المستودع البعيد ويدمجه في نسختك. وإن كنت تفضّل النقر على الكتابة، ففي VS Code قسم التحكّم بالمصادر يجهّز ويلتزم ويرفع بالأزرار. والأوامر أوّلًا، لأنّها تعلّمك ما تفعله الأزرار.
الفروع: جرّب من غير أن تخاف
كلّ ما سبق خطٌّ زمنيّ واحد. لكن ماذا لو أردت أن تجرّب ميزةً لست متأكّدًا منها؟ هنا تأتي الفروع. فالفرع خطٌّ زمنيّ موازٍ يبدأ من لقطةٍ تختارها، تلتزم فيه بما تشاء، والفرع main باقٍ كما هو، فإن نجحت التجربة دمجتها في main، وإن فشلت حذفت الفرع وكأنّها لم تكن.
وفي الجلسة التالية جرى هذا فعلًا على صفحة المشروع نفسها. فبعد التزامٍ أوّل على main فُتح فرعٌ اسمه skip-link بالأمر git switch -c، وأُضيف فيه رابط التجاوز ومؤشّر التركيز من مقال إتاحة الويب. ثمّ عادت الجلسة إلى main ودمجت الفرع:

والأمران switch وrestore جاءا مع Git 2.23 ليقسما عمل الأمر القديم checkout، الذي كان ينتقل بين الفروع ويستعيد الملفّات معًا فيربك المبتدئين.[12] والخيار --no-ff في الدمج يُبقي في التاريخ التزامًا خاصًّا بالدمج، ولهذا ترى في آخر اللقطة الفرع يخرج من main ويعود إليه.
وقد يعدّل فرعان الموضع نفسه من الملفّ نفسه، فيقف Git عند الدمج. ويشرح توثيق git merge ما يفعله حينها: لا يختار أحد التغييرين عشوائيًّا، ويترك الاثنين في الملفّ بين علاماتٍ تبدأ بـ<<<<<<< وتنتهي بـ>>>>>>>، لتقرّر أنت.[13] تفتح الملفّ، وتبقي ما تريد وتحذف العلامات، ثمّ تجهّزه وتلتزم به كأيّ تغيير. وهذا التعارض سؤالٌ من Git، ومع الممارسة يصير حلّه دقيقةً من يومك.
حين تخطئ: ثلاث طرقٍ للعودة
هنا يظهر معنى شبكة الأمان. فالحالة الأولى أن تعبث بملفٍّ ولم تجهّزه بعد، وتريد أن يعود كما كان في آخر لقطة: git restore index.html. والحالة الثانية أن تجهّز ملفًّا ثمّ تغيّر رأيك قبل الالتزام: git restore --staged index.html، فيخرج من منطقة التجهيز ويبقى تعديلك فيه.
والحالة الثالثة أهمّها: التزمت بتغييرٍ خاطئ، وربّما رفعته. والحلّ هنا إضافةٌ إلى التاريخ، فالأمر git revert يسجّل، كما يقول توثيقه، التزاماتٍ جديدة تعكس أثر التزاماتٍ سابقة، وغالبًا التزامًا واحدًا خاطئًا.[14] فتكتب معرّف الالتزام الخاطئ الذي تراه في git log، مثل git revert 7ccc002، فيصنع Git التزامًا يلغيه، ويبقى التاريخ كلّه صادقًا لمن رفعته إليهم.
وأحيانًا لا تكون قد أخطأت، بل انقطعت: أنت في منتصف تعديلٍ لم يكتمل، وجاء خطأٌ عاجل في main يجب أن تصلحه الآن. والأمر git stash يحفظ حال مجلّد العمل ومنطقة التجهيز جانبًا، كما يشرح توثيقه، ويعيدك إلى مجلّدٍ نظيف كآخر لقطة.[15] فتصلح الخطأ وتلتزم به، ثمّ تكتب git stash pop فيعود تعديلك الناقص كما تركته، وتكمل من حيث توقّفت.
المساهمة في مشروعٍ لا تملكه
وعلى الفروع يقوم التعاون كلّه على GitHub. فحين تريد أن تساهم في مشروعٍ لا تملكه، تنسخه إلى حسابك بزرّ Fork، فتصير لك نسختك الكاملة منه. تعمل فيها على فرعٍ خاصّ، ثمّ تفتح طلب سحب، أي اقتراحًا بأن تُدمج تغييرات فرعك في المشروع الأصليّ، يراه أصحابه ويقرّرون،[16] وهكذا تعمل مشاريع المصادر المفتوحة الكبيرة، ومنها Git نفسه.
خلاصة عمليّة
اضبط هويّتك وinit.defaultBranch وcore.quotePath مرّةً على كلّ جهاز. اكتب git status قبل كلّ شيء، وgit diff قبل كلّ تجهيز. جهّز ما يرتبط ببعضه فقط، واكتب رسالة الالتزام بصيغة الأمر في سطرٍ قصير، بالعربيّة إن شئت. ضع في .gitignore ما يجب ألّا يُرفع، وارفع بمفتاح SSH أو رمز وصول لا بكلمة المرور. جرّب في فرع، وادمج حين تنجح التجربة، وعد عن الخطأ المرفوع بـgit revert.
وصفحتك الآن لها تاريخٌ محفوظ، ونسخةٌ على GitHub. ويبقى أن يراها الناس صفحةً حيّة على الويب، بعنوانٍ يستطيع أيّ أحدٍ أن يفتحه، وهذا ما يفعله المستودع الذي أنشأته للتوّ في الخطوة التالية من السلسلة.
المصادر
- سكوت تشاكون وبن ستراوب، «What is Git?»، كتاب Pro Git: يرى Git بياناته سلسلةً من اللقطات، وإن لم يتغيّر ملفٌّ لم يخزّنه ثانيةً بل خزّن رابطًا إلى نسخته السابقة، وللملفّات ثلاث حالات: معدَّل، ومجهَّز، وملتزَم.
- كتاب Pro Git، «A Short History of Git»: استعمل مشروع نواة لينكس منذ 2002 نظامًا تجاريًّا اسمه BitKeeper، وفي 2005 انقطعت العلاقة وسُحبت مجّانيّته، فبنى مجتمع لينكس، ولينوس تورفالدس خاصّةً، أداتهم الخاصّة.
- لينوس تورفالدس، «Initial revision of “git”, the information manager from hell»، أوّل التزامٍ في مستودع Git نفسه، 7 نيسان 2005.
- صورة «LinuxCon Europe Linus Torvalds 03» للمستخدم Krd، تشرين الأوّل 2014، برخصة CC BY-SA 4.0، وشعار Git على غلاف المقال لجيسون لونغ من git-scm.com برخصة CC BY 3.0.
- مشروع Git، «git-scm.com»: أحدث إصدار 2.56.0 في 28 أيلول 2026. و«BreakingChanges»: في Git 3.0 يصير اسم الفرع الافتراضيّ في المستودعات الجديدة main.
- شركة GitHub، «Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1»، 28 تشرين الأوّل 2025: أكثر من 180 مليون مطوّر على GitHub، انضمّ منهم أكثر من 36 مليونًا في سنةٍ واحدة.
- توثيق Git، «git-init»: الخيار
--initial-branchأو-bيسمّي الفرع الأوّل، والإعداد init.defaultBranch يضبط الاسم لكلّ المستودعات الجديدة. - توثيق Git، «git-config: core.quotePath»: الأوامر التي تعرض مسارات الملفّات تكتب البايتات الأكبر من 0x80 بترميزٍ ثُمانيّ، وإن كانت قيمة الإعداد false لم تعدّها غريبة.
- كتاب Pro Git، «Contributing to a Project: Commit Guidelines»: سطرٌ أوّل في نحو 50 حرفًا يصف التغيير، ثمّ سطرٌ فارغ، ثمّ شرحٌ أطول، ورسالةٌ بصيغة الأمر.
- توثيق Git، «gitignore»: ملفّ يحدّد الملفّات غير المتتبَّعة التي يجب أن يتجاهلها Git عمدًا.
- شركة GitHub، «Token authentication requirements for Git operations»: منذ 13 آب 2021 لا يقبل GitHub كلمة مرور الحساب في عمليّات Git. وتوثيق GitHub، «About SSH»: بمفاتيح SSH تتّصل من غير أن تكتب اسم المستخدم ورمز الوصول في كلّ مرّة.
- مشروع Git، «Git 2.23 Release Notes»: أمران جديدان، git switch وgit restore، يقسمان عمل git checkout بين الانتقال إلى فرعٍ واستعادة الملفّات.
- توثيق Git، «git-merge: How conflicts are presented»: حين يغيّر الطرفان الموضع نفسه، لا يختار Git بينهما، ويترك التغييرين في الملفّ بين علاماتٍ لتقرّر أنت.
- توثيق Git، «git-revert»: يسجّل التزاماتٍ جديدة تعكس أثر التزاماتٍ سابقة، وغالبًا التزامًا واحدًا خاطئًا.
- توثيق Git، «git-stash»: يحفظ الحال الحاليّة لمجلّد العمل ومنطقة التجهيز ويعيدك إلى مجلّدٍ نظيف، ثمّ يعيدها git stash pop.
- توثيق GitHub، «About pull requests»: تعريف طلبات السحب وطريقة عملها بين الفروع والمستودعات.