یاد بگیریم، بسازیم

← بازگشت به صفحه اصلی

کار عملی با Git و GitHub

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

نصب Git

قبل از هر چیز باید Git رو روی کامپیوترت نصب کنی. از سایت git-scm.com نسخه‌ی مناسب سیستم‌عاملت رو دانلود کن. بعد از نصب، توی ترمینال (یا Git Bash روی ویندوز) این دستور رو بزن تا مطمئن بشی درست نصب شده:

git --version

یه بار هم باید خودت رو به Git معرفی کنی، چون این اطلاعات کنار هر کامیتی که می‌زنی ذخیره می‌شه:

git config --global user.name "اسم شما"
git config --global user.email "ایمیل شما"

دستورهای پایه‌ی Git

چند تا دستور هست که ۹۰ درصد کارهای روزمره‌ت باهاشون انجام می‌شه.

شروع یه پروژه جدید

برای اینکه یه پوشه رو تبدیل به یه پروژه‌ی Git کنی (یعنی Git شروع کنه تغییراتش رو ردیابی کنه)، داخل همون پوشه این دستور رو بزن:

git init

اگه ریپازیتوری از قبل روی GitHub ساخته شده، به‌جای init از clone استفاده می‌کنی تا یه کپی از اون رو روی کامپیوترت بیاری:

git clone https://github.com/username/repository-name.git

چک کردن وضعیت

هر وقت بخوای ببینی چه فایل‌هایی تغییر کردن یا هنوز کامیت نشدن، این دستور رو بزن:

git status

این دستور رو زیاد استفاده کن؛ قبل از هر کامیتی یه بار بزنیش تا دقیقاً بدونی چی داری کامیت می‌کنی.

اضافه کردن و کامیت

وقتی یه فایل رو تغییر می‌دی، Git خودش به‌طور خودکار کامیتش نمی‌کنه. اول باید بهش بگی کدوم فایل‌ها رو می‌خوای تو کامیت بعدی بذاری:

git add نام-فایل.html
git add .

دستور دوم (git add .) همه‌ی فایل‌های تغییریافته رو اضافه می‌کنه. بعد کامیت می‌کنی:

git commit -m "توضیح کوتاه درباره‌ی این تغییر"

پیام کامیت رو واضح بنویس؛ چند ماه دیگه که به تاریخچه نگاه می‌کنی، همین پیام‌هاست که بهت می‌گه هر تغییر برای چی بوده.

فرستادن و گرفتن تغییرات

بعد از کامیت، تغییرات فقط روی کامپیوتر خودتن. برای اینکه به GitHub برسن:

git push

و اگه بخوای آخرین تغییراتی که روی GitHub انجام شده (مثلاً توسط یه هم‌تیمی) رو بگیری:

git pull

یه عادت خوب اینه که قبل از شروع کار روزانه، یه git pull بزنی تا مطمئن بشی از آخرین نسخه شروع می‌کنی.

فایل README

README.md اولین فایلیه که GitHub توی صفحه‌ی اصلی هر ریپازیتوری نشون می‌ده. معمولاً توش می‌نویسی این پروژه چیه، چطور نصبش کنن و چطور ازش استفاده کنن. چون پسوندش .mdه، با Markdown نوشته می‌شه؛ اگه یادت رفته، می‌تونی مقاله‌ی Markdown چیست؟ رو یه نگاه بندازی.

یه README خوب معمولاً این بخش‌ها رو داره:

• اسم و یه توضیح کوتاه درباره‌ی پروژه
• نحوه‌ی نصب یا اجرا
• یه مثال ساده از استفاده
• لایسنس، اگه پروژه متن‌بازه

فایل .gitignore

