آموزش Git و GitHub از صفر با مثال‌های عملی برای برنامه‌نویسان

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

همه دستورها را می‌توانید همین حالا در ترمینال اجرا کنید.

Git چیست و چرا به آن نیاز داریم؟

Git یک سیستم کنترل نسخه توزیع‌شده (Distributed Version Control) است. «توزیع‌شده» یعنی هر نفر یک نسخه کامل از تاریخچه پروژه را روی سیستم خودش دارد و برای بیشتر کارها به اینترنت یا سرور نیازی نیست.

سه مفهوم پایه را از همین اول به خاطر بسپارید:

• پوشه کاری (Working Directory): فایل‌هایی که الان رویشان کار می‌کنید.
• ناحیه استیج (Staging Area): تغییراتی که برای کامیت بعدی انتخاب کرده‌اید.
• مخزن (Repository): تاریخچه کامیت‌ها که در پوشه .git نگهداری می‌شود.

نصب و پیکربندی اولیه Git

در ویندوز، Git را از سایت رسمی git-scm.com دانلود و نصب کنید. در مک با brew install git و در اوبونتو با دستور زیر نصبش کنید:

sudo apt update && sudo apt install git
git --version

بعد از نصب، نام و ایمیلتان را تنظیم کنید. این اطلاعات روی هر کامیت ثبت می‌شود:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

ساخت اولین مخزن و اولین کامیت

یک پوشه بسازید و آن را به مخزن Git تبدیل کنید:

mkdir my-project && cd my-project
git init
echo "# My Project" > README.md
git status

دستور git status مهم‌ترین دوست شماست؛ هر وقت شک داشتید، اجرایش کنید. حالا فایل را به ناحیه استیج اضافه و کامیت کنید:

git add README.md
git commit -m "Add README"
git log --oneline

پیام کامیت را کوتاه، دقیق و به زبان امری بنویسید؛ مثلاً «Add login form» به‌جای «changes». شش ماه بعد از خودتان تشکر خواهید کرد.

فایل .gitignore را فراموش نکنید

فایل‌هایی مثل node_modules، فایل‌های ساخت و به‌خصوص فایل‌های حاوی رمز و کلید نباید وارد مخزن شوند. یک فایل .gitignore در ریشه پروژه بسازید:

node_modules/
dist/
.env
*.log
.DS_Store

دیدن تغییرات و برگرداندن اشتباه‌ها

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

git diff            # changes not yet staged
git diff --staged   # changes staged for the next commit

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

git restore app.js           # discard changes in working directory
git restore --staged app.js  # unstage, keep the changes

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

git revert <commit-hash>

شاخه‌ها در آموزش Git: قلب کار تیمی

شاخه (Branch) به شما اجازه می‌دهد روی یک قابلیت جدید کار کنید، بدون اینکه کد اصلی دست بخورد. شاخه‌ها در Git بسیار سبک‌اند؛ پس بی‌دریغ از آن‌ها استفاده کنید.

git switch -c feature/login   # create and switch to a new branch
# ... edit files ...
git add .
git commit -m "Add login form"
git switch main               # go back to main
git branch                    # list branches

ادغام شاخه‌ها با merge

وقتی کار روی شاخه تمام شد، آن را در main ادغام کنید:

git switch main
git merge feature/login
git branch -d feature/login   # delete the merged branch

حل تعارض (Merge Conflict)

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

<<<<<<< HEAD
const title = "DevNA";
=======
const title = "DevNA Magazine";
>>>>>>> feature/login

بخش بالای ======= نسخه شاخه فعلی و بخش پایین نسخه شاخه دیگر است. فایل را به شکل نهایی دلخواه ویرایش کنید، نشانگرها را پاک کنید و سپس:

git add app.js
git commit

تعارض ترسناک نیست؛ فقط یعنی Git از شما نظر خواسته است.

rebase یا merge؟

راه دیگر یکپارچه کردن تغییرات، rebase است. به‌جای ساختن کامیت ادغام، کامیت‌های شاخه شما را برمی‌دارد و روی آخرین نسخه main دوباره اعمال می‌کند. نتیجه، تاریخچه‌ای خطی و تمیز است:

git switch feature/login
git rebase main

