آموزش Git از صفر؛ اولین Repository تا اولین Commit

این صفحه یک مسیر خطی است: نصب و هویت، ساخت Repository، دیدن وضعیت، Stage کردن فایل، ثبت اولین Commit، و خواندن تاریخچه. هدف «حفظ کردن همهٔ سوییچ‌ها» نیست؛ هدف این است که بعد از بیست دقیقه بدانید هر فرمان چه لایه‌ای را عوض می‌کند. فرمان‌ها از مستندات رسمی git-scm و فصل‌های ۲٫۱ و ۲٫۲ کتاب Pro Git آمده‌اند.

محیط فرضی: ترمینال روی لینوکس یا macOS؛ روی ویندوز Git Bash یا همان دستورات در PowerShell با Git foreWindows کار می‌کند. اگر هنوز تفاوت Git و GitHub را نخوانده‌اید، مقالهٔ ۰۷۱ را بعداً ببینید — اینجا عمداً Remote را کوتاه نگه می‌داریم تا پایه محکم شود.

هشدار صداقت: این آموزش جایگزین خواندن man page برای سناریوهای خاص نیست. وقتی Conflict یا History rewriting لازم شد، به مقالات Branch/Merge و مستندات رسمی برگردید.

پاسخ کوتاه

برای شروع از صفر: Git را نصب کنید؛ user.name و user.email را تنظیم کنید؛ در پوشهٔ پروژه git init بزنید؛ فایل بسازید؛ با git add به Staging بروید؛ با git commit -m پیام بدهید. وضعیت را با git status و تاریخچه را با git log ببینید. این همان چرخهٔ Recording Changes در Pro Git است.

Staging برای این است که Commit دقیقاً همان چیزی باشد که قصد دارید — نه هر فایلی که اتفاقی روی دیسک کثیف شده.

۱) نصب و هویت

از صفحهٔ دانلود رسمی git-scm.com نسخهٔ مناسب سیستم را بگیرید یا از مدیر بسته استفاده کنید. نسخه را چک کنید:

bash

git --version

طبق First-Time Git Setup در Pro Git، حداقل این دو را سراسری تنظیم کنید (یک‌بار روی هر ماشین):

bash

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

این مقادیر داخل metadata هر Commit می‌روند. ایمیل بهتر است با هویت کاری/GitHub شما هم‌خوان باشد تا تاریخچه در UI یکدست دیده شود. برای دیدن تنظیمات:

bash

git config --list

۲) دو راه برای داشتن Repository

Pro Git می‌گوید دو مسیر رایج دارید: کلون کردن مخزن موجود، یا init روی پوشهٔ جدید/فعلی. Clone را در مقالهٔ ۰۷۳ عمیق می‌کنیم؛ اینجا init:

bash

mkdir hello-git cd hello-git git init

git init یک پوشهٔ پنهان .git می‌سازد که پایگاه دادهٔ اشیاء و refs است. پوشهٔ کاری شما Working tree است. اگر داخل پروژهٔ موجود init می‌کنید، مطمئن شوید Secret و وابستگی‌های حجیم را بعداً با .gitignore حذف می‌کنید (مقالهٔ ۰۸۳).

۳) ساخت فایل و دیدن وضعیت

bash

echo "# Hello" > README.md git status

خروجی status معمولاً README را به‌عنوان untracked نشان می‌دهد: Git فایل را می‌بیند ولی هنوز دنبالش نمی‌کند. این مرحله مهم است چون Commit خودکار همه چیز را برنمی‌دارد مگر صریحاً add یا سوییچ‌هایی مثل commit -a برای فایل‌های tracked.

۴) Staging با git add

bash

git add README.md git status

حالا فایل Staged است: در Index برای Commit بعدی آماده شده. می‌توانید چند فایل یا الگو اضافه کنید:

bash

git add . # یا انتخابی: git add src/

اگر پشیمان شدید قبل از Commit:

bash

