استخدام متقدم لـ Geeta أو كيفية التقاعد قبل ستة أشهر؟

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

قضيت الكثير من الأعصاب عندما بدأت أتعلم طريقة الطباعة بعشرة أصابع. في النهاية ، كان هذا أفضل قرار لتحسين سير عملك الشخصي. من بين التحسينات التالية الأكثر أهمية التطوير المتقدم لـ Geeta.

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

من سيستفيد من هذه المقالة؟

هل سبق لك أن أتقنت مجموعة الرجل الجيتا وهل أنت مستعد للمضي قدمًا؟ هناك طريقتان:

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

خصص بضع ساعات اليوم للتجارب الموصوفة في المقالة ، ووفّر بالحسابات التقريبية ستة أشهر من الحياة العملية.

مرحبًا بك في القط!

تحضير

من بين المطورين ، فإن معيار بديل Bash هو Zsh ، وهو برنامج برمجي متقدم يدعم الضبط الدقيق. ومن بين مستخدمي Zsh ، المعيار هو استخدام Oh My Zsh ، وهي مجموعة من الإعدادات المحددة مسبقًا لـ Zsh . وبالتالي ، بعد تثبيت هذه المجموعة ، سنخرج من الصندوق مجموعة من الاختراقات التي جمعها المجتمع وقام بتطويرها لنا على مر السنين.

من المهم جدًا ملاحظة أن Zsh لنظام التشغيل Linux و Mac وحتى لنظام التشغيل Windows .

قم بتثبيت Zsh و Oh My Zsh

قم بتثبيت Zsh و Oh My Zsh وفقًا للتعليمات بأمر واحد:

 # macOS brew install zsh zsh-completions && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)" # Ubuntu, Debian, ... apt install zsh && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)" 

نظرًا لأن المهمة هي تحسين التفاعل مع Zsh ، Zsh من المكونات الإضافية إلى Zsh . افتح ~/.zshrc وأضف plugins إلى القائمة:

 plugins=(git gitfast) 

المجموع:

• git - مجموعة من الأسماء المستعارة والوظائف المساعدة ؛
• gitfast - إكمال تلقائي محسن لـ Gita.

إعداد tig

واللمسة الأخيرة هي تثبيت أداة tig console:

 # macOS brew install tig # Ubuntu, Debian, ... # https://jonas.imtqy.com/tig/INSTALL.html 

سنتحدث عنه أكثر.

في الواقع العملي

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

تشير الكتل الصفراء إلى الاسم المستعار الرئيسي لحل المشكلة من القسم. تعلم فقط ، واترك كل شيء آخر للتطوير العام.

تحقق من حالة دليل العمل

لنبدأ بأبسط شيء. لقد قمنا بعمل قليل والآن دعونا نرى ما يحدث في دليل العمل:

 $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: e.md 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: b.md Untracked files: (use "git add <file>..." to include in what will be committed) d.md 

يتم وصف الحالة الحالية لجميع الملفات بتفصيل كبير ، ويتم إعطاء تعليمات إضافية للعمل. إنه مفيد للغاية في البداية عند استخدام Geeta ، ولكن هناك الكثير من العمل غير الضروري. دعنا نخفض مستوى الضوضاء باستخدام مفاتيح إضافية:

 $ git status -sb ## master M b.md A e.md ?? d.md 

نعم ، نحن في الفرع master ، b.md بتغيير ملف b.md ( M-odified ) M-odified ملفين ، بإضافة الملف الأول إلى فهرس Geeta ( A-dded ) ، وترك الثاني خارج الفهرس ( ?? ). قصير وواضح.

يبقى تحسين المدخلات اللامتناهية لهذا الأمر من خلال الاسم المستعار " g it s tatus with b ranch" :

إظهار حالة دليل العمل المختصرة

 $ gsb # git status -sb 

إنشاء التزام

نواصل.

بالطبع ، يمكنك القيام بارتكاب. ولكن دعونا نحاول تحسين حل هذه المهمة البسيطة. أضف جميع التغييرات إلى الفهرس بالاسم المستعار " g it a dd a ll" :

 $ gaa # git add --all 

