كيفية جعل الحياة أسهل عند استخدام Git (بالإضافة إلى مجموعة مختارة من المواد للانغماس العميق)


Tree of Dragons II بواسطة surrealistguitarist

لأولئك الذين يستخدمون Git كل يوم لكنهم يشعرون بعدم الأمان ، الفريقلقد قامت Mail.ru Cloud Solutions بترجمة مقال للمطوّر الأمامي Shane Hudson . ستجد هنا بعض الحيل والنصائح التي يمكن أن تجعل العمل مع Git أسهل قليلاً ، بالإضافة إلى مجموعة مختارة من المقالات والكتيبات بمستوى أكثر تقدمًا.

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

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

نرتب الأشياء


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

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

فرز الفروع حسب التاريخ


يُظهر التصنيف حسب التاريخ جميع الفروع المحلية ، بدءًا من الأخير. شائع جدًا ، لكنه ساعدني عدة مرات:

# To sort branches by commit date
git branch --sort=-committerdate

الموضوع السابق


ماذا لو لم تلتزم بتبديل الفرع ثم تريد العودة إلى الفرع السابق؟ ربما يمكنك العثور عليها في قائمة الفروع إذا كان لديك فكرة عن اسمها. ولكن ماذا لو لم يكن فرعًا ، ولكنه detached HEADالتزام محدد؟

اتضح أن هناك طريقة بسيطة للخروج:

# Checkout previous branch
git checkout -

عامل التشغيل -هو اختصار لبناء الجملة @{-1}الذي يسمح لك بالتبديل إلى أي عدد من عمليات السحب مرة أخرى. لذلك ، على سبيل المثال ، إذا قمت بإنشاء فرع feature/thing-a، ثم feature/thing-b، bugfix/thing-cستعيدك المعلمة @{-2}إلى feature/thing-a:

# Checkout branch N number of checkouts ago
git checkout @{-N}

عرض معلومات عن جميع الفروع


vيعرض العلم قائمة بجميع الفروع مع آخر معرف الالتزام والرسالة. vvسيظهر الزوج أيضًا الفروع المنبع بعيدًا ، تليها الفروع المحلية:

# List branches along with commit ID, commit message and remote
git branch -vv

إيجاد ملف


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

الطريقة غريبة بعض الشيء ، بالنظر إلى أن هذا git checkout -يأخذك إلى الفرع السابق. بشكل عام ، إذا حددت --بعد اسم الفرع في الخروج ، فإن هذا سيسمح لك بتحديد الملف المحدد الذي تبحث عنه. لن تخمن مثل هذه الوظيفة بدون تلميح ، ولكنها مريحة للغاية إذا كنت تعرف:

git checkout feature/my-other-branch -- thefile.txt

حالة واضحة


قام توماس لاكوما بالتغريد عن تخفيض الإصدار git statusبمساعدة الأعلام -sbوأضاف: "لسنوات عديدة كنت أستخدم Git ، ولكن لم يخبرني أحد عن ذلك". لا يتعلق الأمر فقط بالعثور على الملفات المفقودة. هناك أوقات يجعل فيها تبسيط المشكلة من السهل عرض التغييرات.

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

# Usually we would use git status to check what files have changed
git status

# Outputs:
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: README.md

Untracked files:
(use "git add <file>..." to include in what will be committed)

another-file
my-new-file

# Using the flags -sb we can shorten the output
git status -sb

# Outputs:
## master
M README.md
?? another-file
?? my-new-file

القصة كاملة


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

جميع أفعالك في Git التي تغير المحتويات حسب المرجع HEAD@{}(على سبيل المثال push/pull/branch/checkout/commit) تقع في reflog (السجل المرجعي). في الواقع ، هذه هي قصة جميع أفعالك ، بغض النظر عن الفرع الذي أنت فيه. هذا هو الفرق git logالذي يظهر التغييرات لفرع معين.


يمكنك القيام git showبمعرف الالتزام - وانظر التغيير المحدد. إذا كان هذا ما كنت تبحث عنه ، فسوف git checkoutينقلك إلى الفرع المطلوب أو حتى يسمح لك بتحديد ملف معين ، كما هو موضح أعلاه:

# See the reference log of your activity
git reflog --all

# Look at the HEAD at given point from reflog
git show HEAD@{2}

# Checkout the HEAD, to get back to that point
git checkout HEAD@{2}

تحضير الملفات التي فوتت الالتزام


في الحالات القصوى ، إذا git reflogلم يساعدك في استعادة ملفاتك (على سبيل المثال ، قمت بإعادة ضبط القرص الصلب مع الملفات المتوسطة) ، فهناك خدعة أخرى.

يتم تخزين كل تغيير داخل كائنات .git/objectsمليئة بالملفات في المشروع النشط ، لذا يكاد يكون من المستحيل اكتشافها. ومع ذلك ، هناك أمر Git يسمى git fsck، والذي يُستخدم للتحقق من سلامة (وجود ملفات تالفة) في المستودع. يمكننا استخدامه مع علامة --lost-foundللبحث عن جميع الملفات التي لا تتعلق بتنفيذ. تسمى هذه الملفات "dangling blob".

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

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