git restore --staged README.md

(در نسخه‌های قدیمی‌تر گاهی git reset HEAD <file> آموزش داده می‌شد؛ restore --staged مسیر توصیه‌شدهٔ جدیدتر است.)

۵) اولین Commit

bash

git commit -m "Add README with project title"

طبق git-commit documentation، Commit محتوای Index را به‌همراه پیام ذخیره می‌کند و Branch جاری را جلو می‌برد. پیام خوب کوتاه و امری است؛ جزئیات در مقالهٔ ۰۷۴. برای چندپاراگراف، بدون -m بنویسید تا ادیتور باز شود.

اگر Commit را زدید و فوراً غلط املایی در پیام دیدید و هنوز Push نکرده‌اید، مسیر amend وجود دارد — ولی قبل از فهم History rewriting از آن روی Branch مشترک استفاده نکنید.

۶) تأیید تاریخچه

bash

git log --oneline git show

باید Commit خود را با hash کوتاه، نویسنده و پیام ببینید. این لحظه‌ای است که «نسخه» دیگر یک فایل کپی نیست؛ یک گره در گراف تاریخچه است.

جدول چرخهٔ روزانهٔ حداقلی

اتصال کوتاه به Remote (اختیاری همین جلسه)

اگر مخزن خالی روی GitHub ساخته‌اید (بدون README تا Conflict اولیه نگیرید)، طبق مثال GitHub Docs:

bash

git remote add origin https://github.com/YOUR-USER/YOUR-REPO.git git branch -M main git push -u origin main

جزئیات Push/Pull در ۰۷۵. اگر اینجا خطا گرفتید، اول هویت SSH/HTTPS و وجود Remote را چک کنید نه اینکه همه چیز را دوباره init کنید.

چک‌لیست پایان جلسه

1. git --version جواب می‌دهد.
2. user.name و user.email ست شده‌اند.
3. یک پوشه با .git دارید.
4. حداقل یک Commit در git log دیده می‌شود.
5. می‌توانید توضیح دهید add با commit چه فرقی دارد.

اشتباه‌های متداول تازه‌کار

• init داخل پوشهٔ خانگی به‌جای پوشهٔ پروژه — تاریخچه با فایل‌های شخصی قاطی می‌شود.
• Commit با پیام خالی یا «update» برای همه چیز.
• add کردن .env و کلیدها.
• ترس از status؛ status دوست شماست، قبل از هر Commit آن را بخوانید.

جمع‌بندی

از صفر تا اولین Commit چهار مهارت کافی است: هویت، init، add، commit. بقیهٔ اکوسیستم روی همین چرخه سوار می‌شود. تمرین پیشنهادی: یک پوشهٔ آزمایشی بسازید، سه Commit جدا برای سه تغییر کوچک بزنید، و log را بخوانید. وقتی این حس درست شد، Clone و Branch معنادار می‌شوند.

فرمان‌های این صفحه را از روی عادت کپی نکنید؛ هر بار status را نگاه کنید تا مدل ذهنی‌تان با دیسک یکی باشد.

خواندن خروجی status مثل یک نقشه

خروجی git status معمولاً سه خبر می‌دهد: روی کدام Branch هستید، چه فایل‌هایی Stagedاند، و چه چیز Unstaged یا Untracked است. تازه‌کارها عجله می‌کنند Commit بزنند؛ حرفه‌ای‌ها اول status را مثل چک‌لیست خلبان می‌خوانند.

اگر فایلی را نمی‌شناسید، قبل از add کردن بازش کنید. بسیاری از فاجعه‌های Secret از همین «add .» عجولانه شروع می‌شود. وقتی شک دارید، فایل‌ها را یکی‌یکی add کنید.

فرمان مفید دیگر:

bash

git diff git diff --staged

اولی تفاوت Working tree با Staging/HEAD را نشان می‌دهد؛ دومی دقیقاً همان چیزی است که وارد Commit بعدی می‌شود. اگر staged خالی است و commit می‌زنید، Git معمولاً اعتراض می‌کند — به اعتراضش گوش بدهید.

