-
1. شروع به کار (getting started)
-
2. مقدمات گیت (git basics chapter)
- 2.1 گرفتن یک مخزن گیت (Getting a Git Repository)
- 2.2 ثبت تغییرات در مخزن (Recording Changes to the Repository)
- 2.3 مشاهده تاریخچه کامیتها (Viewing the Commit History)
- 2.4 بازگرداندن تغییرات (Undoing Things)
- 2.5 کار کردن با ریموت ها (Working with Remotes)
- 2.6 تگ کردن (Tagging)
- 2.7 نام مستعار گیت (Git Aliases)
- 2.8 خلاصه (summary)
-
3. انشعاب‌گیری در گیت (Git Branching)
-
4. گیت روی سرور (Git on the server)
- 4.1 پروتکلها (The Protocols)
- 4.2 راه‌اندازی گیت روی یک سرور (Getting Git on a Server)
- 4.3 ایجاد کلید عمومی SSH شما (Generating Your SSH Public Key)
- 4.4 نصب و راه‌اندازی سرور (Setting up server)
- 4.5 سرویسدهنده گیت (Git Daemon)
- 4.6 HTTP هوشمند (Smart HTTP)
- 4.7 گیتوب (GitWeb)
- 4.8 گیتلب (GitLab)
- 4.9 گزینههای میزبانی شخص ثالث (Third Party Hosted Options)
- 4.10 خلاصه (Summary)
-
5. گیت توزیع‌شده (Distributed git)
-
6. GitHub (گیت هاب)
-
7. ابزارهای گیت (Git Tools)
- 7.1 انتخاب بازبینی (Revision Selection)
- 7.2 مرحلهبندی تعاملی (Interactive Staging)
- 7.3 ذخیره موقت و پاکسازی (Stashing and Cleaning)
- 7.4 Signing Your Work (امضای کارهای شما)
- 7.5 جستجو (Searching)
- 7.6 بازنویسی تاریخچه (Rewriting History)
- 7.7 بازنشانی به زبان ساده (Reset Demystified)
- 7.8 ادغام پیشرفته (Advanced Merging)
- 7.9 بازاستفاده خودکار از حل تضادها (Rerere)
- 7.10 اشکالزدایی با گیت (Debugging with Git)
- 7.11 سابماژول ها (Submodules)
- 7.12 بستهبندی (Bundling)
- 7.13 جایگزینی (Replace)
- 7.14 ذخیرهسازی اطلاعات ورود (Credential Storage)
- 7.15 خلاصه (Summary)
-
8. سفارشی‌سازی Git (Customizing Git)
-
9. گیت و سیستم‌های دیگر (Git and Other Systems)
-
10. (Git Internals)
- 10.1 ابزارها و دستورات سطح پایین (Plumbing and Porcelain)
- 10.2 اشیا گیت (Git Objects)
- 10.3 مراجع گیت (Git References)
- 10.4 فایل‌های بسته (Packfiles)
- 10.5 نگاشت (The Refspec)
- 10.6 پروتکلهای انتقال (Transfer Protocols)
- 10.7 نگهداری و بازیابی داده‌ها (Maintenance and Data Recovery)
- 10.8 متغیرهای محیطی (Environment Variables)
- 10.9 (Summary)
-
A1. پیوست A: گیت در محیط‌های دیگر (Git in Other Environments)
- A1.1 رابط های گرافیکی (Graphical Interfaces)
- A1.2 Git در ویژوال استودیو (Git in Visual Studio)
- A1.3 Git در Visual Studio Code (Git in Visual Studio Code)
- A1.4 Git در IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine (Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine)
- A1.5 Git در Sublime Text (Git in Sublime Text)
- A1.6 گیت در بش (Git in Bash)
- A1.7 Git در Zsh (Git in Zsh)
- A1.8 Git در PowerShell (Git in PowerShell)
- A1.9 خلاصه (Summary)
-
A2. پیوست B: گنجاندن گیت در برنامه‌های شما (Embedding Git in your Applications)
-
A3. پیوست C: دستورات گیت (Git Commands)
- A3.1 تنظیم و پیکربندی (Setup and Config)
- A3.2 گرفتن و ایجاد پروژهها (Getting and Creating Projects)
- A3.3 نمونهبرداری پایهای (Basic Snapshotting)
- A3.4 انشعاب‌گیری و ادغام (Branching and Merging)
- A3.5 بهاشتراکگذاری و بهروزرسانی پروژهها (Sharing and Updating Projects)
- A3.6 بازرسی و مقایسه (Inspection and Comparison)
- A3.7 عیبیابی (Debugging)
- A3.8 اعمال تغییرات به صورت پچ (Patching)
- A3.9 ایمیل (Email)
- A3.10 سیستم‌های خارجی (External Systems)
- A3.11 مدیریت (Administration)
- A3.12 دستورات سطح پایین گیت (Plumbing Commands)
1.1 شروع به کار (getting started) - درباره ورژن کنترل (About Version Control)
این فصل راجع به آغاز به کار با گیت خواهد بود. در آغاز پیرامون تاریخچهٔ ابزارهای کنترل نسخه توضیحاتی خواهیم داد، سپس به چگونگی راه‌اندازی گیت بر روی سیستم‌تان خواهیم پرداخت و در پایان به تنظیم گیت و کار با آن. در پایان این فصل خواننده علت وجود و استفاده از گیت را خواهد دانست و خواهد توانست محیط کار با گیت را فراهم کند.
درباره ورژن کنترل (About Version Control)
“version control” چیست و چرا باید برایتان مهم باشد؟ “version control” یک سیستم است که تغییرات ایجادشده در یک فایل یا مجموعه‌ای از فایل‌ها را در طول زمان ثبت می‌کند تا بتوانید نسخه‌های خاصی را بعداً بازیابی کنید. در مثال‌های این کتاب، شما از کد منبع نرم‌افزار به‌عنوان فایل‌هایی که تحت "version control" هستند استفاده خواهید کرد، هرچند در واقعیت می‌توانید این کار را با تقریباً هر نوع فایلی در کامپیوتر انجام دهید.
اگر شما یک طراح گرافیک یا وب هستید و می‌خواهید هر نسخه از یک تصویر یا طرح را نگه دارید (که قطعاً هم همین‌طور است)، استفاده از یک "Version Control System (VCS)" انتخاب بسیار هوشمندانه‌ای است. این سیستم به شما اجازه می‌دهد فایل‌های خاصی را به وضعیت قبلی بازگردانید، کل پروژه را به حالت قبل برگردانید، تغییرات را در طول زمان با یکدیگر مقایسه کنید، ببینید چه کسی آخرین بار چیزی را تغییر داده که ممکن است باعث بروز مشکل شده باشد، چه کسی و چه زمانی یک اشکال را وارد کرده، و امکانات بیشتر. استفاده از یک VCS معمولاً به این معناست که اگر چیزی را خراب کردید یا فایل‌ها را از دست دادید، می‌توانید به‌راحتی آن‌ها را بازیابی کنید. علاوه بر این، همه‌ی این امکانات را با سربار بسیار کمی به دست می‌آورید.
سیستم‌های کنترل نسخه محلی (Local Version Control Systems)
روش مورد علاقه‌ی بسیاری از افراد برای "version control" این است که فایل‌ها را در یک پوشه‌ی دیگر کپی می‌کنند (اگر کمی زرنگ‌تر باشند، در یک پوشه با نام‌گذاری زمانی). این روش به‌دلیل سادگی بسیار رایج است، اما در عین حال به‌شدت مستعد خطاست. خیلی راحت ممکن است فراموش کنید که در کدام پوشه هستید و به اشتباه فایل اشتباهی را بازنویسی کنید یا فایل‌هایی را کپی کنید که قصدش را نداشتید.
برای حل این مشکل، برنامه‌نویسان از مدت‌ها پیش سیستم‌های "local VCS" را توسعه دادند؛ سیستم‌هایی که دارای یک پایگاه داده ساده بودند و همه‌ی تغییرات ایجادشده در فایل‌هایی که تحت کنترل نسخه بودند را ثبت می‌کردند.
یکی از محبوب‌ترین ابزارهای "VCS" سیستمی به نام "RCS" بود که هنوز هم همراه با بسیاری از کامپیوترها عرضه می‌شود. "RCS" با نگهداری مجموعه‌ای از پچ ها (یعنی تفاوت‌های بین فایل‌ها) در یک قالب خاص روی دیسک کار می‌کند؛ سپس می‌تواند با جمع‌کردن تمام این پچ ها، هر نسخه‌ای از فایل را در هر نقطه‌ای از زمان بازسازی کند.
سیستم‌های کنترل نسخه متمرکز (Centralized Version Control Systems)
چالش بزرگ بعدی که افراد با آن روبرو می‌شوند این است که نیاز دارند با توسعه‌دهندگانی روی سیستم‌های دیگر همکاری کنند. برای حل این مشکل، سیستم‌های "Centralized Version Control" یا "CVCS" توسعه یافتند. این سیستم‌ها (مانند CVS، Subversion و Perforce) دارای یک سرور مرکزی هستند که تمام فایل‌های نسخه‌بندی‌شده را در خود نگه می‌دارد، و تعدادی کلاینت که فایل‌ها را از آن مکان مرکزی دریافت (checkout) می‌کنند. برای سال‌ها، این روش به‌عنوان استانداردی برای "version control" شناخته می‌شد.
این ساختار نسبت به "local VCS"ها مزایای زیادی دارد. برای مثال، هر کسی تا حدی می‌داند که سایر اعضای پروژه مشغول انجام چه کاری هستند. مدیران (administrators) می‌توانند به‌صورت دقیق کنترل کنند که چه کسی چه کاری انجام دهد، و مدیریت یک "CVCS" بسیار آسان‌تر از رسیدگی به پایگاه‌داده‌های محلی روی هر کلاینت به‌صورت جداگانه است.
با این حال، این ساختار معایب جدی‌ای هم دارد. واضح‌ترین ایراد، نقطه‌ی شکست واحدی است که سرور مرکزی ایجاد می‌کند. اگر آن سرور برای یک ساعت از کار بیفتد، در طول آن مدت هیچ‌کس نمی‌تواند همکاری کند یا تغییرات نسخه‌بندی‌شده‌ی خود را ذخیره کند. اگر دیسکی که پایگاه‌داده‌ی مرکزی روی آن قرار دارد خراب شود و نسخه‌های پشتیبان مناسبی تهیه نشده باشد، همه‌چیز را از دست خواهید داد — کل تاریخچه‌ی پروژه به‌جز تک‌نسخه‌هایی که احتمالاً بعضی افراد روی سیستم‌های محلی‌شان دارند. "local VCS"ها هم از همین مشکل رنج می‌برند — هر زمان که کل تاریخچه‌ی پروژه فقط در یک محل متمرکز باشد، خطر از دست دادن همه‌چیز وجود دارد.
سیستم‌های کنترل نسخه توزیع‌شده (Distributed Version Control Systems)
در اینجا است که "Distributed Version Control Systems" یا "DVCS"ها وارد عمل می‌شوند. در یک "DVCS" (مانند Git، Mercurial یا Darcs)، کلاینت‌ها فقط آخرین نسخه‌ی فایل‌ها را دریافت نمی‌کنند؛ بلکه آن‌ها کل مخزن را همراه با تمام تاریخچه‌ی آن به‌طور کامل کپی می‌کنند. بنابراین، اگر هر سروری از بین برود و این سیستم‌ها از طریق آن سرور با هم همکاری می‌کردند، هر یک از مخازن کلاینت‌ها می‌توانند دوباره روی سرور کپی شوند و آن را بازیابی کنند. هر clone در واقع یک نسخه‌ی پشتیبان کامل از تمام داده‌ها است.
علاوه بر این، بسیاری از این سیستم‌ها به‌خوبی می‌توانند با چندین مخزن راه دور (remote) به‌صورت همزمان کار کنند؛ بنابراین شما می‌توانید در یک پروژه‌ی واحد، به‌طور همزمان با گروه‌های مختلف از افراد، به روش‌های متفاوتی همکاری کنید. این قابلیت به شما اجازه می‌دهد چندین نوع جریان کاری (workflow) مختلف را پیاده‌سازی کنید؛ جریان‌هایی که در سیستم‌های متمرکز ممکن نیستند، مانند مدل‌های سلسله‌مراتبی (hierarchical models).