# This will find any change that was staged but is not attached to the git tree
git fsck --lost-found

# See the dates of the files
ls -lah .git/lost-found/other/

# Copy the relevant files to where you want them, for example:
cp .git/lost-found/other/73f60804ac20d5e417783a324517eba600976d30 index.html

Git في العمل الجماعي


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

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

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

نفس نهايات السطر


بشكل افتراضي ، يستخدم Windows نهايات سطر DOS \r\n(CRLF) ، بينما يستخدم نظاما التشغيل Mac و Linux نهايات سطر UNIX \n(LF) ، بينما تستخدم الإصدارات القديمة من Mac \r(CR). وهكذا ، مع نمو الفريق ، تصبح مشكلة نهايات الخطوط غير المتوافقة أكثر احتمالية. هذا غير مريح ، فهم (عادة) لا يخرقون الرمز ، ولكن بسببهم ، تظهر طلبات التنفيذ وتجمع التغييرات المختلفة غير ذات الصلة. غالبًا ما يتجاهلهم الناس ببساطة ، لأنه من الصعب جدًا التجول وتغيير جميع نهايات الخطوط الخاطئة.

هناك حل - يمكنك أن تطلب من جميع أعضاء الفريق تكوين التكوينات المحلية الخاصة بهم لإكمال الخط تلقائيًا:

# This will let you configure line-endings on an individual basis
git config core.eol lf
git config core.autocrlf input

بالطبع ، تحتاج إلى الاشتراك في هذه الاتفاقية والمبتدئ ، وهو أمر سهل النسيان. كيف تفعل هذا للفريق بأكمله؟ وفقًا لخوارزمية العمل ، يتحقق Git من وجود ملف تكوين في مستودع .git / config ، ثم يتحقق من تكوين المستخدم على مستوى النظام ~/.gitconfig، ثم يتحقق من التكوين العام /etc/gitconfig.

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

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

# Adding this to your .gitattributes file will make it so all files
# are checked in using UNIX line endings while letting anyone on the team
# edit files using their local operating system’s default line endings.
* text=auto

اخفاء تلقائي


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

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

كل شيء يقلل من الضغط والحمل المعرفي في عملية مراجعة الكود يحسن من جودته ويقلل من الوقت.

على سبيل المثال ، تريد إضافة ملفات الموارد (الأصل) إلى المستودع ، ولكنك لن تقوم بتعديلها وتتبعها لاحقًا ، بحيث يمكنك إضافة السطر التالي إلى الملف بسمات:

*.asset linguist-generated

استخدم اللوم git أكثر


توصي مقالة هاري روبرتس "الأشياء الصغيرة التي أحب القيام بها باستخدام Git"git blame (تعيين git praiseالترجمة ) بتعيين اسم مستعار (الترجمة من الترجمة "الإنجليزية") ليشعر هذا الفريق كإجراء إيجابي. بالطبع ، إعادة التسمية لا تغير سلوك الفريق. ولكن عندما يأتي النقاش باستخدام دالة git blame، يصبح الجميع متوترين ، وأنا بالطبع كذلك. من الطبيعي أن تدرك كلمة اللوم (الذنب) على أنها شيء سلبي ... لكن هذا خطأ تمامًا!

تُظهر وظيفة قوية git blame (أو git praiseإذا أردت) من كان آخر من استخدم هذا الرمز. لن نلومه أو نمدحه ، ولكن نريد فقط توضيح الموقف. يصبح من الواضح أكثر الأسئلة التي يجب طرحها ولمن ، مما يوفر الوقت.

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

اللوم تناظري للملفات المفقودة


لقد رأيت مؤخرًا مطورًا في فريقنا يحاول معرفة من حذف الملف ومتى ولماذا. يبدو أنه يمكن أن يساعد هنا git blame، ولكنه يعمل مع الأسطر الموجودة في الملف ولا جدوى منه إذا كان الملف مفقودًا.

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

# By using -- for a specific file,
# git log can find logs for files that were deleted in past commits
git log -- missing_file.txt

قالب رسالة الالتزام


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

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

# This sets the commit template to the file given,
# this needs to be run for each contributor to the repository.
git config commit.template ./template-file

بوابة للأتمتة


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

خطاف بوابة


في كثير من الأحيان ، ترى أن أعضاء الفريق يقومون بمهام متكررة أثناء العمل. يمكن أن يكون هذا اختبارًا لاجتياز الاختبارات واللينت قبل إرسال فرع إلى الخادم (ربط قبل الإرسال) أو إستراتيجية إجبارية لتسمية الفروع (ربط قبل الالتزام). حول هذا الموضوع ، كتب كونستانتينوس ليمونز في مجلة Smashing Magazine مقالة بعنوان "كيفية تبسيط سير العمل بخطافات Git» .