ساختار پوشهٔ .git را لمس کنید (بدون خرابکاری)

داخل .git پوشه‌هایی مثل objects، refs و فایل config می‌بینید. لازم نیست دستی ویرایششان کنید. دانستن اینکه تاریخچه اینجاست کمک می‌کند بفهمید پاک کردن .git یعنی از دست دادن کنترل نسخهٔ آن پوشه — در حالی که فایل‌های Working tree ممکن است بمانند.

پشتیبان‌گیری از پروژهٔ Git یعنی هم کد و هم .git (یا Clone از Remote سالم). کپی فقط فایل‌های منبع بدون .git، تاریخچه را نمی‌آورد.

اولین اشتباه‌ها و راه درست جبران

• پیام Commit غلط قبل از Push: امکان amend با آگاهی.
• فایل اضافه در آخرین Commit: دوباره فایل را درست Stage کنید و amend — فقط اگر Push نشده.
• Commit روی Branch اشتباه: معمولاً با جابه‌جایی Commitها یا ساخت Branch از HEAD قابل جبران است؛ عجله نکنید و از reset --hard بدون پشتیبان بپرهیزید.
• init در مسیر غلط: اگر هنوز Commit مهمی ندارید، می‌توانید .git را حذف کنید و در مسیر درست دوباره init کنید.

قانون طلایی جلسهٔ اول: تا وقتی مفهوم را نفهمیده‌اید سراغ بازنویسی تاریخچهٔ اشتراکی نروید. خرابکاری محلی قابل‌تحمل‌تر از Force Push روی main است.

پیوند به عادت‌های حرفه‌ای از همان روز اول

همان جلسه یک فایل .gitignore حداقلی بسازید تا حداقل فایل‌های سیستم‌عامل و وابستگی‌های واضح Commit نشوند. جزئیات در مقالهٔ ۰۸۳ است، ولی حتی دو سه خط اولیه کیفیت تاریخچه را بالا می‌برد.

bash

echo ".DS_Store" >> .gitignore echo "node_modules/" >> .gitignore git add .gitignore git commit -m "Add basic gitignore"

همچنین یک README کوتاه بنویسید: پروژه چیست و چطور اجرا می‌شود. Commit دوم یا سوم مناسب README است؛ منتظر «کامل شدن محصول» نمانید.

معیار موفقیت این آموزش

اگر بتوانید بدون نگاه به چت برای همکارتان روی تخته بکشید که فایل از Working tree چطور به Staging و بعد به Commit می‌رسد، مدل ذهنی را گرفته‌اید. فرمان‌ها حفظی‌اند؛ مدل ذهنی ماندگار است. جلسهٔ بعد را روی Clone یک مخزن واقعی و یک Push کوچک برنامه‌ریزی کنید.

زمان‌بندی واقع‌بینانه: روز اول init/commit، روز دوم remote/push، روز سوم branch. فشردن هر سه در بیست دقیقه بدون تمرین، فقط توهم یادگیری می‌سازد.

تنظیمات مفید اختیاری بعد از روز اول

وقتی چرخهٔ پایه جا افتاد، این‌ها کمک می‌کنند ولی روز صفر اجباری نیستند:

bash

git config --global core.editor "nano" git config --global init.defaultBranch main git config --global color.ui auto

defaultBranch باعث می‌شود مخازن جدید به‌جای نام‌های قدیمی، main بسازند — هم‌خوان با اکثر هاست‌های امروزی. editor را ابزاری بگذارید که بلدید؛ گیر کردن در ادیتور ناشناس اولین Commit را تلخ می‌کند.

تمرین دو: سه Commit معنادار

1. فایل README را گسترش دهید و Commit جدا بزنید.
2. یک فایل کد یا اسکریپت کوچک اضافه کنید؛ Commit جدا.
3. یک غلط املایی را Fix کنید؛ Commit جدا با پیام Fix.

