مقدمه و آغاز کار با گیت

چرا گیت؟

گیت چیست؟

گیت یک سیستم کنترل نسخهVersion Control System است که به شما امکان مدیریت و ردیابی تغییرات پروژه را می‌دهد.

مشکلات بدون گیت

• هماهنگی بین چند برنامه‌نویس سخت است
• بازگشت به نسخه‌های قبلی مشکل است
• ادغام تغییرات چند نفر دشوار است
• از دست دادن کد در صورت خطا

راه‌حل گیت

• هر نفر یک نسخه کامل از پروژه روی سیستم خود دارد
• تمام تغییرات در تاریخچه ذخیره می‌شود
• می‌توانید به هر نسخه قبلی برگردید
• تغییرات به راحتی با دیگران هماهنگ می‌شود
• کار گروهی بدون تداخل انجام می‌شود

نصب گیت

دانلود و نصب

برای نصب گیت، به صفحه رسمی نصب گیت مراجعه کنید و نسخه مناسب سیستم‌عامل خود را دانلود کنید.

نصب در سیستم‌عامل‌های مختلف:

• Windows: فایل exe را از سایت رسمی دانلود و نصب کنید
• macOS: از Homebrew استفاده کنید: brew install git
• Linux: از package manager استفاده کنید: sudo apt install git

بررسی نصب

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

git --version

اگر گیت به درستی نصب شده باشد، خروجی مشابه زیر را خواهید دید:

git version 2.52.0

تنظیمات اولیه

قبل از شروع کار با گیت، باید نام کاربری و ایمیل خود را تنظیم کنید. این اطلاعات در کامیت‌ها نمایش داده می‌شوند و برای کار تیمی ضروری است.

از دستور git config --global برای تنظیمات سراسری استفاده می‌کنیم:

git config --global user.name "نام شما"
git config --global user.email "email@example.com"

نکته

پرچم --global باعث می‌شود این تنظیمات برای تمام پروژه‌های شما اعمال شود.

مشاهده تنظیمات

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

git config --list

فعال‌سازی کلید SSH

کلید SSH برای اتصال امن به سرورهای گیت استفاده می‌شود. در این بخش مراحل راه‌اندازی آن را یاد می‌گیرید.

ایجاد کلید SSH

در ترمینال (یا Git Bash در ویندوز) دستور زیر را اجرا کنید و ۳ بار Enter بزنید:

ssh-keygen

این دستور یک کلید SSH در مسیر ~/.ssh ایجاد می‌کند.

اطلاع

اگر از قبل کلید SSH دارید، می‌توانید از همان استفاده کنید یا یک کلید جدید با نام متفاوت ایجاد کنید.

فعال‌سازی SSH Agent

eval `ssh-agent`

اضافه کردن کلید به SSH Agent

macOS:

ssh-add -K ~/.ssh/id_rsa

یادداشت

در صورت وجود فایل ~/.ssh/config، این دو خط را اضافه کنید:

Host *
UseKeychain yes

Linux/Windows:

ssh-add ~/.ssh/id_rsa

تنظیم کلید در GitHub

1. به تنظیمات SSH Keys در GitHub بروید
2. روی "New SSH key" کلیک کنید
3. یک عنوان انتخاب کنید
4. محتوای ~/.ssh/id_rsa.pub را در قسمت Key قرار دهید
5. "Add SSH key" را بزنید

برای تست اتصال به GitHub:

ssh -T git@github.com

ابزار خط فرمان گیت‌هاب (GitHub CLI)

علاوه بر دستورات استاندارد گیت، گیت‌هاب یک ابزار خط فرمان اختصاصی به نام gh دارد که کار با این پلتفرم را بسیار ساده‌تر می‌کند. با gh می‌توانید بدون خروج از ترمینال، کارهایی مثل ساخت ریپازیتوری، مدیریت Issueها و بررسی Pull Requestها را انجام دهید.

نصب و لاگین

پس از نصب GitHub CLI متناسب با سیستم‌عامل خود، با دستور زیر به حساب گیت‌هاب خود متصل شوید:

