-
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. Git on the Server
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Generating Your SSH Public Key
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Summary
-
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. Appendix 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. Appendix 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. Appendix 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 شاخهسازی در گیت - روند کاری شاخهسازی
روند کاری شاخهسازی
حالا که مبانی شاخهسازی و ادغام را میدانید، چه کار باید یا میتوانید با آنها کنید؟ در این بخش ما چندی از روندهای کاری که این حد سبک از شاخهسازی ممکن میکند را بررسی میکنیم تا شما بتوانید تصمیم بگیرید که در روند توسعه خودتان با آنها میخواهید چکار کنید.
Long-Running Branches
از آنجایی که گیت مرج سه طرفهٔ سادهای استفاده میکند، مرج کردن متوالی برنچی به برنچ دیگر عموماً آسان است. این بدان معناست که میتوانید چندین برنچ داشته باشید که همیشه باز هستند و از آنها برای بخشهای مختلف چرخهٔ توسعه خود استفاده کنید؛ میتوانید به طور منظم آنها را در هم دیگر ادغام کنید.
بسیاری از توسعهدهنگان روند کاری دارند که از این رویکرد الهام میگیرد، مثلاً در برنچ master
خود فقط کدهای تماماً پایدار را نگهداری میکنند — که احتمالاً فقط کدی است که یا منتشر شده است یا منتشر خواهد شد.
همچنین احتمالاً آنها برنچی موازی هم با نام develop
یا next
دارند که روی آن کار میکنند یا از آن برای تست ثبات استفاده میکنند — این برنچ لزوماً همیشه باثبات نیست لکن
هنگامی که باثبات میشود در master
مرج میشود.
این برنچ برای پول کردن برنچهای موضوعی آماده استفاده میشود (برنچهای کوتاه عمری مانند iss53
قبلتر) تا از اینکه آنها آماده هستند اطمینان حاصل شود که همهٔ تستها روی
پولها انجام میشود و باگی تولید نمیکنند.
در حقیقت ما دربارهٔ نشانگرهایی که در خطوط کامیتهای تولیدی شما حرکت میکنند حرف میزنیم. برنچ باثبات معمولاً بسیار پایینتر در تاریخچهٔ کامیتهای شما هستند و برنچهای بروز (Bleeding-edge) بسیار بالاتر در تاریخچه قرار دارند.

به طور کل آسانتر است که به برنچها به عنوان سیلوهای کار نگاه کنیم. جایی که وقتی مجموعهای از کامیتها کاملاً تست شدند به سمت سیلویی باثباتتر انتقال داده میشوند.

شما میتوانید این فرآیند را برای چند مرحله از ثبات تکرار کنید.
بعضی از پروژههای بزرگتر همچنین برنچ pu
یا proposed
(بروزرسانی پیشنهادی) دارند که مجتمعی از برنچهایی است که ممکن است هنوز برای راه یافتن به برنچ master
یا next
آماده نباشند.
ایدهٔ کلی این است که برنچهای شما در مرتبههای مختلف ثبات هستند؛ وقتی به مرتبهٔ بالاتری از ثبات رسیدند، به برنچی که در مرتبهٔ بالاتر است مرج خواهند شد.
شایان ذکر است که داشتن چندین برنچها فعال همزمان لزومی ندارد، اما اغلب مفید واقع میشود، به خصوص وقتی که با پروژههای خیلی بزرگ یا پیچیده سروکار دارید.
برنچهای موضوعی
از سوی دیگر برنچهای موضوعی در پروژههایی با هر اندازهای مفید هستند. یک برنچ موضوعی، برنچی کم عمر است که مختص یک کار یا ویژگی خاص میسازید و استفاده میکنید. این کاری است که به احتمال خیلی زیاد هرگز در هیچ VCS دیگر انجام ندادهاید چرا که به طور کل هزینهٔ ساخت و ادغام برنچها زیاد است. لکن در گیت ساختن، ادغام، پاککردن و کار کردن روزانهٔ برنچها رایج است.
شما در بخش قبل هنگام کار با برنچهای iss53
و hotfix
که ساختید متوجه این شدهاید.
شما تعدادی کامیت روی آنها ساختید و آنها را به محض ادغام با برنچ اصلیتان پاک کردید.
این روش به شما این امکان را میدهد که سریعاً و تماماً محتوای کاری را تغییر دهید — به دلیل اینکه کارهای شما به طور مجزا در سیلوهایی است که تمام تغییراتی که در آن
اعمال میشود باید مرتبط با موضوع کار باشد، بسیار آسانتر میتوان از وقایع مرتبط مانند اینکه چه اتفاقی حین بازبینی کد اتفاق افتاده مطلع شد.
شما میتوانید تغییرات خود را در این سیلوها برای دقایق، روزها و یا ماهها نگهداری کنید و وقتی که آماده بودند آنها را بیتوجه به ترتیب کاری یا پیدایش آنها ادغام کنید.
شرایطی را تصور کنید که در حال کار کردن هستید (روی master
)، برای یک ایشو یک برنچ میسازید (iss91
)، کمی روی آن کار میکنید؛ برنچ دومی را میسازید تا همان مسئله را
به صورت دیگری حل کنید (iss91v2
)، به برنچ master
باز میگردید و آنجا کمی فعالیت میکنید و سپس یک برنچ دیگر میسازید تا کمی روی ایدهای که از کارکردش مطمئن نیستید کار کنید (برنچ dumbidea
).
تایخچهٔ کامیتهایتان این شکلی به نظر میرسد:

حال فرض کنیم که فکر میکنید راه حل دوم بهترین راه حل برای این مشکل است (iss91v2
)؛ و برنچ dumbidea
را نیز به همکارتان نشان دادهاید و بسیار هوشمندانه به نظر رسیده است.
شما میتوانید برنچ iss91
را حذف کنید (کامیتهای C5
و C6
را از دست میدهید) و دو برنچ دیگر را ادغام میکنید.
پس از این تاریخچهٔ شما بدین شکل خواهد بود:

dumbidea
و iss91v2
در گیت توزیعشده به جزئیات بیشتر دربارهٔ روندهای کاری متفاوت برای پروژه گیتتان میپردازیم. بنابراین پیش از اینکه تصمیم بگیرید برای پروژه آینده خود چه ساختار شاخهسازی میخواهید، مطمئن باشید که آن فصل را مطالعه کردهاید.
مهم است به خاطر داشته باشید که هنگامی که تمام این کارها انجام میشود، تمام برنچها تماماً محلی هستند. وقتی شاخهسازی یا مرج میکنید، همه چیز فقط در مخزن گیت شما اتفاق میافتد — ارتباطی با سرور برقرار نیست.