سپس git log --oneline را نگاه کنید. باید سه داستان جدا ببینید. اگر همه چیز در یک Commit قاطی است، تمرین را تکرار کنید — این همان عضلهٔ اتمیک بودن است.

وقتی ادیتور Commit باز می‌شود چه کنیم؟

اگر commit را بدون -m بزنید، ادیتور برای پیام باز می‌شود. خط اول عنوان است؛ خطوطی که با # شروع می‌شوند معمولاً توضیح کمکی‌اند و در پیام نهایی نمی‌آیند (بسته به cleanup). فایل را ذخیره و ادیتور را ببندید تا Commit ثبت شود. اگر ادیتور را بدون ذخیره ببندید، Commit لغو می‌شود — این رفتار امن است.

اگر در vim گیر افتادید: Escape سپس :wq و Enter. یا از قبل core.editor را عوض کنید.

از محلی به همکاری — پل کوتاه

وقتی سه Commit محلی دارید، وقت Remote است. مخزن خالی روی هاست بسازید، remote add کنید، Push کنید، و در UI همان Commitها را ببینید. این لحظهٔ «آها» است که می‌فهمید تاریخچهٔ محلی و Remote یکی شده‌اند.

اگر Push رد شد چون Remote از قبل README داشته و شما هم Commit اولیه دارید، تاریخچه‌ها واگرا شده‌اند. برای تازه‌کار ساده‌ترین راه: مخزن Remote را بدون فایل اولیه بسازید، یا آگاهانه Pull با اجازهٔ unrelated/اجازهٔ Merge طبق راهنمای هاست. عجله برای Force نکنید.

معیار اتمام آموزش صفر

آموزش صفر تمام است وقتی: (۱) بدون کپی کور از چت بتوانید init/add/commit را انجام دهید، (۲) status را ترجمه کنید، (۳) فرق Untracked و Staged را بگویید، (۴) یک بار Push موفق داشته باشید یا حداقل علت شکست را تشخیص دهید. از اینجا به بعد مقالات Clone، Commit خوب، و Branch شما را از سطح بقا به سطح همکاری می‌برند.

اشکال‌زدایی جلسهٔ اول — جدول سریع

این جدول را کنار ترمینال نگه دارید. بیشتر ترس‌های روز اول با status و خواندن پیام خطا حل می‌شوند، نه با حذف .git و شروع مجدد عصبانی.

اگر یک مسیر را سه بار خراب کردید، پوشه را کنار بگذارید و از صفر در پوشهٔ جدید تمرین کنید؛ شرم ندارد. عضله با تکرار تمیز ساخته می‌شود.

گام بعدی یادگیری بعد از این صفحه

ترتیب پیشنهادی: مقالهٔ ۰۷۳ برای Clone پروژه‌های موجود، ۰۷۴ برای کیفیت پیام، ۰۷۵ برای Push/Pull روزانه، ۰۷۶ و ۰۷۷ برای کار موازی. هر مقاله را با یک تمرین بیست‌دقیقه‌ای ببندید نه فقط مطالعه. Git مهارت لمسی است؛ خواندن alone کافی نیست.

اگر در سازمانی هستید، از یک همکار بخواهید PR اول شما را Review کند حتی اگر تغییر آزمایشی باشد. بازخورد روی اولین PR بیشتر از یک فصل کتاب می‌ارزد، به شرطی که محیط امن و بدون شرمساری باشد.

منابع و مراجع

• Pro Git — Getting a Git Repository — https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository
• Pro Git — Recording Changes to the Repository — https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
• Pro Git — First-Time Git Setup — https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
• git-init documentation — https://git-scm.com/docs/git-init
• git-commit documentation — https://git-scm.com/docs/git-commit
• GitHub Docs — About Git (مثال مخزن جدید) — https://docs.github.com/en/get-started/using-git/about-git