الشروع في العمل مع Git: دليل شامل للمبتدئين

بدلاً من المقدمة

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

أساسيات جيت

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

تثبيت جيت

لنقم بتثبيت Java على جهاز الكمبيوتر الخاص بك.

التثبيت على ويندوز

كالعادة، تحتاج إلى تنزيل ملف exe وتشغيله. كل شيء بسيط هنا: انقر على رابط Google الأول ، وقم بإجراء التثبيت، وهذا كل شيء. للقيام بذلك، سوف نستخدم وحدة التحكم bash التي يوفرها Windows. على نظام التشغيل Windows، تحتاج إلى تشغيل Git Bash. إليك كيف تبدو في قائمة "ابدأ": الآن هذا هو موجه الأوامر الذي يمكنك العمل معه. لتجنب الاضطرار إلى الانتقال إلى المجلد الذي يحتوي على المشروع في كل مرة لفتح Git هناك، يمكنك فتح موجه الأوامر في مجلد المشروع باستخدام زر الفأرة الأيمن بالمسار الذي نحتاجه:

التثبيت على لينكس

عادةً ما يكون Git جزءًا من توزيعات Linux وهو مثبت بالفعل، نظرًا لأنه أداة تمت كتابتها في الأصل لتطوير Linux kernel. ولكن هناك حالات عندما لا يكون الأمر كذلك. للتحقق، تحتاج إلى فتح محطة وكتابة: git --version. إذا حصلت على إجابة واضحة، فلا يلزم تثبيت أي شيء. افتح محطة طرفية وقم بتثبيت Git على Ubuntu . أنا أعمل على Ubuntu، لذا يمكنني أن أخبرك بما ستكتب له: sudo apt-get install git.

التثبيت على نظام التشغيل MacOS

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

إعدادات جيت

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

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

إذا كنت بحاجة إلى تغيير المؤلف لمشروع معين، فيمكنك إزالة "--global". وهذا سيعطينا ما يلي:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

قليلا من النظرية ...

للتعمق في الموضوع، يجب أن نقدم لك بعض الكلمات والأفعال الجديدة...

• مستودع بوابة
• يقترف
• فرع
• دمج
• الصراعات
• يحذب
• يدفع
• كيفية تجاهل بعض الملفات (.gitignore)

وما إلى ذلك وهلم جرا.

الحالات في جيت

لدى Git العديد من التماثيل التي يجب فهمها وتذكرها:

• غير متعقب
• معدل
• نظموا
• ملتزم

كيف يجب أن تفهم هذا؟

هذه هي الحالات التي تنطبق على الملفات التي تحتوي على الكود الخاص بنا:

1. الملف الذي تم إنشاؤه ولكن لم يتم إضافته بعد إلى المستودع يكون بالحالة "غير متعقب".
2. عندما نقوم بإجراء تغييرات على الملفات التي تمت إضافتها بالفعل إلى مستودع Git، تكون حالتها "معدلة".
3. من بين الملفات التي قمنا بتغييرها، نختار الملفات التي نحتاجها، ويتم تغيير هذه الفئات إلى الحالة "المرحلية".
4. يتم إنشاء الالتزام من الملفات المعدة في الحالة المرحلية وينتقل إلى مستودع Git. بعد ذلك، لا توجد ملفات بالحالة "المرحلة". ولكن قد تظل هناك ملفات حالتها "معدلة".

وهنا ما يبدو:

ما هو الالتزام؟

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

• المعرف الفريد للالتزام، والذي يمكن استخدامه للعثور عليه
• اسم مؤلف الالتزام الذي قام بإنشائه
• تاريخ إنشاء الالتزام
• تعليق يصف ما تم القيام به أثناء الالتزام

وهنا كيف يبدو:

ما هو الفرع؟

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

الشروع في العمل مع جيت

يمكنك العمل مع مستودع محلي بمفردك وكذلك مع مستودع بعيد. لممارسة الأوامر المطلوبة، يمكنك قصر نفسك على المستودع المحلي. يقوم فقط بتخزين جميع معلومات المشروع محليًا في المجلد .git. إذا كنا نتحدث عن المستودع البعيد، فسيتم تخزين جميع المعلومات في مكان ما على الخادم البعيد: يتم تخزين نسخة من المشروع محليًا فقط. يمكن دفع التغييرات التي تم إجراؤها على نسختك المحلية (git Push) إلى المستودع البعيد. في مناقشتنا هنا وأدناه، نتحدث عن العمل مع Git في وحدة التحكم. بالطبع، يمكنك استخدام نوع ما من الحلول المستندة إلى واجهة المستخدم الرسومية (على سبيل المثال، IntelliJ IDEA)، ولكن يجب عليك أولاً معرفة الأوامر التي يتم تنفيذها وماذا تعني.

العمل مع Git في مستودع محلي

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

git init

سيؤدي هذا إلى إنشاء مجلد .git في الدليل الحالي لوحدة التحكم. يقوم المجلد .git بتخزين جميع المعلومات حول مستودع Git. لا تحذفه؛) بعد ذلك، تتم إضافة الملفات إلى المشروع، ويتم تعيينها بالحالة "غير متعقب". للتحقق من الوضع الحالي لعملك، اكتب هذا:

git status

نحن في الفرع الرئيسي وسنبقى هنا حتى نتحول إلى فرع آخر. يعرض هذا الملفات التي تم تغييرها ولكن لم تتم إضافتها بعد إلى الحالة "المرحلة". لإضافتها إلى الحالة "المرحلية"، تحتاج إلى كتابة "git add". لدينا بعض الخيارات هنا، على سبيل المثال:

• git add -A - أضف جميع الملفات إلى الحالة "المرحلية".
• إضافة بوابة . - إضافة كافة الملفات من هذا المجلد وجميع المجلدات الفرعية. في الأساس، هذا هو نفس السابق
• git add <اسم الملف> - يضيف ملفًا محددًا. هنا يمكنك استخدام التعبيرات العادية لإضافة ملفات وفقًا لنمط ما. على سبيل المثال، git add *.java: هذا يعني أنك تريد فقط إضافة الملفات ذات ملحق Java.

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

git add *.txt

للتحقق من الحالة، نستخدم الأمر المعروف لنا بالفعل:

git status

هنا يمكنك أن ترى أن التعبير العادي يعمل بشكل صحيح: test_resource.txt أصبح الآن بالحالة "مرحلية". وأخيرًا، المرحلة الأخيرة للعمل مع مستودع محلي (هناك مرحلة أخرى عند العمل مع المستودع البعيد؛)) - إنشاء التزام جديد:

git commit -m "all txt files were added to the project"

التالي هو أمر رائع للنظر في سجل الالتزام على الفرع. دعونا نستفيد منه:

git log

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

git status

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

git status

هنا يمكنك أن ترى بوضوح الفرق بين الحالة "غير المتعقبة" والحالة "المعدلة". GitTest.java "غير متتبع"، بينما "test_resource.txt" "معدل". الآن بعد أن أصبح لدينا ملفات في الحالة المعدلة، يمكننا فحص التغييرات التي تم إجراؤها عليها. يمكن القيام بذلك باستخدام الأمر التالي:

git diff

وهذا يعني أنه يمكنك هنا أن ترى بوضوح ما أضفته إلى ملفنا النصي: مرحبًا بالعالم! دعونا نضيف تغييراتنا إلى الملف النصي وننشئ التزامًا:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

لإلقاء نظرة على جميع الالتزامات، اكتب:

git log

كما ترون، لدينا الآن التزامان. سنضيف GitTest.java بنفس الطريقة. لا توجد تعليقات هنا، فقط الأوامر:

git add GitTest.java
git commit -m "added GitTest.java"
git status

العمل مع .gitignore

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

```
*.class
target/
*.iml
.idea/
```

لنلقي نظرة:

• السطر الأول هو تجاهل كافة الملفات ذات الامتداد .class
• السطر الثاني هو تجاهل مجلد "الهدف" وكل ما يحتوي عليه
• السطر الثالث هو تجاهل كافة الملفات ذات الامتداد .iml
• السطر الرابع هو تجاهل المجلد .idea

دعونا نحاول استخدام مثال. لنرى كيف يعمل، دعونا نضيف GitTest.class المترجمة إلى المشروع ونتحقق من حالة المشروع:

git status

من الواضح أننا لا نريد إضافة الفئة المترجمة بطريقة أو بأخرى إلى المشروع (باستخدام git add -A). للقيام بذلك، قم بإنشاء ملف .gitignore وأضف كل ما تم وصفه مسبقًا: الآن دعنا نستخدم التزامًا لإضافة ملف .gitignore إلى المشروع:

git add .gitignore
git commit -m "added .gitignore file"

والآن لحظة الحقيقة: لدينا فئة مجمعة GitTest.class "غير متعقبة"، والتي لا نريد إضافتها إلى مستودع Git. الآن يجب أن نرى تأثيرات ملف .gitignore:

git status

ممتاز! .جيتينور +1 :)

العمل مع الفروع وما شابه

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

git branch -a

يمكنك أن ترى أن لدينا فرعًا رئيسيًا واحدًا فقط. النجمة التي أمامه تشير إلى أننا فيه. بالمناسبة، يمكنك أيضًا استخدام الأمر "git Status" لمعرفة الفرع الذي نحن فيه. ثم هناك عدة خيارات لإنشاء الفروع (قد يكون هناك المزيد - هذه هي الخيارات التي أستخدمها):

• إنشاء فرع جديد بناءً على الفرع الذي نحن فيه (99% من الحالات)
• إنشاء فرع بناءً على التزام محدد (1% من الحالات)

لنقم بإنشاء فرع بناءً على التزام محدد

سوف نعتمد على المعرف الفريد للالتزام. وللبحث عنه نكتب:

git log

لقد سلطت الضوء على الالتزام بالتعليق "تمت إضافة مرحبًا بالعالم..." المعرف الفريد الخاص به هو 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. أريد إنشاء فرع "تطوير" يبدأ من هذا الالتزام. وللقيام بذلك أكتب:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

