شروع با Git: راهنمای دقیق برای مبتدیان

به جای مقدمه

سلام مهندس ارشد نرم افزار آینده. امروز ما در مورد سیستم کنترل نسخه، یعنی Git (به عنوان GIT خوانده می شود، و نه JIT، همانطور که ممکن است از دستور زبان انگلیسی به نظر برسد) صحبت خواهیم کرد. بله، بله، می دانم که Mercurial، SVN نیز وجود دارد... اما بیایید صادق باشیم: زمان آنها گذشته است، و من وقت گرانبهای شما را برای آنها تلف نمی کنم. برای اینکه متوجه اهمیت دانستن Git در زمان ما شوید، این را می گویم: بدون دانش / درک این موضوع، شما در برنامه نویسی کاری ندارید. اما زیبایی این است که برای کار مداوم نیازی نیست همه دستورات و امکانات را در ذهن خود نگه دارید. شما باید مجموعه ای از دستورات را بدانید که به شما کمک می کند همه چیز را درک کنید.

Git Basics

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

نصب Git

بیایید Git را روی رایانه خود نصب کنیم. من می دانم که هرکسی سیستم عامل متفاوتی دارد، بنابراین سعی می کنم چندین مورد را شرح دهم.

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

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

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

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

نصب در macOS

در اینجا نیز ابتدا باید بررسی کنید که آیا Git در حال حاضر وجود دارد یا خیر (مانند لینوکس به بالا مراجعه کنید). اگر نه، ساده ترین راه دانلود آخرین نسخه است. اگر XCode نصب شده باشد، قطعاً Git به طور خودکار نصب می شود.

راه اندازی Git

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

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).

و غیره.

ایالات در گیت

گیتا چندین حالت دارد که باید درک و به خاطر بسپارید:

• ردیابی نشده
• اصلاح شده؛
• آماده شده (مرحله ای)؛
• متعهد شد.

چه مفهومی داره؟

این ها حالت هایی هستند که فایل های کد ما در آنها قرار دارند. یعنی مسیر زندگی آنها معمولاً به این صورت است:

1. فایلی که ایجاد می شود و به مخزن اضافه نمی شود در حالت ردیابی نشده خواهد بود.
2. ما در فایل‌هایی که قبلاً به مخزن Git اضافه شده‌اند تغییراتی ایجاد می‌کنیم - آنها در حالت اصلاح شده هستند.
3. از بین فایل هایی که تغییر داده ایم، فقط آنهایی (یا همه) مورد نیاز خود را انتخاب می کنیم (مثلاً نیازی به کلاس های کامپایل شده نداریم) و این کلاس ها با تغییرات در حالت مرحله بندی قرار می گیرند.
4. یک commit از فایل های آماده شده از حالت مرحله ایجاد می شود و به مخزن Git می رود. پس از این، حالت مرحله بندی شده خالی است. اما اصلاح شده ممکن است همچنان حاوی چیزی باشد.

به نظر می رسد (تصویر از سند رسمی، بنابراین می توانید به آن اعتماد کنید)):

تعهد چیست

یک 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

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

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

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

git add *.txt

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

git status

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

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

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

git log

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

git status

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

git status

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

git diff

یعنی اینجا به وضوح می بینید که hello world! را به فایل متنی خود اضافه کردم. تغییرات را به فایل متنی اضافه کنید و 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 ایجاد می کنیم و در این فایل هر خط یک الگو برای نادیده گرفتن خواهد بود. در این مثال، git ignore به شکل زیر خواهد بود:

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

بیایید اکنون نگاه کنیم:

• خط اول نادیده گرفتن همه فایل های با پسوند .class است.
• خط دوم نادیده گرفتن پوشه هدف و همه چیزهایی است که در آن وجود دارد.
• خط سوم نادیده گرفتن همه فایل های با پسوند iml است.
• خط چهارم نادیده گرفتن پوشه .idea است.

بیایید آن را با یک مثال امتحان کنیم. برای مشاهده نحوه عملکرد، کلاس GitTest.class کامپایل شده را به پروژه اضافه کنید و وضعیت پروژه را مشاهده کنید:

git status

واضح است که ما نمی خواهیم تصادفا (اگر از git add -A استفاده کنیم) یک کلاس کامپایل شده به پروژه اضافه کنیم. برای انجام این کار، یک فایل .gitignore ایجاد کنید و هر آنچه قبلا توضیح داده شد را اضافه کنید: حالا بیایید git ignore را با یک commit جدید به پروژه اضافه کنیم:

git add .gitignore
git commit -m “added .gitignore file”

و اکنون لحظه حقیقت: ما یک کلاس GitTest.class کامپایل شده در حالت ردیابی نشده داریم که نمی‌خواستیم آن را به مخزن Git اضافه کنیم. اینجاست که git ignore باید کار کند:

git status

همه چیز واضح است) Git ignore +1)

کار با شاخه ها و امثال آن

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

git branch -a

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

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

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

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

git log

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

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

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

git branch -a

مشاهده می شود که دو شاخه - استاد و توسعه - وجود دارد و اکنون در حال توسعه هستیم.

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

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

• git checkout master - به شعبه اصلی بروید.
• وضعیت git - بررسی کنید که آیا روی Master است یا خیر.

در اینجا می بینید که ما به شاخه اصلی منتقل شده ایم، git ignore در حال حاضر در اینجا کار می کند و کلاس کامپایل شده دیگر به عنوان ردیابی نشده ظاهر نمی شود. اکنون یک شاخه جدید بر اساس شاخه اصلی ایجاد می کنیم:

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

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”

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

git merge feature/add-header

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

1. بین “<<<<<< HEAD” و “=======” تغییرات اصلی هستند که در این خط در شاخه اصلی وجود دارد.
2. بین “=======” و “>>>>>>> ویژگی/add-header” تغییراتی در شاخه feature/add-header وجود دارد.

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

git status

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

git add *.txt

در توضیحات متوجه خواهید شد که آنها فقط نوشتن git commit را پیشنهاد می کنند. گوش می کنیم و می نویسیم:

git commit

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

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

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

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

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

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

• و غیره…

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

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

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

git pull

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

git add test_resource.txt
git commit -m “prepated txt for pushing”

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

git push

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

لینک های مفید

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