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

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

مرحبًا بك مهندس برمجيات المستقبل. سنتحدث اليوم عن نظام التحكم في الإصدار، وهو Git (اقرأ كـ GIT، وليس JIT، كما قد يبدو من قواعد اللغة الإنجليزية). نعم، نعم، أعلم أن هناك أيضًا Mercurial، SVN... لكن لنكن صادقين: لقد مر وقتهم بالفعل، ولن أضيع وقتك الثمين عليهم. لكي تفهم أهمية معرفة Git في عصرنا هذا، سأقول هذا: بدون معرفة/فهم هذا، لن يكون لديك ما تفعله في البرمجة. لكن الجميل في الأمر هو أنك لكي تعمل باستمرار، لا تحتاج إلى الاحتفاظ بجميع الأوامر والاحتمالات في رأسك. أنت بحاجة إلى معرفة مجموعة من الأوامر التي ستساعدك على فهم كل ما يحدث.

أساسيات جيت

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

تثبيت جيت

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

التثبيت لنظام التشغيل Windows

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

التثبيت لنظام التشغيل Linux

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

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

هنا أيضًا، تحتاج أولاً إلى التحقق مما إذا كان Git موجودًا بالفعل (انظر أعلاه، كما هو الحال في Linux). إذا لم يكن الأمر كذلك، فإن أسهل طريقة هي تنزيل أحدث إصدار. إذا تم تثبيت 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).

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

الدول في جيت

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

• غير متعقب؛
• معدل؛
• مستعد (على مراحل) ؛
• ملتزم.

ماذا يعني ذلك؟

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

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

يبدو الأمر كما يلي (صورة من الوثيقة الرسمية، لذا يمكنك الوثوق بها)):

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

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

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

هذا هو ما يبدو:

ما هو فرع

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

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

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

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

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

git init

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

git status

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

• git add -A - إضافة كافة الملفات من الحالة المرحلية؛
• إضافة بوابة . - إضافة جميع الملفات من هذا المجلد وجميع الملفات الداخلية. في الأساس نفس سابقتها؛
• git add <filename> - يضيف ملفًا محددًا فقط. هنا يمكنك استخدام التعبيرات العادية للإضافة وفقًا لبعض الأنماط. على سبيل المثال، 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

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

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، وفي هذا الملف سيكون كل سطر نموذجًا يجب تجاهله. في هذا المثال، سيبدو تجاهل git كما يلي:

```
*.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. هذا هو المكان الذي يجب أن يعمل فيه تجاهل git:

git status

كل شيء واضح) بوابة تجاهل +1)

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

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

git branch -a

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

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

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

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

git log

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

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

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

git branch -a

يمكن ملاحظة أن هناك فرعين - السيد والتطوير - ونحن الآن في مرحلة التطوير.

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

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

• git checkout master - انتقل إلى الفرع الرئيسي؛
• حالة git - تحقق مما إذا كانت موجودة على الجهاز الرئيسي.

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

git checkout -b feature/update-txt-files

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

حل النزاعات

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

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
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

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

git checkout master
… обновor 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 “prepated txt for pushing”

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

git push

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

روابط مفيدة

• الوثيقة الرسمية لـ Git موجودة باللغة الروسية . أوصي به كدليل مرجعي.
• شخص سخيف