نتحقق من أن الفهرس حصل بالضبط على ما نحتاج إليه باستخدام الاسم المستعار " g it d iff ca ched" :

 $ gdca # git diff --cached diff --git a/b.md b/b.md index 698d533..cf20072 100644 --- a/b.md +++ b/b.md @@ -1,3 +1,3 @@ # Beta -Next step. +Next step really hard. diff --git a/d.md b/d.md new file mode 100644 index 0000000..9e3752e --- /dev/null +++ b/d.md @@ -0,0 +1,3 @@ +# Delta + +Body of article. 

حسنًا ، يجب أن تقع التغييرات التي تحل مهمة واحدة في التزام واحد. هنا ، لا ترتبط التغييرات في كلا الملفين بأي شكل من الأشكال. d.md ملف d.md من الفهرس d.md المستعار " g it r eset u ndo" :

 $ gru d.md # git reset -- d.md 

وإنشاء التزام باستخدام الاسم المستعار " g it c ommit" :

 $ gc # git commit 

نكتب اسم الالتزام وحفظها. ثم ننشئ التزامًا آخر لملف d.md باستخدام أمر أكثر دراية باستخدام الاسم المستعار " g it c ommit m e s sa g e" :

 $ gaa #    $ gcmsg "Add new file" # git commit -m "Add new file" 

ويمكننا ...

... الالتزام بالملفات المعدلة من الفهرس بأمر واحد:

 $ gcam "Add changes" # git commit -a -m "Add changes" 

... شاهد التغييرات بالكلمات بدلاً من السطور (مفيدة جدًا عند العمل مع النص):

 $ gdw # git diff --word-diff 

... إضافة ملفات في أجزاء (مفيدة جدًا عندما تحتاج إلى الإضافة إلى جزء الالتزام فقط من التغييرات من الملف):

 $ gapa # git add --patch 

... إضافة إلى الفهرس فقط الملفات الموجودة تحت إشراف جيتا:

 $ gau # git add --update 

المجموع:

إضافة إلى فهرس / إنشاء التزام

 $ ga # git add $ gc # git commit 

الالتزام الالتزام

لا يوضح اسم آخر التزام التغييرات التي قمنا بها. دعونا إعادة صياغة:

 $ gc! # git commit -v --amend 

وفي محرر النص الذي يفتح ، سنطلق عليه اسمًا أكثر وضوحًا: "Add Delta article" . أنا متأكد من أنك لا تستخدم أبدًا مفتاح التبديل -v ، على الرغم من أنه عند تعديل وصف الالتزام ، فإنه يعرض جميع التغييرات التي تم إجراؤها ، مما يساعد على التنقل بشكل أفضل.

ويمكننا ...

... قم بإجراء تغييرات على ملف الالتزام ، ولكن لا تلمس الوصف:

 $ gcn! # git commit -v --no-edit --amend 

... قم بإجراء جميع التغييرات على الملف فورًا ، دون إضافة إلى الفهرس أولاً:

 $ gca! # git commit -v -a --amend 

... الجمع بين الأمرين السابقين:

 $ gcan! # git commit -v -a --no-edit --amend 

حسنًا ، من المهم أن نلاحظ مرة أخرى أنه بدلاً من كتابة الأمر git commit -v --amend المستخدم بالكامل والمستخدم بانتظام ، نكتب ثلاثة أحرف فقط:

تغيير الالتزام الأخير

 $ gc! # git commit -v --amend 

الشروع في ميزة جديدة

إنشاء فرع جديد من الاسم المستعار الحالي " g it c heckout b ranch" :

 $ gcb erlang # git checkout --branch erlang 

على الرغم من لا ، من الأفضل كتابة مقال عن لغة أكثر حداثة من قبل Elixir alias " g it b ranch with the key m ove" (تتم إعادة التسمية في Gita من خلال move ):

 $ gb -m elixir # git branch -m elixir 

سيكون من المنطقي استخدام الاسم المستعار gbmv ، ولكن للأسف ، لم يتم اختراعه بعد. خيار جيد للمساهمة.