gh auth login

این دستور شما را قدم‌به‌قدم برای انتخاب پروتکل (HTTPS یا SSH) و احراز هویت راهنمایی می‌کند. اگر SSH را انتخاب کنید، gh می‌تواند به صورت خودکار کلیدهای SSH شما را مدیریت و آپلود کند!

دستورات پرکاربرد

• ساخت ریپازیتوری جدید:

gh repo create my-new-project --public --clone

• کلون کردن ریپازیتوری:

gh repo clone owner/repo

• مشاهده لیست Issueها:

gh issue list

• مشاهده وضعیت Pull Requestها:

gh pr status

ریپازیتوری

ریپازیتوری چیست؟

ریپازیتوریRepository

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

انواع ریپازیتوری

• ریپازیتوری محلیLocal Repository : ریپازیتوری روی کامپیوتر شما
• ریپازیتوری راه‌دورRemote Repository : ریپازیتوری روی سرور (مثل GitHub یا Gitlab)

نحوه کار با ریپازیتوری

در گیت، هر عضو تیم:

• یک کپی کامل از پروژه و تاریخچه آن روی سیستم خود دارد
• می‌تواند تغییرات را ایجاد و کامیت کند
• تغییرات را به سرور ارسالpush می‌کند
• تغییرات دیگران را از سرور دریافتpull می‌کند

مثال ساده

1. شما یک فایل file.txt می‌سازید و کامیت می‌کنید
2. کامیت را به سرور ارسال می‌کنید
3. هم‌تیمی شما تغییرات را از سرور دریافت می‌کند
4. او فایل را ویرایش می‌کند و کامیت جدید می‌سازد
5. این روند ادامه می‌یابد و پروژه پیشرفت می‌کند

نکته

سرور همیشه نسخه رسمی و به‌روز پروژه را نگه می‌دارد.

دستورات git init و git clone

git init

برای تبدیل یک پروژه موجود به ریپازیتوری< گیت، از دستور git init استفاده می‌کنیم:

git init <PATH>

این دستور یک ریپازیتوری خالی با فولدر .git ایجاد می‌کند که تاریخچه تغییرات در آن ذخیره می‌شود.

اطلاع

اگر در دایرکتوری فعلی باشید، دستور git init همان دایرکتوری را به ریپازیتوری تبدیل می‌کند.

git remote add

برای اتصال ریپازیتوری محلی به یک ریپازیتوری راه‌دورRemote Repository (مثل GitHub یا GitLab)، از دستور زیر استفاده می‌کنیم:

git remote add <NAME> <REPOSITORY_URL>

مثال:

git remote add origin https://github.com/Byte-Magazine/byte-site

نکته

نام origin به طور پیش‌فرض برای ریپازیتوری اصلی استفاده می‌شود، اما می‌توانید نام دلخواه انتخاب کنید.

هشدار

این دستور فقط اتصال را برقرار می‌کند و فایل‌ها را به سرور ارسال نمی‌کند. برای ارسال فایل‌ها باید از دستور git push استفاده کنید.

مشاهده Remote‌ها

برای مشاهده لیست remote‌های متصل شده:

git remote

برای مشاهده URL کامل remote‌ها:

git remote -v

تغییر URL Remote

برای تغییر آدرس یک remote موجود از دستور git remote set-url استفاده می‌کنیم:

git remote set-url <NAME> <NEW_URL>

مثال:

git remote set-url origin https://github.com/username/new-repository.git

نکته

این دستور زمانی مفید است که آدرس remote تغییر کرده یا می‌خواهید از HTTPS به SSH (یا برعکس) تغییر دهید.

git clone

برای دریافت یک پروژه از سرور و ساخت کپی محلی از آن، از دستور git clone استفاده می‌کنیم:

git clone <REPOSITORY_URL>

مثال:

git clone https://github.com/Byte-Magazine/byte-site

با نام دلخواه:

git clone https://github.com/Byte-Magazine/byte-site my-test-project

