شروع کار با Git: راهنمای جامع برای تازه کارها

به جای مقدمه

سلام! امروز قصد داریم در مورد یک سیستم کنترل نسخه، یعنی Git صحبت کنیم. اگر Git را بلد نیستید یا نمی فهمید، با برنامه نویسی کاری ندارید. اما زیبایی این است که شما مجبور نیستید تمام دستورات و ویژگی های Git را در ذهن خود نگه دارید تا بتوانید به طور مداوم از آن استفاده کنید. شما باید مجموعه ای از دستورات را بدانید که به شما کمک می کند همه چیز را درک کنید.

اصول Git

Git یک سیستم کنترل نسخه توزیع شده برای کد ما است. چرا ما به اون احتیاج داریم؟ تیم های توزیع شده به نوعی سیستم برای مدیریت کار خود نیاز دارند. برای ردیابی تغییراتی که در طول زمان رخ می‌دهند لازم است. یعنی باید بتوانیم مرحله به مرحله ببینیم کدام فایل ها و چگونه تغییر کرده اند. این امر به ویژه زمانی مهم است که در حال بررسی تغییرات در زمینه یک کار واحد هستید و امکان برگرداندن تغییرات را فراهم می کند.

نصب Git

بیایید جاوا را روی رایانه خود نصب کنیم.

نصب روی ویندوز

طبق معمول، باید یک فایل exe را دانلود و اجرا کنید. همه چیز در اینجا ساده است: روی اولین پیوند Google کلیک کنید ، نصب را انجام دهید و تمام. برای این کار از کنسول bash ارائه شده توسط ویندوز استفاده می کنیم. در ویندوز، باید Git Bash را اجرا کنید. در منوی استارت اینگونه به نظر می رسد: اکنون این یک خط فرمان است که می توانید با آن کار کنید. برای اینکه مجبور نشوید هر بار برای باز کردن Git به پوشه پروژه بروید، می توانید خط فرمان را در پوشه پروژه با دکمه سمت راست ماوس با مسیری که نیاز داریم باز کنید:

نصب روی لینوکس

معمولا Git بخشی از توزیع های لینوکس است و قبلاً نصب شده است، زیرا ابزاری است که در ابتدا برای توسعه هسته لینوکس نوشته شده بود. اما شرایطی وجود دارد که اینطور نیست. برای بررسی، باید یک ترمینال باز کنید و بنویسید: git --version. اگر پاسخ قابل فهمی دریافت کردید، پس نیازی به نصب چیزی نیست. یک ترمینال باز کنید و Git را در اوبونتو نصب کنید . من روی اوبونتو کار می کنم، بنابراین می توانم به شما بگویم که برای آن چه بنویسید: sudo apt-get install git.

نصب روی macOS

در اینجا نیز ابتدا باید بررسی کنید که آیا Git از قبل وجود دارد یا خیر. اگر آن را ندارید، ساده ترین راه برای دریافت آن این است که آخرین نسخه را از اینجا دانلود کنید . اگر Xcode نصب شده باشد، قطعاً Git به طور خودکار نصب می شود.

تنظیمات Git

Git دارای تنظیمات کاربری برای کاربری است که کار ارسال می کند. این منطقی است و ضروری است، زیرا Git این اطلاعات را برای فیلد Author هنگام ایجاد یک commit می گیرد. با اجرای دستورات زیر یک نام کاربری و رمز عبور برای تمام پروژه های خود تنظیم کنید:

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

کمی تئوری...

برای غوطه ور شدن در موضوع، باید چند حرف و عمل جدید را به شما معرفی کنیم...

• مخزن git
• مرتکب شدن
• شاخه
• ادغام
• درگیری ها
• کشیدن
• فشار دادن
• چگونه برخی از فایل ها را نادیده بگیریم (gitignore.)

و غیره.

وضعیت ها در Git

Git چندین مجسمه دارد که باید درک و به خاطر بسپارید:

• ردیابی نشده
• اصلاح شده
• صحنه سازی کرد
• متعهد شد

چگونه باید این را بفهمید؟

این ها وضعیت هایی هستند که برای فایل های حاوی کد ما اعمال می شوند:

1. فایلی که ایجاد می شود اما هنوز به مخزن اضافه نشده است وضعیت "ردیابی نشده" دارد.
2. وقتی در فایل‌هایی که قبلاً به مخزن Git اضافه شده‌اند تغییراتی ایجاد می‌کنیم، وضعیت آنها «تغییر می‌شود».
3. از بین فایل هایی که تغییر داده ایم، موارد مورد نیاز خود را انتخاب می کنیم و این کلاس ها به وضعیت "مرحله ای" تغییر می کنند.
4. یک commit از فایل های آماده شده در حالت مرحله ایجاد می شود و به مخزن Git می رود. پس از آن، هیچ فایلی با وضعیت "مرحله ای" وجود ندارد. اما ممکن است هنوز فایل هایی وجود داشته باشند که وضعیت آنها "اصلاح شده" است.

در اینجا به نظر می رسد:

تعهد چیست؟

یک commit رویداد اصلی در مورد کنترل نسخه است. این شامل تمام تغییرات ایجاد شده از زمان شروع commit است. commit ها مانند یک لیست به هم پیوسته به هم مرتبط می شوند. به طور دقیق تر: اولین commit وجود دارد. وقتی commit دوم ایجاد می شود، می داند که بعد از اولی چه می آید. و از این طریق می توان اطلاعات را ردیابی کرد. یک commit نیز اطلاعات خاص خود را دارد که اصطلاحاً ابرداده نامیده می شود:

• شناسه منحصر به فرد commit که می توان برای یافتن آن استفاده کرد
• نام نویسنده کامیت که آن را ایجاد کرده است
• تاریخ ایجاد commit
• کامنتی که آنچه را که در حین ارتکاب انجام شده است توصیف می کند

در اینجا به نظر می رسد:

شعبه چیست؟

یک شاخه نشانگر برخی از تعهدات است. از آنجا که یک commit می داند کدام commit قبل از آن است، وقتی یک شاخه به یک commit اشاره می کند، تمام آن commit های قبلی نیز برای آن اعمال می شود. بر این اساس، می‌توان گفت که شما می‌توانید به تعداد دلخواه شعبه داشته باشید که به همان commit اشاره می‌کنند. کار در شاخه‌ها اتفاق می‌افتد، بنابراین وقتی یک commit جدید ایجاد می‌شود، شاخه اشاره‌گر خود را به commit جدیدتر منتقل می‌کند.

شروع کار با Git

شما می توانید با یک مخزن محلی به تنهایی و همچنین با یک مخزن از راه دور کار کنید. برای تمرین دستورات مورد نیاز، می توانید خود را به مخزن محلی محدود کنید. فقط تمام اطلاعات پروژه را به صورت محلی در پوشه .git ذخیره می کند. اگر در مورد مخزن راه دور صحبت می کنیم، تمام اطلاعات در جایی در سرور راه دور ذخیره می شود: فقط یک کپی از پروژه به صورت محلی ذخیره می شود. تغییرات ایجاد شده در نسخه محلی شما را می توان (git push) به مخزن راه دور منتقل کرد. در بحث ما در اینجا و پایین، در مورد کار با Git در کنسول صحبت می کنیم. البته، می‌توانید از نوعی راه‌حل مبتنی بر رابط کاربری گرافیکی (مثلاً IntelliJ IDEA) استفاده کنید، اما ابتدا باید بفهمید چه دستوراتی اجرا می‌شوند و چه معنایی دارند.

کار با Git در یک مخزن محلی

در مرحله بعد، پیشنهاد می کنم که تمام مراحلی را که من انجام دادم، در حین خواندن مقاله دنبال کنید و انجام دهید. این امر درک و تسلط شما را بر مطالب بهبود می بخشد. خوب، اشتهای مبارک! :) برای ایجاد یک مخزن محلی، باید بنویسید:

git init

با این کار یک پوشه .git در دایرکتوری فعلی کنسول ایجاد می شود. پوشه .git تمام اطلاعات مربوط به مخزن Git را ذخیره می کند. آن را حذف نکنید ;) در مرحله بعد، فایل ها به پروژه اضافه می شوند و وضعیت "Untracked" به آنها اختصاص می یابد. برای بررسی وضعیت فعلی کار خود، این را بنویسید:

git status

ما در شاخه اصلی هستیم و در اینجا می مانیم تا زمانی که به شاخه دیگری سوئیچ کنیم. این نشان می دهد که کدام فایل ها تغییر کرده اند اما هنوز به وضعیت "مرحله ای" اضافه نشده اند. برای افزودن آنها به وضعیت "staged"، باید "git add" را بنویسید. ما در اینجا چند گزینه داریم، به عنوان مثال:

• git add -A - همه فایل‌ها را به وضعیت «مرحله‌ای» اضافه کنید
• git افزودن . - همه فایل‌ها را از این پوشه و همه زیرپوشه‌ها اضافه کنید. در اصل، این همان مورد قبلی است
• git add <نام فایل> - یک فایل خاص را اضافه می کند. در اینجا می توانید از عبارات منظم برای اضافه کردن فایل ها بر اساس برخی الگوها استفاده کنید. به عنوان مثال git add *.java: به این معنی است که شما فقط می خواهید فایل هایی با پسوند جاوا اضافه کنید.

دو گزینه اول به وضوح ساده هستند. همه چیز با آخرین افزوده جالب تر می شود، بنابراین بیایید بنویسیم:

git add *.txt

برای بررسی وضعیت، از دستوری که قبلاً برای ما شناخته شده است استفاده می کنیم:

git status

در اینجا می توانید ببینید که عبارت منظم به درستی کار کرده است: test_resource.txt اکنون وضعیت "staged" را دارد. و در نهایت، آخرین مرحله برای کار با یک مخزن محلی (هنگام کار با مخزن راه دور یکی دیگر وجود دارد ؛)) - ایجاد یک commit جدید:

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

در مرحله بعد یک دستور عالی برای مشاهده تاریخچه commit در یک شاخه است. بیایید از آن استفاده کنیم:

git log

در اینجا می توانید ببینید که ما اولین commit خود را ایجاد کرده ایم و شامل متنی است که در خط فرمان ارائه کرده ایم. درک این نکته بسیار مهم است که این متن باید تا حد امکان به طور دقیق توضیح دهد که در طول این تعهد چه کاری انجام شده است. این در آینده بارها به ما کمک خواهد کرد. یک خواننده کنجکاو که هنوز به خواب نرفته است ممکن است از خود بپرسد که چه اتفاقی برای فایل GitTest.java افتاده است. بیایید همین الان بفهمیم. برای این کار از:

git status

همانطور که می بینید، هنوز "ردیابی نشده" است و در بال ها منتظر است. اما اگر اصلاً نخواهیم آن را به پروژه اضافه کنیم چه؟ گاهی این اتفاق می افتد. برای جالب‌تر کردن موارد، اکنون سعی می‌کنیم فایل test_resource.txt خود را تغییر دهیم. بیایید متنی را در آنجا اضافه کنیم و وضعیت را بررسی کنیم:

git status

در اینجا می توانید به وضوح تفاوت بین وضعیت های "ردیابی نشده" و "تغییر شده" را مشاهده کنید. GitTest.java "ردیابی نشده" است، در حالی که test_resource.txt "تغییر یافته است". اکنون که فایل هایی را در حالت اصلاح شده داریم، می توانیم تغییرات ایجاد شده در آنها را بررسی کنیم. این کار را می توان با استفاده از دستور زیر انجام داد:

git diff

یعنی آنچه را که به فایل متنی خود اضافه کردم به وضوح می توانید ببینید: سلام دنیا! بیایید تغییرات خود را به فایل متنی اضافه کنیم و یک commit ایجاد کنیم:

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

برای مشاهده تمام تعهدات، بنویسید:

git log

همانطور که می بینید، اکنون دو commit داریم. به همین ترتیب 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 ایجاد کنید و هر آنچه قبلا توضیح داده شد را اضافه کنید: حالا بیایید از یک commit برای اضافه کردن فایل .gitignore به پروژه استفاده کنیم:

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

و اکنون لحظه حقیقت: ما یک کلاس کامپایل شده GitTest.class داریم که «ردیابی نشده» است، که نمی‌خواستیم آن را به مخزن Git اضافه کنیم. اکنون باید اثرات فایل .gitignore را ببینیم:

git status

کامل! .gitignore +1 :)

کار با شاخه ها و اینها

طبیعتاً کار در یک شعبه برای توسعه دهندگان انفرادی ناخوشایند است و زمانی که بیش از یک نفر در یک تیم وجود داشته باشد غیرممکن است. به همین دلیل ما شعبه داریم. همانطور که قبلاً گفتم، یک شاخه فقط یک اشاره گر متحرک برای commit است. در این بخش، کار در شاخه‌های مختلف را بررسی می‌کنیم: چگونه تغییرات را از یک شاخه به شاخه دیگر ادغام کنیم، چه تضادهایی ممکن است ایجاد شود، و بسیاری موارد دیگر. برای دیدن لیستی از تمام شعبات موجود در مخزن و درک اینکه در کدام یک هستید، باید بنویسید:

git branch -a

می بینید که ما فقط یک شعبه اصلی داریم. ستاره جلوی آن نشان می دهد که ما در آن هستیم. به هر حال، شما همچنین می توانید از دستور "git status" استفاده کنید تا بفهمید ما در کدام شاخه هستیم. سپس چندین گزینه برای ایجاد شاخه ها وجود دارد (ممکن است موارد بیشتری وجود داشته باشد - اینها همان هایی هستند که من استفاده می کنم):

• ایجاد یک شعبه جدید بر اساس شاخه ای که در آن هستیم (99٪ موارد)
• ایجاد یک شعبه بر اساس یک تعهد خاص (1٪ موارد)

بیایید یک شاخه بر اساس یک commit خاص ایجاد کنیم

ما به شناسه منحصر به فرد commit تکیه خواهیم کرد. برای یافتن آن می نویسیم:

git log

من commit را با نظر "اضافه شد hello world..." را برجسته کرده ام. من می خواهم یک شاخه "توسعه" ایجاد کنم که از این commit شروع شود. برای این کار می نویسم:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

یک شاخه تنها با دو کامیت اول از شاخه اصلی ایجاد می شود. برای تأیید این موضوع، ابتدا مطمئن شوید که به یک شاخه دیگر سوئیچ می کنیم و تعداد commit ها را در آنجا بررسی می کنیم:

git status
git log

و همانطور که انتظار می رود، ما دو تعهد داریم. به هر حال، در اینجا یک نکته جالب وجود دارد: هنوز فایل .gitignore در این شاخه وجود ندارد، بنابراین فایل کامپایل شده ما (GitTest.class) اکنون با وضعیت "ردیابی نشده" برجسته شده است. اکنون می‌توانیم شعبه‌های خود را دوباره با نوشتن این مورد بررسی کنیم:

git branch -a

می بینید که دو شاخه وجود دارد: "استاد" و "توسعه". در حال حاضر در حال توسعه هستیم.

بیایید یک شاخه بر اساس فعلی ایجاد کنیم

راه دوم برای ایجاد یک شاخه، ایجاد آن از دیگری است. من می خواهم یک شاخه بر اساس شاخه اصلی ایجاد کنم. ابتدا باید به آن سوئیچ کنم و قدم بعدی ایجاد یک مورد جدید است. بیا یک نگاهی بیندازیم:

• git checkout master — به شاخه اصلی بروید
• وضعیت git - بررسی کنید که ما واقعاً در شاخه اصلی هستیم

در اینجا می بینید که ما به شاخه اصلی سوئیچ کردیم، فایل .gitignore در حال اجرا است و کلاس کامپایل شده دیگر به عنوان "untracked" برجسته نمی شود. اکنون یک شاخه جدید بر اساس شاخه اصلی ایجاد می کنیم:

git checkout -b feature/update-txt-files

اگر مطمئن نیستید که این شاخه همان "master" است یا خیر، می توانید به راحتی با اجرای "git log" و مشاهده تمام commit ها بررسی کنید. باید چهار نفر از آنها باشد.

حل تعارض

