-
1. شروع به کار
- 1.1 دربارهٔ کنترل نسخه
- 1.2 تاریخچهٔ کوتاهی از گیت
- 1.3 گیت چیست؟
- 1.4 خط فرمان
- 1.5 نصب گیت
- 1.6 اولین راهاندازی گیت
- 1.7 کمک گرفتن
- 1.8 خلاصه
-
2. مقدمات گیت
- 2.1 دستیابی به یک مخزن گیت
- 2.2 ثبت تغییرات در مخزن
- 2.3 دیدن تاریخچهٔ کامیتها
- 2.4 بازگردانی کارها
- 2.5 کار با ریموتها
- 2.6 برچسبگذاری
- 2.7 نامهای مستعار در گیت
- 2.8 خلاصه
-
3. شاخهسازی در گیت
- 3.1 شاخهها در یک کلمه
- 3.2 شاخهسازی و ادغام مقدماتی
- 3.3 مدیریت شاخه
- 3.4 روند کاری شاخهسازی
- 3.5 شاخههای ریموت
- 3.6 ریبیسکردن
- 3.7 خلاصه
-
4. گیت روی سرور
- 4.1 پروتکلها
- 4.2 راهاندازی گیت در سرور
- 4.3 ساختن کلید عمومی SSH
- 4.4 نصب و راهاندازی سرور
- 4.5 دیمن گیت
- 4.6 HTTP هوشمند
- 4.7 گیتوب
- 4.8 گیتلب
- 4.9 گزینههای شخصی ثالث میزبانی شده
- 4.10 خلاصه
-
5. گیت توزیعشده
- 5.1 روندهای کاری توزیعشده
- 5.2 مشارکت در یک پروژه
- 5.3 نگهداری یک پروژه
- 5.4 خلاصه
-
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. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
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 in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in Eclipse
- A1.5 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.6 Git in Sublime Text
- A1.7 Git in Bash
- A1.8 Git in Zsh
- A1.9 Git in PowerShell
- A1.10 Summary
-
A2. پیوست B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
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 شروع به کار - دربارهٔ کنترل نسخه
این فصل راجع به آغاز به کار با گیت خواهد بود. در آغاز پیرامون تاریخچهٔ ابزارهای کنترل نسخه توضیحاتی خواهیم داد، سپس به چگونگی راهاندازی گیت بر روی سیستمتان خواهیم پرداخت و در پایان به تنظیم گیت و کار با آن. در پایان این فصل خواننده علت وجود و استفاده از گیت را خواهد دانست و خواهد توانست محیط کار با گیت را فراهم کند.
دربارهٔ کنترل نسخه
«کنترل نسخه» چیست و چرا باید بدان پرداخت؟ کنترل نسخه سیستمی است که تغییرات را در فایل یا دستهای از فایلها ذخیره میکند و به شما این امکان را میدهد که در آینده به نسخه و نگارش خاصی برگردید. برای مثالهای این کتاب، شما از سورس کد نرمافزار به عنوان فایلهایی که نسخه آنها کنترل میشود استفاده میکنید. اگرچه در واقع میتوانید تقریباً از هر فایلی استفاده کنید.
اگر شما یک گرافیست یا طراح وب هستید و میخواهید نسخههای متفاوت از عکسها و قالبهای خود داشته باشید (که احتمالاً میخواهید)، یک سیستم کنترل نسخه (Version Control System (VCS)) انتخاب خردمندانهای است. یک VCS به شما این امکان را میدهد که فایلهای انتخابی یا کل پروژه را به یک حالت قبلی خاص برگردانید، روند تغییرات را بررسی کنید، ببینید چه کسی آخرین بار تغییری ایجاد کرده که احتمالاً مشکل آفرین شده، چه کسی، چه وقت مشکلی را اعلام کرده و… استفاده از یک VCS همچنین به این معناست که اگر شما در حین کار چیزی را خراب کردید و یا فایلهایی از دست رفت، به سادگی میتوانید کارهای انجام شده را بازیابی نمایید. همچنین مقداری سربار به فایلهای پروژهتان افزوده میشود.
سیستمهای کنترل نسخهٔ محلی
روش اصلی کنترل نسخهٔ کثیری از افراد کپی کردن فایلها به پوشهای دیگر است (احتمالاً با تاریخگذاری، اگر خیلی باهوش باشند). این رویکرد به علت سادگی بسیار رایج است هرچند خطا آفرینی بالایی دارد. فراموش کردن اینکه در کدام پوشه بودهاید و نوشتن اشتباهی روی فایل یا فایلهایی که نمیخواستید روی آن بنویسید بسیار آسان است.
برای حل این مشکل، سالها قبل VCSهای محلی را توسعه دادند که پایگاه دادهای ساده داشت که تمام تغییرات فایلهای تحت مراقبتش را نگهداری میکرد.
![Local version control diagram](png/local.png)
یکی از شناختهشدهترین ابزاریهای کنترل نسخه، سیستمی به نام RCS بود که حتی امروز، با بسیاری از کامپیوترها توزیع میشود. RCS با نگه داشتن مجموعههایی از پچها (Patch/وصله) — همان تفاوتهای بین نگارشهای گوناگون فایلها — در قالبی ویژه کار میکند؛ پس از این، با اعمال پچها میتواند هر نسخهای از فایل که مربوط به هر زمان دلخواه است را بازسازی کند.
سیستمهای کنترل نسخهٔ متمرکز
چالش بزرگ دیگری که مردم با آن روبرو میشوند نیاز به همکاری با توسعهدهندگانی است که با سیستمهای دیگر کار میکنند. دربرخورد با این چالش سیستمهای کنترل نسخه متمرکز (Centralized Version Control System (CVCS)) ایجاد شدند. این قبیل سیستمها (مثل CVS، سابورژن و Preforce) یک سرور دارند که تمام فایلهای نسخهبندی شده را در بر دارد و تعدادی کلاینت (Client/خدمتگیرنده) که فایلهایی را از آن سرور چکاوت (Checkout/وارسی) میکنند. سالهای سال این روش استاندارد کنترل نسخه بوده است.
![Centralized version control diagram](png/centralized.png)
این ساماندهی به ویژه برای VCSهای محلی منافع و مزایای بسیاری دارد. به طور مثال هر کسی به میزان مشخصی از فعالیتهای دیگران روی پروژه آگاهی دارد. مدیران دسترسی و کنترل مناسبی بر این دارند که چه کسی چه کاری میتواند انجام دهد؛ همچنین مدیریت یک CVCS خیلی آسانتر از درگیری با پایگاهدادههای محلی روی تک تک کلاینتهاست.
هرچند که این گونه ساماندهی معایب جدی نیز دارد. واضحترین آن رخدادن خطا در سروری که نسخهها در آن متمرکز شدهاند است. اگر که سرور برای یک ساعت غیرفعال باشد، در طول این یک ساعت هیچکس نمیتواند همکاری یا تغییراتی که انجام داده است را ذخیره نماید. اگر هارددیسک سرور مرکزی دچار مشکلی شود و پشتیبان مناسبی هم تهیه نشده باشد همه چیز (تاریخچه کامل پروژه بجز اسنپشاتهایی که یک کلاینت ممکن است روی کامپیوتر خود ذخیره کرده باشد) از دست خواهد رفت. VCSهای محلی نیز همگی این مشکل را دارند — هرگاه کل تاریخچه پروژه را در یک مکان واحد ذخیره کنید، خطر از دست دادن همه چیز را به جان میخرید.
سیستمهای کنترل نسخه توزیعشده
اینجا است که سیستمهای کنترل نسخه توزیعشده (Distributed Version Control System (DVCS)) نمود پیدا میکنند. در یک DVCS (مانند گیت، Mercurial، Bazaar یا Darcs) کلاینتها صرفاً به چکاوت کردن آخرین اسنپشات فایلها اکتفا نمیکنند؛ بلکه آنها کل مخزن (Repository) را کپی عینی یا آینه (Mirror) میکنند که شامل تاریخچه کامل آن هم میشود. بنابراین اگر هر سروری که سیستمها به واسطه آن در حال تعامل با یکدیگر هستند متوقف شده و از کار بیافتد، با کپی مخرن هر کدام از کاربران بر روی سرور، میتوان آن را بازیابی کرد. در واقع هر کلون، پشتیبان کاملی از تمامی دادهها است.
![Distributed version control diagram](png/distributed.png)
علاوه بر آن اکثر این سیستمها تعامل کاری خوبی با مخازن متعدد خارجی دارند و از آن استقبال میکنند، در نتیجه شما میتوانید با گروههای مختلفی به روشهای مختلفی در قالب پروژهای یکسان بهصورت همزمان همکاری کنید. این قابلیت این امکان را به کاربر میدهد که چندین جریان کاری متنوع، مانند مدلهای سلسه مراتبی، را پیادهسازی کند که انجام آن در سیستمهای متمرکز امکانپذیر نیست.