نجري تغييرات على المستودع وننشئ التزامًا ، كما نعلم بالفعل:

 $ echo "#  —     ." > e.md $ gaa && gcmsg "Add article about Elixir" 

وتذكر:

إنشاء فرع جديد

 $ gcb # git checkout --branch 

دمج التغييرات

الآن نضيف مقالنا الجديد حول إكسير master . أولاً ، انتقل إلى الفرع الرئيسي بالاسم المستعار " g it c heckout m aster" :

 $ gcm # git checkout master 

لا حقا. أحد الأوامر الأكثر استخدامًا في ثلاثة أحرف سهلة التذكر. الآن mergim لتغيير الاسم المستعار هو " g it m erge" :

 $ gm elixir # git merge elixir 

عفوًا ، لكن شخصًا ما تمكن بالفعل من إجراء تغييرات master . وبدلاً من التاريخ الخطي الجميل الذي تم تبنيه في مشروعنا ، قمت بإنشائه مكروه دمج الدمج.

دمج الفروع

 $ gm # git merge 

حذف الالتزام الأخير

لا داعي للقلق! ما عليك سوى حذف آخر التزام ومحاولة دمج التغييرات مرة أخرى " g it r eset hh ard" :

حذف الالتزام الأخير

 $ grhh HEAD~ # git reset --hard HEAD~ 

نحن نحل النزاعات

يتم تنفيذ تسلسل checkout – rebase – merge القياسي checkout – rebase – merge لإعداد سجل التغييرات الخطية من خلال التسلسل التالي للأسماء المستعارة:

 gco elixir # git checkout elixir grbm # git rebase master gcm # git checkout master gm elixir # git merge elixir 

كلهم يستخدمون في كثير من الأحيان لدرجة أنهم يطيرون بالفعل بعيدًا عن الأصابع ، وعند القيام بمثل هذه العمليات ، ليست هناك حاجة للتفكير في مجموعة الحروف التي يجب كتابتها. ولا تنس أنه في Zsh يمكنك استكمال أسماء الفروع بمفتاح Tab .

اصنع ريبس

 $ grb # git rebase 

إرسال التغييرات إلى الخادم

أولاً نضيف origin بالاسم المستعار " g it r emote a dd" :

 $ gra origin git@github.com/... # git remote add origin git@github.com/... 

ثم نرسل التغييرات مباشرة إلى الفرع الحالي من المستودع ( "gg" - مضاعفة g في بداية الأمر تشير إلى تنفيذ الإجراء في الفرع الحالي):

 $ ggpush # git push origin git_current_branch 

يمكنك أيضًا ...

... إرسال التغييرات إلى الخادم مع التثبيت المسبق للاسم المستعار " g it p ush s et up up " :

 $ gpsup # git push --set-upstream origin $(git_current_branch) 

إرسال التغييرات إلى الخادم

 $ gp # git push 

نتلقى تغييرات من الخادم

العمل على قدم وساق. تمكنا من إضافة مقال جديد f.md master ، وقام زملائنا بتغيير المقالة a.md وإرسال هذا التغيير إلى الخادم. يتم حل هذه الحالة أيضًا بكل بساطة:

 $ gup # git pull --rebase 

ثم يمكنك إرسال التغييرات بأمان إلى الخادم. تم تسوية الصراع.

احصل على التغييرات من الخادم

 $ gl # git pull 

حذف الفروع المدمجة

لذا ، نجحنا في دمج عدة فروع في master ، بما في ذلك فرع elixir من المثال السابق. نحن لسنا بحاجة إليها بعد الآن. يمكنك إزالة الاسم المستعار " g it b ranch d elete a nother" :

 $ gbda # git branch --no-color --merged | command grep -vE "^(\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d 

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

إنشاء التزام مؤقت

العمل على مقال h.md جديد عن هاسكل على قدم وساق. نصف مكتوب وتحتاج إلى الحصول على تعليقات من زميل. بدون التفكير مرتين ، نكتب الاسم المستعار " g it w ork i n p rogress" :

 $ gwip # git add -A; git rm $(git ls-files --deleted) 2> /dev/null; git commit --no-verify -m "--wip-- [skip ci]" 