قبل از اینکه تعارض چیست را بررسی کنیم، باید در مورد ادغام یک شاخه در شاخه دیگر صحبت کنیم. این تصویر روند ادغام یک شاخه به شاخه دیگر را نشان می دهد: در اینجا، ما یک شاخه اصلی داریم. در نقطه ای، یک شاخه ثانویه از شاخه اصلی ایجاد می شود و سپس اصلاح می شود. پس از اتمام کار، باید یک شاخه را در شاخه دیگر ادغام کنیم. من ویژگی های مختلف را شرح نمی دهم: در این مقاله فقط می خواهم یک درک کلی را منتقل کنم. اگر به جزئیات نیاز دارید، می توانید خودتان آنها را جستجو کنید. در مثال ما، شاخه feature/update-txt-files را ایجاد کردیم. همانطور که در نام شعبه مشخص است، ما در حال به روز رسانی متن هستیم. حال باید یک commit جدید برای این کار ایجاد کنیم:

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

حالا اگر بخواهیم شاخه feature/update-txt-files را در master ادغام کنیم، باید به master رفته و «git merge feature/update-txt-files» را بنویسیم:

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

در نتیجه، شاخه اصلی اکنون شامل commit است که به فایل‌های feature/update-txt اضافه شده است. این قابلیت اضافه شد، بنابراین می توانید شاخه ویژگی را حذف کنید. برای این کار می نویسیم:

git branch -D feature/update-txt-files

تا اینجا همه چیز مشخص است، بله؟ بیایید وضعیت را پیچیده کنیم: اکنون فرض کنید که باید فایل txt را دوباره تغییر دهید. اما اکنون این فایل در شاخه اصلی نیز تغییر خواهد کرد. به عبارت دیگر، به موازات آن تغییر خواهد کرد. وقتی می‌خواهیم کد جدید خود را در شاخه اصلی ادغام کنیم، Git نمی‌تواند بفهمد چه کاری باید انجام دهد. بیا بریم! ما یک شاخه جدید بر اساس master ایجاد می کنیم، تغییراتی در text_resource.txt ایجاد می کنیم و یک commit برای این کار ایجاد می کنیم:

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"

و اکنون جالب ترین نکته: ما باید تغییرات را از شاخه ویژگی/افزودن سرآیند به master ادغام کنیم. ما در شاخه اصلی هستیم، بنابراین فقط باید بنویسیم:

git merge feature/add-header

اما نتیجه یک تضاد در فایل test_resource.txt خواهد بود: در اینجا می بینیم که Git نمی تواند به تنهایی تصمیم بگیرد که چگونه این کد را ادغام کند. به ما می گوید که ابتدا باید تعارض را حل کنیم و تنها پس از آن commit را انجام دهیم. خوب. فایل با تداخل را در یک ویرایشگر متن باز می کنیم و می بینیم: برای اینکه بفهمیم Git در اینجا چه کاری انجام داده است، باید به یاد داشته باشیم که کدام تغییرات و کجا ایجاد کرده ایم و سپس مقایسه کنیم:

1. تغییراتی که در این خط در شاخه اصلی بود بین "<<<<<<< HEAD" و "=======" یافت می شود.
2. تغییراتی که در شاخه feature/add-header بود بین "=======" و ">>>>>>> feature/add-header" یافت می شود.

اینگونه است که Git به ما می گوید که نمی تواند نحوه ادغام را در این مکان در فایل بیابد. این بخش را به دو بخش از شاخه های مختلف تقسیم می کند و ما را به حل تعارض ادغام خود دعوت می کند. به اندازه کافی منصفانه من جسورانه تصمیم گرفتم همه چیز را حذف کنم و فقط کلمه "هدر" را باقی بگذارم: بیایید به وضعیت تغییرات نگاه کنیم. توضیحات کمی متفاوت خواهد بود. به جای وضعیت "تغییر یافته"، ما "ادغام نشده" شده ایم. پس آیا می‌توانستیم وضعیت پنجم را ذکر کنیم؟ من فکر نمی کنم این لازم باشد. اجازه بدید ببینم:

git status

ما می توانیم خودمان را متقاعد کنیم که این یک مورد خاص و غیرعادی است. بیا ادامه بدهیم:

git add *.txt

