إليك جميع أوامر Git التي استخدمتها الأسبوع الماضي ، وماذا تفعل.

مثل معظم المبتدئين ، بدأت في البحث في StackOverflow عن أوامر Git ، ثم نسخ الإجابات ولصقها ، دون فهم ما فعلوه حقًا.

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

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

لإبقاء الأمور عملية ، أقوم بوضع هذه القائمة على أساس أوامر Git الفعلية التي استخدمتها خلال الأسبوع الماضي.

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

git add --allgit commit -am ""git push origin master

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

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

أوامر مستخدمة بانتظام

لتهيئة Git في مستودع (repo) ، ما عليك سوى كتابة الأمر التالي. إذا لم تقم بتهيئة Git ، فلا يمكنك تشغيل أي أوامر Git أخرى داخل هذا الريبو.

git init

إذا كنت تستخدم GitHub وكنت تدفع رمزًا إلى مستودع GitHub المخزن عبر الإنترنت ، فأنت تستخدم الريبو عن بُعد . الاسم الافتراضي (المعروف أيضًا باسم الاسم المستعار) لهذا الريبو البعيد هو الأصل . إذا قمت بنسخ مشروع من Github ، فإن له أصل بالفعل . يمكنك عرض هذا الأصل باستخدام الأمر git remote -v ، والذي سيدرج عنوان URL الخاص بالريبو البعيد.

إذا قمت بتهيئة Git repo الخاص بك وتريد إقرانه بـ GitHub repo ، فسيتعين عليك إنشاء واحد على GitHub ، ونسخ عنوان URL المقدم ، واستخدام الأمر git remote add origin RL> ، مع استبدال عنوان URL المقدم من GitHub بـ "". من هناك ، يمكنك الإضافة والتنفيذ والدفع إلى الريبو البعيد الخاص بك.

يتم استخدام آخر واحد عندما تحتاج إلى تغيير المستودع البعيد. لنفترض أنك قمت بنسخ الريبو من شخص آخر وتريد تغيير المستودع البعيد من المالك الأصلي إلى حساب GitHub الخاص بك. اتبع نفس العملية مثل git remote add origin ، باستثناء استخدام set-url بدلاً من ذلك لتغيير الريبو البعيد.

git remote -vgit remote add origin git remote set-url origin 

الطريقة الأكثر شيوعًا لنسخ الريبو هي استخدام git clone ، متبوعًا بعنوان URL الخاص بالريبو.

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

git clone 

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

يسرد الأمر git Branch جميع الفروع الموجودة على جهازك المحلي. إذا كنت ترغب في إنشاء فرع جديد ، يمكنك استخدام فرع git أنا> ، مع & lt ؛ name> يمثل اسم الفرع ، مثل "رئيسي".

و الخروج الجهاز الهضمي لي> يتحول الأمر إلى فرع موجود. يمكنك أيضًا استخدام الأمر git checkout -b & lt؛ name> لإنشاء فرع جديد والتبديل إليه فورًا. يستخدم معظم الناس هذا بدلاً من أوامر الفروع والسحب المنفصلة.

git branchgit branch git checkout git checkout -b 

إذا أجريت مجموعة من التغييرات على أحد الفروع ، فلنسميها "تطوير" ، وتريد دمج هذا الفرع مرة أخرى في الفرع الرئيسي ، يمكنك استخدام git merge

ch> الأمر. ستنتقل إلى ch eckout الفرع الرئيسي ، و n run git merge develop لدمجها في الفرع الرئيسي.

git merge 

إذا كنت تعمل مع عدة أشخاص ، فستجد نفسك في وضع تم فيه تحديث الريبو على GitHub ، لكن ليس لديك التغييرات محليًا. إذا كان الأمر كذلك ، فيمكنك استخدام أصل git pull

ch> لسحب أحدث التغييرات من ذلك الفرع البعيد.

git pull origin 

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

git statusgit diff --stat

أوامر متقدمة وأفضل الممارسات

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

و سجل بوابة يتيح الأمر الذي نرى ارتكاب التاريخ. سترغب في استخدام هذا لمشاهدة محفوظات التزاماتك.

ستأتي التزاماتك برسائل وتجزئة ، وهي سلسلة عشوائية من الأرقام والحروف. قد يبدو تجزئة المثال كالتالي: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

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

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

git checkout c3d88eaa1aa4e4d5f

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

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

git push -f origin master

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

لنفترض أن لديك 4 التزامات في سجلك المحلي (لم يتم دفعها إلى GitHub) والتي ذهبت فيها ذهابًا وإيابًا. تبدو التزاماتك قذرة وغير حاسمة. يمكنك استخدام تغيير العنوان الأساسي لدمج كل تلك الالتزامات في التزام واحد موجز.

git rebase -i HEAD~4

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

pick 130deo9 oldest commit messagepick 4209fei second oldest commit messagepick 4390gne third oldest commit messagepick bmo0dne newest commit message

من أجل الجمع بين هذه ، نحتاج إلى تغيير خيار "الانتقاء" إلى "الإصلاح" (كما تقول الوثائق الموجودة أسفل الكود) لدمج الالتزامات وتجاهل رسائل الالتزام. لاحظ أنه في vim ، تحتاج إلى الضغط على " a " أو " i " لتتمكن من تحرير النص ، وللحفظ والخروج ، تحتاج إلى كتابة مفتاح الهروب متبوعًا بـ " shift + z + z ". لا تسألني لماذا ، إنه كذلك.

pick 130deo9 oldest commit messagefixup 4209fei second oldest commit messagefixup 4390gne third oldest commit messagefixup bmo0dne newest commit message

سيؤدي هذا إلى دمج جميع التزاماتك في الالتزام بالرسالة "أقدم رسالة التزام".

The next step is to rename your commit message. This is entirely a matter of opinion, but so long as you follow a consistent pattern, anything you do is fine. I recommend using the commit guidelines put out by Google for Angular.js.

In order to change the commit message, use the amend flag.

git commit --amend

This will also open vim, and the text editing and saving rules are the same as above. To give an example of a good commit message, here’s one following the rules from the guideline:

feat: add stripe checkout button to payments page
- add stripe checkout button- write tests for checkout

One advantage to keeping with the types listed in the guideline is that it makes writing change logs easier. You can also include information in the footer (again, specified in the guideline) that references issues.

Note: you should avoid rebasing and squashing your commits if you are collaborating on a project, and have code pushed to GitHub. If you start changing version history under people’s noses, you could end up making everyone’s lives more difficult with bugs that are difficult to track.

There are an almost endless number of possible commands with Git, but these commands are probably the only ones you’ll need to know for your first few years of programming.

Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printing topographical maps, as well as LearnPhoenix.io, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React.