ثم يتم إنشاء الالتزام باسم Work in Progress ، وتخطي CI وحذف الملفات "الإضافية". نرسل الفرع إلى الخادم ، ونتحدث عن هذا الزميل وننتظر المراجعة.

ثم يمكن التراجع عن هذا الالتزام وعودة الملفات إلى حالتها الأصلية:

 $ gunwip # git log -n 1 | grep -q -c "\-\-wip\-\-" && git reset HEAD~1 

وللتحقق من وجود عمليات WIP في الفرع الخاص بك ، استخدم الأمر:

 $ work_in_progress 

يعد أمر gwip موثوقًا إلى حد ما gwip عندما تحتاج إلى التبديل إلى فرع مجاور. ولكن في Zsh هناك العديد من الأسماء المستعارة Zsh نفسها.

إضافة التزام مؤقت / إعادة تعيين التزام مؤقت

 $ gwip $ gunwip 

إخفاء التغييرات

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

دعنا نخفي الملفات التي نعمل عليها باستخدام الاسم المستعار g it st ash ll alias:

 $ gsta # git stash save 

ثم أعدها مرة أخرى بالاسم المستعار " g it st ash p op" :

 $ gstp # git stash pop 

أو طريقة " g it st ash a ll a pply" الأكثر أمانًا:

 $ gstaa # git stash apply 

يمكنك أيضًا ...

... انظر ماذا أخبئنا بالضبط:

 gsts # git stash show --text 

... استخدم الاختصارات للأوامر ذات الصلة:

 gstc # git stash clear gstd # git stash drop gstl # git stash list 

إخفاء التغييرات / الحصول على التغييرات

 $ gsta $ gstaa 

تبحث عن خطأ

أداة git-bisect ، التي أنقذت حياتي بشكل متكرر ، لها أيضًا أسماء مستعارة خاصة بها. نبدأ ببدء إجراء "البحث عن الأخطاء الثنائية" بالاسم المستعار " g it b i s ect s tart" :

 $ gbss # git bisect start 

نلاحظ أن الالتزام الحالي ، الأخير في الفرع ، يحتوي على خطأ بالاسم المستعار " g it b i s ect b ad" :

 $ gbsb # git bisect bad 

الآن نحتفل بالالتزام الذي يضمن لنا الحالة التشغيلية للتطبيق " g it b i s ect g ood" :

 $ gbsg HEAD~20 # git bisect good HEAD~20 

والآن يبقى الاستمرار في الإجابة على أسئلة جيتا بعبارات gbsb أو gbsg ، وبعد العثور على الجاني ، قم بإعادة ضبط الإجراء:

 $ gbsr # git bisect reset 

وأنا بالفعل أكتب هذه الاختصارات عند استخدام هذه الأداة.

خطأ في الالتزام بالبحث

 $ gbss # git bisect start $ gbsb # git bisect bad $ gbsg # git bisect good $ gbsr # git bisect reset 

نحن نبحث عن المحرض على انعدام القانون

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

 $ gbl a.md -L 2 # git blame -b -w a.md -L 2 

كما ترون ، Oh My Zsh المساهمون في Oh My Zsh اسمًا مستعارًا ليس فقط لفريق git blame ، ولكن أضافوا مفاتيح إليه تجعل من السهل العثور على المحرض مباشرة.

مكافأة

عرض قائمة الالتزامات

لعرض قائمة الالتزامات ، استخدم الأمر git log مع مفاتيح تنسيق إخراج إضافية. عادة يتم إدخال هذا الأمر ، مع المفاتيح ، في الأسماء المستعارة المخصصة لـ Gita. نحن أكثر حظًا ، لدينا بالفعل اسم مستعار جاهز خارج الصندوق: glog . وإذا قمت بتثبيت أداة tig المساعدة بناء على نصيحة من بداية المقال ، فأنت بطل مطلق.

الآن ، لتعلم تاريخ الالتزامات في وحدة التحكم بطريقة مريحة للغاية ، تحتاج إلى كتابة كلمة git والعكس بالعكس:

 $ tig 

توفر الأداة المساعدة أيضًا بضع إضافات مفيدة غير موجودة في Gita خارج الصندوق.