الأتمتة اليدوية


واحدة من ميزات الأتمتة الرئيسية في Git هي git bisect. سمع الكثير عن ذلك ، ولكن القليل يستخدمه. خلاصة القول هي معالجة شجرة Git (تاريخ الالتزام) وإيجاد مكان إدخال الخطأ.

أسهل طريقة للقيام بذلك هي باليد. يمكنك البدء git bisect start، وتعيين معرفات الأوامر الجيدة والسيئة (حيث لا يوجد خلل وحيث يوجد خطأ) ، ثم التنفيذ git bisect goodأو git bisect badلكل التزام.

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

# Begin the bisect
git bisect start

# Tell git which commit does not have the bug
git bisect good c5ba734

# Tell git which commit does have the bug
git bisect bad 6c093f4

# Here, do your test for the bug.
# This could be running a script, doing a journey on a website, unit test etc.

# If the current commit has bug:
git bisect bad

# If the current commit does not have the bug
git bisect good

# This will repeat until it finds the first commit with the bug
# To exit the bisect, either:

# Go back to original branch:
git bisect reset

# Or stick with current HEAD
git bisect reset HEAD

# Or you can exit the bisect at a specific commit
git bisect reset <commit ID>

الانتقال: الأتمتة العلمية


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

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

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

فكيف يمكننا أتمتةgit bisect؟؟؟ يمكنك تمرير البرنامج النصي لكل التزام المقابلة. في وقت سابق ، قلت أنه يمكنك تشغيل البرنامج النصي يدويًا في كل خطوة من أجزاء bisect ، ولكن إذا قمت بتمرير أمر للتشغيل ، فسيتم تشغيل البرنامج النصي تلقائيًا في كل خطوة. يمكن أن يكون برنامجًا نصيًا خصيصًا لتصحيح هذه المشكلة المحددة أو اختبار (معياري ، وظيفي ، وتكامل ، وأي نوع من الاختبار). وبالتالي ، يمكنك كتابة اختبار للتحقق من أن الانحدار لا يتكرر ، وتشغيل هذا الاختبار في عمليات التنفيذ السابقة:

# Begin the bisect
git bisect start

# Tell git which commit does not have the bug
git bisect good c5ba734

# Tell git which commit does have the bug
git bisect bad 6c093f4

# Tell git to run a specific script on each commit
# For example you could run a specific script:
git bisect run ./test-bug

# Or use a test runner
git bisect run jest

على كل التزام الماضي


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

كمران أحمد في تغريدة مكتوبة كما rebaseهو ، ما الالتزام لا يجتاز الاختبار:

العثور على تعهد فشل الاختبار:

$ git rebase -i --exec "yarn test" d294ae9

يقوم الأمر بتشغيل اختبار الغزل على جميع عمليات التنفيذ بين d294ae9 و HEAD ويتوقف عند الالتزام حيث يتعطل الاختبار.

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

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

# This will run for every commit between current and the given commit ID
git rebase -i --exec ./my-script

مجموعة مختارة من المقالات والكتيبات لمساعدتك على التعمق في Git


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

  1. بوابة المستكشف . موقع تفاعلي يساعدك على فهم كيفية تحقيق ما تريد بسهولة.
  2. دانغ انها بوابة! . يمكن أن يضيع كل منا في مرحلة ما في Git ولا يعرف كيفية حل أي مشكلة. يوفر هذا الموقع حلولًا للعديد من المشاكل الأكثر شيوعًا.
  3. بوابة برو . هذا الكتاب المجاني مورد لا يقدر بثمن لفهم Git.
  4. Git Docs. — . , Git Docs, Git (, man git-commit) Git .
  5. Thoughtbot. Git Thoughtbot .
  6. Git. Git.
  7. Git. , … . Git, .
  8. Git: من المبتدئ إلى المستوى المتقدم . كتب Mike Ritmüller هذه المقالة المفيدة ، وهي مثالية لمستخدمي Git المبتدئين.
  9. أشياء صغيرة أحب القيام بها مع Git . كانت هذه المقالة التي كتبها هاري روبرتس هي التي جعلتني أدرك عدد الاحتمالات التي لا تزال موجودة في Git ، بصرف النظر عن نقل الشفرة عبر الفروع.
  10. أدلة Atlassian Advanced Git . توضح هذه الدروس التعليمية العديد من الموضوعات المذكورة في هذه المقالة.
  11. ورقة الغش Git على Github . من الملائم دائمًا أن يكون لديك ورقة غش جيدة لأدوات مثل Git.
  12. تخفيض Git . توضح هذه المقالة العديد من علامات أوامر Git وتوصي بالعديد من الأسماء المستعارة.

ولكن ماذا يمكنك أن تقرأ :

  1. Git. №1: , .git
  2. Git. №2: rebase.
  3. .

All Articles