خیلی وقت‌ها تو پوشه‌ی پروژه‌ت فایل‌هایی هست که نمی‌خوای وارد ریپازیتوری بشن — مثلاً فایل‌های تنظیمات شخصی ادیتور، فایل‌های موقتی سیستم‌عامل، یا پوشه‌ی node_modules تو پروژه‌های جاوااسکریپتی. با ساختن یه فایل به اسم .gitignore تو ریشه‌ی پروژه، به Git می‌گی این فایل‌ها یا پوشه‌ها رو نادیده بگیره:

.DS_Store
node_modules/
*.log

هر خط یه الگوئه: می‌تونه اسم یه فایل، یه پوشه (با / آخرش)، یا یه الگوی کلی‌تر با * باشه.

کار با برنچ

تو مقاله‌ی قبل با مفهوم برنچ آشنا شدی. حالا دستورهاش:

ساختن یه برنچ جدید و رفتن روش:

git branch نام-برنچ
git checkout نام-برنچ

یا هر دو کار با یه دستور:

git checkout -b نام-برنچ

وقتی کارت روی برنچ تموم شد و مطمئن بودی درسته، برمی‌گردی به برنچ اصلی و اون رو ادغام (merge) می‌کنی:

git checkout main
git merge نام-برنچ

Fork و Pull Request

Fork یعنی یه کپی کامل از ریپازیتوری یکی دیگه رو زیر اکانت خودت بسازی. این کار وقتی به کار می‌آد که می‌خوای تو یه پروژه‌ی متن‌باز مشارکت کنی ولی دسترسی مستقیم نوشتن روی ریپازیتوری اصلی رو نداری.

مراحل مشارکت تو یه پروژه‌ی متن‌باز معمولاً این‌جوریه:

1. ریپازیتوری رو Fork می‌کنی (از دکمه‌ی «Fork» بالای صفحه‌ی ریپازیتوری روی GitHub)
2. نسخه‌ی fork‌شده رو روی کامپیوترت clone می‌کنی
3. یه برنچ جدید می‌سازی و تغییراتت رو توش انجام می‌دی
4. تغییرات رو push می‌کنی به fork خودت
5. از GitHub یه Pull Request می‌زنی که ازش خواسته می‌شه تغییراتت با ریپازیتوری اصلی ادغام بشه

نگهدارنده‌ی پروژه Pull Request رو بررسی می‌کنه، ممکنه ازت بخواد چیزی رو اصلاح کنی، و اگه همه‌چیز اوکی بود، تغییراتت رو merge می‌کنه.

حل Merge Conflict

گاهی وقتی می‌خوای دو برنچ رو ادغام کنی، Git نمی‌تونه خودش تصمیم بگیره کدوم نسخه از یه قسمت از فایل درسته — مثلاً چون تو و یه هم‌تیمی هم‌زمان یه خط از همون فایل رو تغییر دادین. به این می‌گن Merge Conflict (تداخل ادغام).

وقتی این اتفاق بیفته، Git توی فایل، هر دو نسخه رو با این علامت‌ها نشون می‌ده:

<<<<<<< HEAD
نسخه‌ی شما
=======
نسخه‌ی برنچ دیگه
>>>>>>> نام-برنچ

کاری که باید بکنی:

1. فایل رو باز کن و ببین کدوم نسخه (یا ترکیبی از هر دو) درسته
2. علامت‌های <<<<<<<، ======= و >>>>>>> رو پاک کن و فقط متن نهایی رو نگه دار
3. فایل رو ذخیره کن، بعد git add و git commit بزن تا merge کامل بشه

تداخل ترسناک نیست؛ فقط یعنی Git از تو می‌خواد خودت تصمیم نهایی رو بگیری.

جمع‌بندی

با این دستورها (init، clone، status، add، commit، push، pull)، فایل‌های README و .gitignore، و کار با برنچ و Pull Request، دیگه می‌تونی روزمره با Git و GitHub کار کنی. بخش بعدی این سه‌گانه به انتشار سایتت با GitHub Pages و ابزارهای بیشتر GitHub می‌پردازه.

← بازگشت به صفحه اصلی