ممکن است متوجه شوید که توضیحات فقط نوشتن "git commit" را پیشنهاد می کند. بیایید سعی کنیم بنویسیم که:

git commit

و دقیقاً مانند آن، ما آن را انجام دادیم - تضاد موجود در کنسول را حل کردیم. البته این کار را می توان در محیط های توسعه یکپارچه کمی ساده تر انجام داد. به عنوان مثال، در IntelliJ IDEA، همه چیز به قدری خوب تنظیم شده است که می توانید تمام اقدامات لازم را دقیقاً در آن انجام دهید. اما IDE ها کارهای زیادی را «زیر سرپوش» انجام می دهند و ما اغلب نمی دانیم دقیقاً چه اتفاقی در آنجا می افتد. و زمانی که تفاهم وجود نداشته باشد، ممکن است مشکلات ایجاد شود.

کار با مخازن راه دور

آخرین مرحله این است که چند دستور دیگر را که برای کار با مخزن راه دور مورد نیاز است، کشف کنید. همانطور که گفتم، مخزن از راه دور مکانی است که در آن مخزن ذخیره می شود و می توانید آن را از آنجا شبیه سازی کنید. چه نوع مخازن راه دور وجود دارد؟ مثال ها:

• GitHub بزرگترین بستر ذخیره سازی برای مخازن و توسعه مشارکتی است. قبلاً در مقالات قبلی توضیح داده ام.
  من را در GitHub دنبال کنید . من اغلب در آن مناطقی که برای کار مطالعه می کنم، کارم را در آنجا به نمایش می گذارم.

• GitLab یک ابزار مبتنی بر وب برای چرخه عمر DevOps با منبع باز است . این یک سیستم مبتنی بر Git برای مدیریت مخازن کد با ویکی، سیستم ردیابی اشکال ، خط لوله CI/CD و سایر عملکردها است.
  پس از خبر خرید GitHub توسط مایکروسافت، برخی از توسعه دهندگان پروژه های خود را در GitLab کپی کردند.

• BitBucket یک سرویس وب برای میزبانی پروژه و توسعه مشارکتی مبتنی بر سیستم های کنترل نسخه Mercurial و Git است. زمانی مزیت بزرگی نسبت به GitHub داشت زیرا مخازن خصوصی رایگان را ارائه می کرد. سال گذشته گیت هاب نیز این قابلیت را به صورت رایگان به همه معرفی کرد.

• و غیره…

هنگام کار با یک مخزن راه دور، اولین کاری که باید انجام دهید این است که پروژه را در مخزن محلی خود شبیه سازی کنید. برای این کار پروژه ای را که ساختیم به صورت محلی صادر کردم و حالا هرکسی می تواند با نوشتن آن را برای خودش کلون کند:

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

اکنون یک نسخه کامل محلی از پروژه وجود دارد. برای اطمینان از اینکه نسخه محلی پروژه جدیدترین است، باید پروژه را با نوشتن زیر بکشید:

git pull

در مورد ما، در حال حاضر هیچ چیز در مخزن راه دور تغییر نکرده است، بنابراین پاسخ این است: قبلاً به روز شده است. اما اگر من هر تغییری در مخزن راه دور ایجاد کنم، پس از کشیدن آنها، محلی به روز می شود. و در نهایت، آخرین دستور این است که داده ها را به مخزن راه دور فشار دهید. وقتی کاری را به صورت محلی انجام دادیم و می خواهیم آن را به مخزن راه دور ارسال کنیم، ابتدا باید یک commit جدید به صورت محلی ایجاد کنیم. برای نشان دادن این موضوع، بیایید چیز دیگری را به فایل متنی خود اضافه کنیم: اکنون چیزی کاملاً رایج برای ما - یک commit برای این کار ایجاد می کنیم:

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

دستور فشار دادن این مورد به مخزن راه دور این است:

git push

خب، این تمام چیزی است که می خواستم بگویم. از توجه شما ممنونم. من را در GitHub دنبال کنید ، جایی که من پروژه های مختلف نمونه جالب مربوط به مطالعه و کار شخصی خود را پست می کنم.

لینک مفید

• مستندات رسمی Git . من آن را به عنوان یک مرجع توصیه می کنم.