-
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
3.4 شاخهسازی در گیت - روند کاری شاخهسازی
روند کاری شاخهسازی
حالا که مبانی شاخهسازی و ادغام را میدانید، چه کار میتوانید یا باید با آنها کنید؟ در این بخش چندی از روندهای کاری که این حد سبک از شاخهسازی ممکن میکند را بررسی میکنیم تا شما بتوانید تصمیم بگیرید که در روند توسعه خودتان با آنها میخواهید چکار کنید.
شاخههای با قدمت
از آنجایی که گیت از مرج سه طرفهٔ سادهای استفاده میکند، مرج کردن متوالی برنچی به برنچ دیگر عموماً آسان است. این بدان معناست که میتوانید چندین برنچ داشته باشید که همیشه باز هستند و از آنها برای بخشهای مختلف چرخهٔ توسعه خود استفاده کنید؛ میتوانید به طور منظم آنها را در یکدیگر ادغام کنید.
بسیاری از توسعهدهنگان روند کاری دارند که این رویکرد را در بر میگیرد، مثلاً در برنچ master
خود فقط کدهای تماماً پایدار را نگهداری میکنند — که احتمالاً فقط کدی است که یا منتشر شده است یا منتشر خواهد شد.
همچنین احتمالاً آنها برنچی موازی هم با نام develop
یا next
دارند که روی آن کار میکنند یا از آن برای تست ثبات استفاده میکنند — این برنچ لزوماً همیشه باثبات نیست لکن
هرگاه که به وضعیت باثباتی برسد میتواند در master
مرج شود.
هنگام آماده شدن برنچهای موضوعی (برنچهای کوتاه عمری مانند iss53
قبلترتان) این برنچ برای پول کردن آنها استفاده میشود تا از اینکه آنها همهٔ تستها را پاس میشوند و باگی تولید نمیکنند اطمینان حاصل شود.
در حقیقت ما دربارهٔ نشانگرهایی که در خطوط کامیتهای تولیدی شما حرکت میکنند حرف میزنیم. برنچ باثبات معمولاً بسیار پایینتر در خط تاریخچهٔ کامیتهای شما هستند و برنچهای بروز (Bleeding-edge) بسیار بالاتر در تاریخچه قرار دارند.
![A linear view of progressive-stability branching.](png/lr-branches-1.png)
به طور کل آسانتر است که به برنچها به عنوان سیلوهای کار نگاه کنیم. جایی که وقتی مجموعهای از کامیتها کاملاً تست شدند به سمت سیلویی باثباتتر انتقال داده میشوند.
![A ``silo'' view of progressive-stability branching.](png/lr-branches-2.png)
شما میتوانید این فرآیند را برای چند مرتبه از ثبات تکرار کنید.
بعضی از پروژههای بزرگتر همچنین برنچ pu
یا proposed
(بروزرسانی پیشنهادی) دارند که مجتمعی از برنچهایی است که ممکن است هنوز برای راه یافتن به برنچ master
یا next
آماده نباشند.
ایدهٔ کلی این است که برنچهای شما در مرتبههای مختلف ثبات هستند؛ وقتی به مرتبهٔ بالاتری از ثبات رسیدند، در برنچی که در مرتبهٔ بالاتر است مرج خواهند شد.
مجدداً، داشتن چندین برنچها فعال همزمان لزومی ندارد، اما اغلب مفید است، به خصوص وقتی که با پروژههای خیلی بزرگ یا پیچیده سروکار دارید.
شاخههای موضوعی
برنچهای موضوعی، از سوی دیگر، در پروژههایی با هر اندازه مفید هستند. یک برنچ موضوعی، برنچی کم عمر است که مختص یک کار یا ویژگی خاص میسازید و استفاده میکنید. این کاری است که به احتمال خیلی زیاد، هرگز در هیچ VCS دیگر انجام ندادهاید چرا که به طور کل هزینهٔ ساخت و ادغام برنچها زیاد است. لکن در گیت ساختن، ادغام، پاککردن و کار کردن روزانهٔ برنچها رایج است.
در بخش قبل هنگام کار با برنچهای iss53
و hotfix
که ساختید متوجه این شدهاید.
شما تعدادی کامیت روی آنها ساختید و آنها را به محض ادغام با برنچ اصلیتان پاک کردید.
این روش به شما این امکان را میدهد که سریعاً و تماماً محتوای کاری را تغییر دهید — از آنجایی که کارهای شما به سیلوهایی مجزا تقسیم شده که تمام تغییراتی که در آن برنچ اعمال میشود باید مرتبط با آن موضوع باشد، اطلاع از اتفاقاتی که حین بازبینی کد و غیره افتاده بسیار آسانتر است.
شما میتوانید تغییرات خود را برای دقایق، روزها و یا ماهها نگهداری کنید و وقتی آماده بودند آنها را بیتوجه به ترتیب کاری یا پیدایش آنها ادغام کنید.
شرایطی را تصور کنید که در حال کار کردن (روی master
) هستید، برای یک ایشو یک برنچ میسازید (iss91
)، کمی روی آن کار میکنید، برنچ دومی را میسازید تا همان مسئله را
به صورت دیگری حل کنید (iss91v2
)، به برنچ master
خود باز میگردید و آنجا کمی فعالیت میکنید و سپس یک برنچ دیگر میسازید تا کمی روی ایدهای که مطمئن نیستید خوب است یا خیر کار کنید (برنچ dumbidea
).
تایخچهٔ کامیتهایتان این شکلی به نظر خواهد رسید:
![Multiple topic branches.](png/topic-branches-1.png)
حال فرض کنیم که فکر میکنید راه حل دوم بهترین راه حل برای این مشکل است (iss91v2
)؛ و برنچ dumbidea
را نیز به همکارتان نشان دادهاید و بسیار هوشمندانه به نظر رسیده است.
شما میتوانید برنچ iss91
را حذف کنید (کامیتهای C5
و C6
را از دست میدهید) و دو برنچ دیگر را ادغام میکنید.
پس از این تاریخچهٔ شما بدین شکل خواهد بود:
![History after merging `dumbidea` and `iss91v2`.](png/topic-branches-2.png)
dumbidea
و iss91v2
در گیت توزیعشده به جزئیات بیشتر دربارهٔ روندهای کاری متفاوت برای پروژه گیتتان میپردازیم، بنابراین پیش از اینکه تصمیم بگیرید برای پروژه آینده خود چه ساختار شاخهسازی میخواهید، مطمئن باشید که آن فصل را مطالعه کردهاید.
مهم است به خاطر داشته باشید که هنگامی که تمام این کارها انجام میشود، تمام برنچها تماماً محلی هستند. وقتی شاخهسازی یا مرج میکنید، همه چیز فقط در مخزن گیت شما اتفاق میافتد — ارتباطی با سرور برقرار نیست.