-
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)
5.1 گیت توزیع‌شده (Distributed git) - جریان‌های کاری توزیع‌شده (Distributed Workflows)
حال که یک مخزن ریموت گیت راه‌اندازی شده به عنوان کانونی برای تمام توسعه‌دهندگان دارید تا کدهایشان را روی آن به اشتراک بگذارند و شما با دستورات پایهٔ گیت در یک روند کاری محلی آشنایی دارید، به اینکه چگونه از گیت در جهت روندهای کاری توزیع‌شده‌ای که گیت در خدمت شما قرار می‌دهد استفاده کنید، می‌پردازیم.
در این فصل خواهید دید که چگونه به عنوان یک مشارکت‌کننده و یکپارچه‌ساز از گیت در یک محیط توزیع‌شده استفاده کنید. در این مباحث، خواهید آموخت که چگونه در کد یک پروژه مشارکت موفقیت‌آمیز کنید و این کار را برای خود و نگهدارندهٔ پروژه تا حد امکان آسان کنید؛ همچنین اینکه چگونه می‌توان یک پروژه با تعدادی توسعه‌دهنده را به طور موفقیت‌آمیز نگهداری کنید.
جریان‌های کاری توزیع‌شده (Distributed Workflows)
برخلاف سیستم‌های کنترل نسخه متمرکز (CVCSها)، ماهیت توزیع‌شده گیت به شما اجازه می‌دهد که در همکاری توسعه‌دهندگان روی پروژه‌ها بسیار انعطاف‌پذیرتر عمل کنید. در سیستم‌های متمرکز، هر توسعه‌دهنده یک گره است که به طور مساوی با یک هاب مرکزی کار می‌کند. اما در گیت، هر توسعه‌دهنده می‌تواند هم گره باشد و هم هاب؛ یعنی هر توسعه‌دهنده می‌تواند هم به مخازن دیگر کد بدهد و هم یک مخزن عمومی نگهداری کند که دیگران بتوانند روی آن کار کنند و به آن مشارکت دهند. این موضوع امکان‌های گسترده‌ای از جریان‌های کاری را برای پروژه و/یا تیم شما فراهم می‌کند، بنابراین ما چند الگوی رایج که از این انعطاف‌پذیری بهره می‌برند را بررسی خواهیم کرد. ما نقاط قوت و ضعف احتمالی هر طراحی را مرور می‌کنیم؛ شما می‌توانید یکی از آنها را برای استفاده انتخاب کنید یا ویژگی‌های مختلف را ترکیب کنید.
جریان کاری متمرکز (Centralized Workflow)
در سیستم‌های متمرکز معمولاً یک مدل همکاری وجود دارد — جریان کاری متمرکز. یک هاب مرکزی یا مخزن وجود دارد که کد را می‌پذیرد و همه کارهای خود را با آن همگام‌سازی می‌کنند. تعدادی توسعه‌دهنده به عنوان گره — مصرف‌کنندگان آن هاب — کار می‌کنند و با آن مکان مرکزی همگام می‌شوند.
این بدان معناست که اگر دو توسعه‌دهنده از هاب کلون کنند و هر دو تغییراتی ایجاد کنند، اولین توسعه‌دهنده‌ای که تغییراتش را به سرور ارسال کند، بدون مشکل می‌تواند این کار را انجام دهد. توسعه‌دهنده دوم باید قبل از ارسال تغییرات خود، کار توسعه‌دهنده اول را با تغییرات خود ادغام کند تا تغییرات توسعه‌دهنده اول بازنویسی نشود. این مفهوم در گیت همانقدر درست است که در ساب‌ورژن (یا هر CVCS دیگری) درست است، و این مدل در گیت به خوبی کار می‌کند.
اگر شما قبلاً با جریان کاری متمرکز در شرکت یا تیم خود راحت هستید، می‌توانید به راحتی با گیت نیز از همین مدل استفاده کنید. فقط کافی است یک مخزن راه‌اندازی کنید و به همه اعضای تیم دسترسی ارسال (push) بدهید؛ گیت اجازه نمی‌دهد کاربران تغییرات همدیگر را بازنویسی کنند.
فرض کنیم جان و جسیکا هر دو همزمان شروع به کار می‌کنند. جان تغییراتش را تکمیل می‌کند و آنها را به سرور ارسال می‌کند. سپس جسیکا تلاش می‌کند تغییراتش را ارسال کند اما سرور آن را رد می‌کند. به او گفته می‌شود که در تلاش برای ارسال تغییرات غیرپیشرو (non-fast-forward) است و نمی‌تواند این کار را انجام دهد مگر اینکه تغییرات را بگیرد (fetch) و ادغام (merge) کند. این جریان کاری برای بسیاری جذاب است چون الگویی است که بسیاری با آن آشنا و راحت هستند.
این مدل محدود به تیم‌های کوچک نیست. با مدل شاخه‌بندی گیت، صدها توسعه‌دهنده می‌توانند به طور همزمان از طریق ده‌ها شاخه روی یک پروژه کار کنند.
جریان کاری مدیر ادغام (Integration-Manager Workflow)
چون گیت به شما اجازه می‌دهد چند مخزن راه دور داشته باشید، امکان استفاده از جریانی وجود دارد که هر توسعه‌دهنده به مخزن عمومی خودش دسترسی نوشتن دارد و به مخازن دیگران دسترسی خواندن. این حالت معمولاً شامل یک مخزن مرجع است که نمایانگر پروژه “رسمی” است. برای مشارکت در آن پروژه، شما یک کلون عمومی از پروژه ایجاد می‌کنید و تغییرات خود را به آن ارسال می‌کنید. سپس می‌توانید درخواست دهید که نگهدارنده پروژه اصلی تغییرات شما را دریافت کند. نگهدارنده می‌تواند مخزن شما را به عنوان یک مخزن راه دور اضافه کند، تغییرات شما را به صورت محلی تست و ادغام کند، و سپس به مخزن خودش ارسال کند. فرآیند به این صورت است (نگاه کنید به Integration-manager workflow):
-
نگهدارنده پروژه تغییرات را به مخزن عمومی خودش ارسال می‌کند.
-
یک مشارکت‌کننده آن مخزن را کلون می‌کند و تغییراتی ایجاد می‌کند.
-
مشارکت‌کننده تغییراتش را به نسخه عمومی خودش ارسال می‌کند.
-
مشارکت‌کننده ایمیلی به نگهدارنده می‌فرستد و درخواست می‌کند تغییرات را دریافت کند.
-
نگهدارنده مخزن مشارکت‌کننده را به عنوان مخزن راه دور اضافه می‌کند و تغییرات را به صورت محلی ادغام می‌کند.
-
نگهدارنده تغییرات ادغام شده را به مخزن اصلی ارسال می‌کند.
این یک جریان کاری بسیار رایج با ابزارهای مبتنی بر هاب مانند GitHub یا GitLab است که در آن به راحتی می‌توان پروژه را فورک کرد و تغییرات را در فورک خود به اشتراک گذاشت. یکی از مزایای اصلی این روش این است که شما می‌توانید به کار خود ادامه دهید و نگهدارنده مخزن اصلی هر زمان که بخواهد تغییرات شما را دریافت کند. مشارکت‌کنندگان نیازی ندارند منتظر بمانند تا پروژه تغییراتشان را بپذیرد — هر طرف می‌تواند با سرعت خودش کار کند.
جریان کاری دیکتاتور و معاونان (Dictator and Lieutenants Workflow)
این یک زیرمجموعه از جریان کاری چند مخزنه است. معمولاً در پروژه‌های بسیار بزرگ با صدها همکار استفاده می‌شود؛ یک مثال مشهور کرنل لینوکس است. چند مدیر ادغام مسئول بخش‌هایی از مخزن هستند؛ به آنها معاونان گفته می‌شود. تمام معاونان یک مدیر ادغام دارند که به او دیکتاتور خیرخواه گفته می‌شود. دیکتاتور خیرخواه از شاخه خودش به مخزن مرجع که همه همکاران باید از آن بگیرند، ارسال می‌کند. فرآیند به این صورت است (نگاه کنید به Benevolent dictator workflow):
-
توسعه‌دهندگان معمولی روی شاخه موضوعی خود کار می‌کنند و کارشان را روی شاخه
masterبازپایه (rebase) می‌کنند. شاخهmasterمتعلق به مخزن مرجعی است که دیکتاتور به آن ارسال می‌کند. -
معاونان شاخه‌های موضوعی توسعه‌دهندگان را در شاخه
masterخود ادغام می‌کنند. -
دیکتاتور شاخه‌های
masterمعاونان را در شاخهmasterخودش ادغام می‌کند. -
در نهایت دیکتاتور آن شاخه
masterرا به مخزن مرجع ارسال می‌کند تا سایر توسعه‌دهندگان بتوانند روی آن بازپایه کنند.
این نوع جریان کاری رایج نیست، اما در پروژه‌های بسیار بزرگ یا محیط‌های سلسله‌مراتبی بسیار مفید است. این امکان را به رهبر پروژه (دیکتاتور) می‌دهد که بخش زیادی از کار را واگذار کند و مجموعه‌های بزرگی از کد را در چند مرحله جمع‌آوری و سپس ادغام کند.
الگوهایی برای مدیریت شاخه‌های کد منبع (Patterns for Managing Source Code Branches)
|
یادداشت
|
مارتین فاولر راهنمایی به نام "الگوهایی برای مدیریت شاخه‌های کد منبع" تهیه کرده است. این راهنما تمام جریان‌های کاری رایج گیت را پوشش می‌دهد و توضیح می‌دهد که چگونه و چه زمانی از آنها استفاده کنیم. بخشی نیز دارد که فرکانس‌های بالای ادغام و پایین را مقایسه می‌کند. |
خلاصه جریان‌های کاری (Workflows Summary)
این‌ها برخی جریان‌های کاری رایج هستند که با یک سیستم توزیع‌شده مانند گیت امکان‌پذیرند، اما می‌بینید که تنوع زیادی برای تطبیق با جریان کاری واقعی شما وجود دارد. اکنون که (امیدواریم) بتوانید ترکیب مناسبی از جریان‌های کاری را برای خود مشخص کنید، به بررسی مثال‌های مشخص‌تری از چگونگی انجام نقش‌های اصلی در جریان‌های مختلف می‌پردازیم. در بخش بعد، با چند الگوی رایج برای مشارکت در یک پروژه آشنا خواهید شد.