با SSH:

git clone git@github.com:Byte-Magazine/byte-site.git

اطلاع

با clone کردن یک پروژه، تمام کامیت‌ها و تاریخچه پروژه روی سیستم شما کپی می‌شود و به صورت خودکار remote به نام origin تنظیم می‌شود.

چرخه حیات وضعیت فایل‌ها

• Untracked: فایل توسط گیت پیگیری نمی‌شود
• Unmodified: فایل شناسایی شده و تغییری ندارد
• Modified (not staged): فایل تغییر کرده اما به Staging Area اضافه نشده
• Staged: فایل آماده کامیت است

دستورات add و status

git add

برای اضافه کردن فایل‌ها به Staging Area از دستور git add استفاده می‌کنیم:

git add <filename>

مثال:

git add file.txt
git add file1.txt file2.txt

برای اضافه کردن همه فایل‌ها:

git add .

یا

git add -A

اطلاع

فایل‌های جدید به طور پیش‌فرض Untracked هستند و باید با git add به گیت معرفی شوند.

git status

برای مشاهده وضعیت فایل‌ها و تغییرات، از دستور git status استفاده می‌کنیم:

git status

دستور commit

پس از stage کردن فایل‌ها، می‌توانیم با دستور git commit یک کامیت ایجاد کنیم:

git commit -m "commit message"

نکته

پیام کامیت باید واضح و خلاصه باشد تا در آینده بتوانید به راحتی تغییرات را متوجه شوید.

روش‌های مختلف کامیت

کامیت فایل‌های خاص بدون stage کردن:

git commit file.txt -m "change content in file.txt"

این دستور فایل را stage و سپس کامیت می‌کند.

کامیت همه فایل‌های tracked:

git commit -a -m "update all tracked files"

پرچم -a همه فایل‌های tracked را stage و کامیت می‌کند.

هشدار

فایل‌های جدید (untracked) با -a کامیت نمی‌شوند. باید ابتدا با git add اضافه شوند.

git log

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

git log

این دستور اطلاعات زیر را نمایش می‌دهد:

• شناسه کامیت (hash)
• کاربر و زمان کامیت
• پیام کامیت

مشاهده تاریخچه یک فایل خاص:

git log file.txt

مشاهده تاریخچه یک دایرکتوری:

git log dir1/

هش کامیت

هر کامیت یک شناسه یکتا به نام hash دارد که یک رشته 40 کاراکتری (hexadecimal) است. مثال:

a9c30aad7f0d8b39d54ae0f68ba3c9c97a7c3b5c

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

استفاده از hash:

• می‌توانید از چند کاراکتر اول hash برای اشاره به کامیت استفاده کنید (معمولاً 7 کاراکتر کافی است)
• برای مشاهده جزئیات یک کامیت خاص:

git show a9c30a

اطلاع

گیت از الگوریتم SHA-1 برای تولید hash استفاده می‌کند. هر تغییر کوچک در کامیت، hash کاملاً متفاوتی ایجاد می‌کند.

دستور tag

از دستور git tag برای علامت‌گذاری کامیت‌های مهم استفاده می‌شود. معمولاً برای نسخه‌های منتشر شده (مثل v1.0، v2.1) از tag استفاده می‌کنیم.

انواع Tag

Lightweight Tag: یک اشاره‌گر ساده به یک کامیت است و اطلاعات اضافی ندارد:

git tag <TAG_NAME>

مثال:

git tag v1.0

Annotated Tag: دارای اطلاعات کامل مانند تاریخ، checksum و پیام است. این نوع tag پیشنهاد می‌شود:

git tag -a <TAG_NAME> -m "<MESSAGE>"

مثال:

git tag -a v1.0 -m "Release version 1.0"

مشاهده Tag‌ها

مشاهده لیست تمام tag‌ها:

git tag

جستجو در tag‌ها با الگو:

git tag -l "v1.*"

این دستور تمام tag‌هایی که با v1. شروع می‌شوند را نمایش می‌دهد.