وكما هو متوقع، لدينا التزامان. بالمناسبة، إليك نقطة مثيرة للاهتمام: لا يوجد ملف .gitignore في هذا الفرع حتى الآن، لذلك تم تمييز ملفنا المترجم (GitTest.class) الآن بالحالة "غير متعقب". والآن يمكننا مراجعة فروعنا مرة أخرى بكتابة هذا:

git branch -a

يمكنك أن ترى أن هناك فرعين: "الرئيسي" و"التطوير". نحن حاليا في التنمية.

لنقم بإنشاء فرع بناءً على الفرع الحالي

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

• git checkout master — قم بالتبديل إلى الفرع الرئيسي
• حالة git — تحقق من أننا موجودون بالفعل في الفرع الرئيسي

هنا يمكنك أن ترى أننا قمنا بالتبديل إلى الفرع الرئيسي، وأن الملف .gitignore ساري المفعول، ولم يعد يتم تمييز الفئة المترجمة على أنها "غير متعقبة". الآن نقوم بإنشاء فرع جديد يعتمد على الفرع الرئيسي:

git checkout -b feature/update-txt-files

إذا لم تكن متأكدًا مما إذا كان هذا الفرع هو نفس الفرع "الرئيسي"، فيمكنك التحقق بسهولة من خلال تنفيذ "سجل git" والنظر في جميع الالتزامات. يجب أن يكون هناك أربعة منهم.

حل الصراع

قبل أن نستكشف ما هو الصراع، نحتاج أن نتحدث عن دمج فرع في آخر. هذه الصورة توضح عملية دمج فرع في آخر: هنا، لدينا فرع رئيسي. في مرحلة ما، يتم إنشاء فرع ثانوي خارج الفرع الرئيسي ثم يتم تعديله. بمجرد الانتهاء من العمل، نحتاج إلى دمج فرع واحد في الآخر. لن أصف الميزات المختلفة: في هذه المقالة، أريد فقط أن أنقل فهمًا عامًا. إذا كنت بحاجة إلى التفاصيل، يمكنك البحث عنها بنفسك. في مثالنا، قمنا بإنشاء فرع feature/update-txt-files. كما هو موضح باسم الفرع، نقوم بتحديث النص. نحن الآن بحاجة إلى إنشاء التزام جديد لهذا العمل:

git add *.txt 
git commit -m "updated txt files"
git log

الآن، إذا أردنا دمج فرع feature/update-txt-files في الفرع الرئيسي، فعلينا الانتقال إلى master وكتابة "git merge feature/update-txt-files":

git checkout master
git merge feature/update-txt-files
git log

ونتيجة لذلك، يتضمن الفرع الرئيسي الآن أيضًا الالتزام الذي تمت إضافته إلى ملفات feature/update-txt. تمت إضافة هذه الوظيفة، بحيث يمكنك حذف فرع الميزة. وللقيام بذلك نكتب:

git branch -D feature/update-txt-files

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

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

انتقل إلى الفرع الرئيسي وقم أيضًا بتحديث هذا الملف النصي على نفس السطر الموجود في فرع الميزات:

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

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

git merge feature/add-header

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

1. تم العثور على التغييرات التي كانت على هذا السطر في الفرع الرئيسي بين "<<<<<<< HEAD" و"=======".
2. تم العثور على التغييرات التي كانت في فرع الميزة/الرأس الإضافي بين "=======" و">>>>>>> الميزة/الرأس الإضافي".

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

git status

يمكننا أن نقنع أنفسنا بأن هذه حالة خاصة وغير عادية. فلنكمل:

git add *.txt

قد تلاحظ أن الوصف يقترح كتابة "git Commit" فقط. دعونا نحاول كتابة ذلك:

git commit

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

العمل مع المستودعات البعيدة

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

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

• GitLab هي أداة قائمة على الويب لدورة حياة DevOps مفتوحة المصدر . إنه نظام قائم على Git لإدارة مستودعات التعليمات البرمجية باستخدام موقع wiki الخاص به ونظام تتبع الأخطاء وخط أنابيب CI/CD ووظائف أخرى.
  بعد أنباء شراء Microsoft لـ GitHub، قام بعض المطورين بتكرار مشاريعهم في GitLab.

• BitBucket هي خدمة ويب لاستضافة المشاريع والتطوير التعاوني استنادًا إلى أنظمة التحكم في إصدار Mercurial وGit. في وقت من الأوقات كانت تتمتع بميزة كبيرة على GitHub من حيث أنها توفر مستودعات خاصة مجانية. في العام الماضي، قدم GitHub أيضًا هذه الإمكانية للجميع مجانًا.

• وما إلى ذلك وهلم جرا…

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

git clone https://github.com/romankh3/git-demo

توجد الآن نسخة محلية كاملة من المشروع. للتأكد من أن النسخة المحلية من المشروع هي الأحدث، عليك سحب المشروع عن طريق كتابة:

git pull

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

git add test_resource.txt
git commit -m "prepared txt for pushing"

الأمر لدفع هذا إلى المستودع البعيد هو:

git push

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

رابط مفيد

• وثائق جيت الرسمية . أوصي به كمرجع.