أولاً ، أمر بالبحث في محتويات القصة:

 $ tig grep 

ثانيًا ، عرض قائمة بجميع المصادر والفروع والعلامات جنبًا إلى جنب مع تاريخها:

 $ tig refs 

ثالثًا ، ربما ستجد شيئًا مثيرًا للاهتمام لنفسك:

 $ tig --help 

git reset --hard الخطأ - git reset --hard

لقد عملت في فرع elixir طوال اليوم:

 $ glog * 17cb385 (HEAD -> elixir) Refine Elixir article * c14b4dc Add article about Elixir * db84d54 (master) Initial commit 

وفي النهاية ، حذفوا كل شيء عن طريق الخطأ:

 $ grhh HEAD~2 HEAD is now at db84d54 Initial commit 

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

دعونا نلقي نظرة على إعادة تسجيل الدخول ، ولكن ليس بالطريقة المعتادة من خلال إعادة تسجيل الدخول إلى git reflog ، ولكن أكثر إثارة للاهتمام مع نص مفصل:

 $ glg -g 

البحث عن تجزئة الالتزام 17cb385 المطلوب واستعادته:

 #           $ gcb elixir-recover 17cb385 #    $ gbd elixir #     $ gb -m elixir 

عن طريق الصدفة ، بدلاً من إنشاء التزام جديد ، قمت بإجراء تغييرات على السابق

هنا مرة أخرى نأتي إلى مساعدة الانقاذ. نجد تجزئة الالتزام 17cb385 الأصلي ، إذا قمنا بإلغاء الالتزام على الفور ، فبدلاً من البحث عن التجزئة ، يمكننا استخدام الرابط السريع لها HEAD@{1} . بعد ذلك ، نقوم بإعادة تعيين بسيطة ، بينما لا تتم إعادة تعيين الفهرس:

 #      $ grh --soft HEAD@{1} # git reset -soft #   $ gcmsg "Commit description" 

الفرع قديم جدا

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

دعونا نلقي نظرة على مثال لفرع ميزة يسمى elixir :

 #   master $ gcm # git checkout master #        $ gcb elixir-new # git checkout --branch elixir-new #           $ gcp elixir@{0} # git cherry-pick elixir@{0} 

لذا ، بدلاً من محاولة تحديث الفرع ، نأخذ وننقل التزامًا واحدًا دون أي مشاكل.

إزالة البيانات الهامة من المستودع

لحذف بيانات مهمة من المستودع ، قمت بحفظ المقتطف التالي:

 $ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <path-to-your-file>' --prune-empty --tag-name-filter cat -- --all && git push origin --force --all 

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

الرجوع إلى الفرع السابق

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

 $ gco - # git checkout - $ gm - # git merge - $ grb - # git rebase - 

احذف جميع الملفات المميزة بعلامة .gitignore

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

 $ gclean -X # git clean -Xfd 

كن حذرا!

تابع القراءة للطريقة الصحيحة.

لماذا تحتاج العديد من الفرق إلى مفتاح --dry-run ؟

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

الخلاصة

توضح المقالة نقطة لتحسين عمل المبرمج. تذكر أن 10-20 اختصارات مفيدة ليست صعبة ، انس الفريق الأصلي يكاد يكون مستحيلاً. يتم توحيد الأسماء المستعارة ، لذلك عند تبديل الفريق بأكمله إلى Zsh + Oh My Zsh ، يمكنك العمل بنفس السرعة والراحة ، حتى مع البرمجة الزوجية.

إلى أين أذهب بعد ذلك؟

أقدم الخيارات التالية:

1. أخيرًا ، اكتشف كيف يتم ترتيب الجيت في الداخل . من المفيد أن تفهم ما تفعله ولماذا لا يعمل ما تريد القيام به.
2. لا تكن كسولًا للنظر مرة أخرى في وثائق الأوامر: git --help أو ghh .
3. انظر القائمة الكاملة للأسماء المستعارة على الرابط . محاولة تذكرها كلها مجنونة ، ولكن استخدام القائمة كمجموعة من الأوامر والمفاتيح المثيرة للاهتمام لها فكرة جيدة.

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

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