Tag کردن کامیت‌های قدیمی

برای tag کردن یک کامیت خاص، hash کامیت را در انتهای دستور اضافه کنید:

git tag -a <TAG_NAME> -m "<MESSAGE>" <COMMIT_HASH>

مثال:

git tag -a first -m "First commit tag" 615b64e

نکته

می‌توانید از چند کاراکتر اول hash استفاده کنید، به شرطی که یکتا باشد.

اطلاع

Tag‌ها در git log نمایش داده می‌شوند و می‌توانید با آن‌ها به راحتی به نسخه‌های خاص پروژه دسترسی داشته باشید.

فایل gitignore.

فایل .gitignore برای نادیده گرفتن فایل‌ها و دایرکتوری‌های خاص توسط گیت استفاده می‌شود. این فایل معمولاً در روت پروژه قرار می‌گیرد.

موارد استفاده:

• فایل‌های تولید شده توسط IDE (مثل VSCode)
• فایل‌های مهم پروژه (مثل .env)
• فایل‌های تولید شده از build پروژه

ساخت فایل gitignore.

در روت پروژه یک فایل با نام .gitignore بسازید و قوانین دلخواه خود را در آن بنویسید:

file1.txt
/dir1

/dir2/*.cpp

*.env

قوانین مهم

آدرس‌دهی از روت:

• /file.txt → فقط فایل در روت پروژه
• file.txt → فایل در هر جای پروژه

Wildcards:

• * → صفر یا چند کاراکتر (غیر از /)
• ** → هر تعداد دایرکتوری

مثال‌ها:

*.env

/dir1/file.txt

/dir1/**/file.txt

# don't ignore this file
!/dir1/file.txt

مثال‌های رایج

برای پروژه‌های Node.js:

node_modules/
.env
*.log
.DS_Store

برای پروژه‌های Python:

__pycache__/
*.pyc
venv/
.env
.DS_Store

برای پروژه‌های Java:

*.class
target/
.idea/
.DS_Store

نکته

پس از ساخت یا تغییر .gitignore، فایل‌های قبلاً tracked شده را با git rm --cached حذف کنید تا قوانین جدید اعمال شوند.

اطلاع

برای الگوهای بیشتر و پیش‌ساخته، می‌توانید از gitignore.io استفاده کنید.

دستورات pull و push و fetch

این دستورات برای همگام‌سازی پروژه محلی با ریپازیتوری راه‌دور استفاده می‌شوند.

git push

برای ارسال تغییرات محلی به سرور از دستور git push استفاده می‌کنیم:

git push <REPOSITORY> <BRANCH>

مثال:

git push origin main

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

git push

نکته

در اولین push، از پرچم -u استفاده کنید تا ارتباط بین branch محلی و remote برقرار شود:

git push -u origin main

git pull

برای دریافت و اعمال تغییرات از سرور به پروژه محلی از دستور git pull استفاده می‌کنیم:

git pull <REPOSITORY> <BRANCH>

مثال:

git pull origin main

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

git pull

این دستور تغییرات را دریافت کرده و به صورت خودکار با پروژه محلی merge می‌کند.

git fetch

برای دریافت تغییرات از سرور بدون merge کردن از دستور git fetch استفاده می‌کنیم:

git fetch <REPOSITORY>

مثال:

git fetch origin

اطلاع

git fetch فقط تغییرات را دانلود می‌کند و فایل‌های محلی را تغییر نمی‌دهد. برای اعمال تغییرات باید از git merge استفاده کنید.

تفاوت pull و fetch

دستور	کارکرد
git pull	دریافت + merge خودکار
git fetch	فقط دریافت (بدون merge)

مزایای fetch:

• می‌توانید قبل از merge، تغییرات را بررسی کنید
• کنترل بیشتری روی merge دارید
• می‌توانید تغییرات را در زمان مناسب merge کنید

هشدار

قبل از push، همیشه ابتدا git pull را اجرا کنید تا از همگام بودن با سرور اطمینان حاصل کنید.