-
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
5.1 گیت توزیعشده - روندهای کاری توزیعشده
حال که یک مخزن ریموت گیت راهاندازی شده به عنوان کانونی برای تمام توسعهدهندگان دارید تا کدهایشان را روی آن به اشتراک بگذارند و شما با دستورات پایهٔ گیت در یک روند کاری محلی آشنایی دارید، به اینکه چگونه از گیت در جهت روندهای کاری توزیعشدهای که گیت در خدمت شما قرار میدهد استفاده کنید، میپردازیم.
در این فصل خواهید دید که چگونه به عنوان یک مشارکتکننده و یکپارچهساز از گیت در یک محیط توزیعشده استفاده کنید. در این مباحث، خواهید آموخت که چگونه در کد یک پروژه مشارکت موفقیتآمیز کنید و این کار را برای خود و نگهدارندهٔ پروژه تا حد امکان آسان کنید؛ همچنین اینکه چگونه میتوان یک پروژه با تعدادی توسعهدهنده را به طور موفقیتآمیز نگهداری کنید.
روندهای کاری توزیعشده
برخلاف سیستمهای کنترل نسخه متمرکز (CVCS)، نفس توزیعشدهٔ گیت به شما این اجازه میدهد تا در اینکه چگونه توسعهدهندهها روی پروژهها همکاری میکنند انعطاف خیلی بیشتری داشته باشید. در سیستمهای متمرکز، هر توسعهدهنده یک گره فعال است که کموبیش به طور برابر با دیگران با هاب مرکزی کار میکند. لکن در گیت هر توسعهدهنده میتواند هم یک گره باشد هم یک هاب؛ اینگونه، هر توسعهدهنده هم میتواند در کد مخازن دیگر مشارکت کند و یک مخزن عمومی داشته باشد که دیگران میتوانند روی آنها کار کنند و در آن مشارکت کنند. این اصل طیف زیادی از روندهای کاری ممکن برای پروژه و/یا تیم شما ارائه میکند؛ به همین دلیل ما چند نمونه از آنها را بررسی خواهیم کرد تا از این انعطافپذیری نهایت استفاده را ببریم. به نقاط قوت و ضعف احتمالی هر طراحی خواهیم پرداخت؛ شما میتوانید یکی از این طراحیها را انتخاب کنید، یا میتوانید آنها را ترکیب کنید و از هرکدام یک ویژگی برگزینید.
روند کاری متمرکز
در سیستمهای متمرکز، غالباً یک مدل همکاری وجود دارد — روند کاری متمرکز. یک هاب یا مخزن مرکزی قادر است کدها را بپذیرد و همه کار خود را با آن همگامسازی میکنند. تعدادی توسعهدهنده گرههای این شبکه هستند — مشتریهای هاب — و با آن نقطهٔ مرکزی همگامسازی میکنند.
![Centralized workflow.](png/centralized_workflow.png)
این بدان معناست که اگر دو توسعهدهنده از هاب کلون کنند و هر دو تغییراتی را اعمال کنند، اولین توسعهدهندهای که تغییرات را پوش کند، میتواند بیمشکل این کار را انجام دهد. اما دومین توسعهدهنده باید قبل از پوش کردن کار نفر اول را ادغام کند تا منجر به بازنویسی روی کارهای توسعهدهندهٔ اول نشوند. این مفهوم در گیت هم به اندازهٔ سابورژن (یا هر CVCS دیگری) برقرار است و این مدل کاری در گیت هم به طور بینقص کار میکند.
اگر از قبل به روند کاری متمرکز در کمپانی یا تیم خود عادت دارید، به سادگی میتوانید همان روند را ادامه دهید. خیلی ساده یک مخزن راهاندازی کنید، به تمام افراد تیم خود دسترسی پوش بدهید؛ گیت اجازه نخواهد داد که کاربران تغییرات یکدیگر را بازنویسی کنند.
فرض کنیم که جان و جسیکا هر دو در حال کار همزمان هستند. جان تغییرات خود را تمام میکند و آنها را روی سرور پوش میکند. سپس جسیکا سعی میکند که تغییرات خود را پوش کند، اما سرور آنها را رد میکند. به او گفته میشود که او سعی در پوش کردن تغییرات غیر fast-forward است و تا زمانی که فچ و مرج نکند، نخواهد توانست چنین کاری را انجام دهد. این روند کاری جذابی برای کثیری از افراد است، چرا که روشی است که خیلیها با آن احساس راحتی میکنند و با آن آشنا هستند.
بعلاوه، این روش به تیمهای کوچک محدود نیست. با مدل شاخهسازی گیت، ممکن است که صدها توسعهدهنده به طور موفقیتآمیز و همزمان به وسیلهٔ هزاران برنچ، روی یک پروژه کار کنند.
روند کاری مدیر-یکپارچهسازی
از این جهت که گیت به شما اجازهٔ داشتن چندین مخزن ریموت را میدهد، این امکان وجود دارد که روند کاری داشته باشید که در آن هر توسعهدهنده اجازهٔ نوشتن به مخزن عمومی خودش را دارد و اجازهٔ خواندن از مخازن دیگران را دارد. در این سناریو معمولاً یک مخزن استاندارد و مرکزی وجود دارد که نقش پروژهٔ «رسمی» را بازی میکند. برای مشارکت در آن پروژه، شما کلون عمومی خود را از پروژه میسازید و تغییرات خود را به آن پوش میکنید. سپس میتوانید به نگهدارندهٔ پروژهٔ اصلی درخواستی ارسال کنید تا تغییرات شما را پول کند. نگهدارندهٔ مذکور پس از این، میتواند مخزن شما را به عنوان یک ریموت اضافه کند، تغییرات شما را به طور محلی تست کند، آنها را در برنچ خودش مرج کند و به مخزن خودش پوش کند. این فرآیند به صورت زیر است (روند کاری مدیر-یکپارچهسازی. را نگاه کنید):
-
نگهدارندهٔ پروژه به مخزن عمومی پوش میکند.
-
یک مشارکتکننده آن را کلون میکند و تغییراتی اعمال میکند.
-
مشارکتکننده به کپی عمومی خودش پوش میکند.
-
مشارکتکننده ایمیلی به نگهدارنده میفرستد و از او میخواهد که تغییرات را پول کند.
-
نگهدارنده مخزن مشارکتکننده را به عنوان یک ریموت اضافه میکند به صورت محلی مرج میکند.
-
نگدارنده مرج تغییرات را به مخزن اصلی پوش میکند.
![Integration-manager workflow.](png/integration-manager.png)
این روند کاری رایجی بین ابزارهای هاب-پایه مانند گیتهاب و گیتلب است، در این ابزارها فورک کردن یک پروژه و پوش کردن تغییراتتان به فورکتان جهت استفاده همه آسان است. یکی از اصلیترین مزیتهای این روش این است که میتوانید به کار کردن ادامه دهید و نگهدارندهٔ مخزن اصلی میتواند در هر زمانی پول کند. مشارکتکنندگان مجبور نیستند منتظر پروژه بمانند تا تغییرات خود را معرفی کنند — هر گروه میتواند با سرعتی که صلاح میداند کار کند.
روند کاری دیکتاتور و ستوانها
این روند، نوعی روند کاری چند-مخزنی است. عموماًاین روش برای پروژههای بزرگ با صدها مشارکتکننده به کار میرود؛ یکی از مثالهای معروف هستهٔ لینوکس است. مدیران یکپارچهسازی مختلف مسئول بخشهای مختلف پروژه هستند؛ به آنها ستوان گفته میشود. همهٔ ستوانها یک مدیر یکپارچهسازی به نام دیکتاتور کریم دارند. دیکتاتور کریم از پوشهٔ خود به یک مخزن مرجع پوش میکند که همهٔ مشارکتکنندگان مستلزم پول کردن از آن هستند. فرآیند به این شکل کار میکند (روندکاری رهبر کریم. را ببینید):
-
توسعهدهندگان معمولی روی برنچ موضوعی خود کار میکنند و تغییرات را به نوک
master
ریبیس میکنند. برنچmaster
آن برنچی از مخزن مرجع است که دیکتاتور به آن پوش میکند. -
ستوانها برنچهای موضوعی توسعهدهندگان را به برنچ
master
خود پوش میکنند. -
دیکتاتور برنچهای
master
ستوانها را باmaster
دیکتاتور ادغام میکند. -
در آخر دیکتاتور به آن برنچ
master
در مخزن مرجع پوش میکند تا دیگر توسعهدهندگان بتوانند روی آن ریبیس کنند.
![Benevolent dictator workflow.](png/benevolent-dictator.png)
این نوع روند کاری رایج نیست، اما میتواند در پروژههای بزرگ یا در محیطهای خیلی سلسله مراتبی مفید باشد. به رهبر پروژه (دیکتاتور) این امکان را میدهد تا بخش عظیمی از کار را واگذار کند و پیش از یکپارچهسازی کد بخشهای اعظمی از آنرا از جاهای مختلف گردآوری کند.
خلاصهٔ روندهای کاری
انگشت شماری روند کاری رایج وجود دارد که معمولاً با سیستم توزیعشدهای مانند گیت اجرا میشود، اما اکنون میبینید که مشتقات بسیار بیشتری قابل پیادهسازی است که میتواند با روند کاری واقعی شما تطبیق پیدا کند. حال که (به احتمال زیاد) میتوانید به اینکه چه ترکیبی از روندهای کاری برای شما مناسب است پی ببرید، چند مورد جزئیتر از اینکه «چگونه میتوان نقشهای اصلی را به نحوی ایفا کرد که روندهای مختلف را بسازند» بررسی خواهیم کرد. در بخش بعد، چند الگوی رایج مشارکت در یک پروژه را یاد خواهید گرفت.