قانون ساده‌ای که از دردسر نجاتتان می‌دهد: شاخه‌های شخصی‌تان را آزادانه rebase کنید، اما هرگز شاخه‌ای را که دیگران رویش کار می‌کنند rebase نکنید؛ چون rebase تاریخچه را بازنویسی می‌کند و هم‌تیمی‌هایتان با تاریخچه‌ای متفاوت روبه‌رو می‌شوند. اگر مطمئن نیستید، merge همیشه انتخاب امن‌تری است.

کار با GitHub: از مخزن محلی تا مخزن آنلاین

حالا وقت آن است که پروژه را روی GitHub منتشر کنیم. در سایت GitHub یک مخزن خالی بسازید (بدون README تا تعارضی پیش نیاید) و آدرسش را کپی کنید. برای احراز هویت، استفاده از کلید SSH راحت‌ترین روش است:

ssh-keygen -t ed25519 -C "you@example.com"
cat ~/.ssh/id_ed25519.pub   # add this public key in GitHub > Settings > SSH keys
ssh -T git@github.com       # test the connection

سپس مخزن محلی را به GitHub وصل و ارسال کنید:

git remote add origin git@github.com:your-username/my-project.git
git push -u origin main

فلگ -u شاخه محلی را به شاخه راه دور متصل می‌کند تا از این به بعد فقط git push و git pull کافی باشد.

کلون کردن و به‌روز ماندن

برای دریافت پروژه‌ای که روی GitHub است:

git clone git@github.com:your-username/my-project.git
cd my-project
git pull   # fetch and merge the latest changes

جریان کار تیمی با Pull Request

در تیم‌ها معمولاً کسی مستقیم روی main کامیت نمی‌کند. جریان کار استاندارد این است:

1. از main یک شاخه جدید بسازید: git switch -c fix/header-typo
2. تغییرات را کامیت و شاخه را push کنید: git push -u origin fix/header-typo
3. در GitHub یک Pull Request باز کنید تا هم‌تیمی‌ها کد را بررسی کنند.
4. بعد از تأیید، PR در main ادغام می‌شود و شاخه حذف می‌شود.

این جریان وقتی با تست خودکار ترکیب شود، قدرت واقعی‌اش را نشان می‌دهد. در آموزش CI/CD با GitHub Actions یاد می‌گیرید چطور روی هر Pull Request تست‌ها خودکار اجرا شوند.

چند دستور کاربردی که هر روز به کارتان می‌آید

نسخه‌گذاری با تگ

وقتی نسخه‌ای از پروژه آماده انتشار است، روی آن تگ (Tag) بگذارید. تگ برچسبی ثابت روی یک کامیت است و معمولاً برای شماره نسخه به کار می‌رود:

git tag -a v1.0.0 -m "First stable release"
git push origin v1.0.0
git tag   # list tags

تگ‌ها در GitHub به‌عنوان Release هم قابل استفاده‌اند و بسیاری از خطوط لوله CI/CD با push شدن یک تگ جدید، انتشار نسخه را آغاز می‌کنند. پیشنهاد می‌کنیم از نسخه‌گذاری معنایی (Semantic Versioning) پیروی کنید: عدد اول برای تغییرات ناسازگار، عدد دوم برای قابلیت‌های جدید و عدد سوم برای رفع باگ.

اشتباه‌های رایج تازه‌کارها

• کامیت کردن فایل .env: اگر رمزی وارد مخزن عمومی شد، فقط حذف فایل کافی نیست؛ رمز را فوراً عوض کنید.
• کامیت‌های غول‌پیکر: هر کامیت باید یک تغییر منطقی باشد. کامیت‌های کوچک بررسی و برگرداندن را آسان می‌کنند.
• استفاده بی‌احتیاط از push --force: روی شاخه‌های مشترک هرگز این کار را نکنید. اگر لازم شد، --force-with-lease امن‌تر است.

قدم بعدی

با همین دستورها می‌توانید بخش بزرگی از کارهای روزمره Git را انجام دهید. قدم بعدی این است که پروژه‌تان را با Docker کانتینری کنید و سپس خط لوله CI/CD برایش بسازید. تمرین کنید، شاخه بسازید، خراب کنید و برگردانید؛ Git برای همین ساخته شده است.