برخلاف سیستم‌های کنترل نسخه متمرکز (CVCS)، نفس توزیع‌شدهٔ گیت به شما این اجازه می‌دهد تا در اینکه چگونه توسعه‌دهنده‌ها روی پروژه‌ها همکاری می‌کنند انعطاف خیلی بیشتری داشته باشید. در سیستم‌های متمرکز، هر توسعه‌دهنده یک گره فعال است که کم‌وبیش به طور برابر با دیگران با هاب مرکزی کار می‌کند. لکن در گیت هر توسعه‌دهنده می‌تواند هم یک گره باشد هم یک هاب؛ اینگونه، هر توسعه‌دهنده هم می‌تواند در کد مخازن دیگر مشارکت کند و یک مخزن عمومی داشته باشد که دیگران می‌توانند روی آنها کار کنند و در آن مشارکت کنند. این اصل طیف زیادی از روندهای کاری ممکن برای پروژه و/یا تیم شما ارائه می‌کند؛ به همین دلیل ما چند نمونه از آنها را بررسی خواهیم کرد تا از این انعطاف‌پذیر نهایت استفاده را ببریم. به نقاط قوت و ضعف احتمالی هر طراحی خواهیم پرداخت؛ شما می‌توانید یکی از این طراحی‌ها را انتخاب کنید، یا می‌توانید که آنها را ترکیب کنید و از هرکدام یک ویژگی برگزینید.
در سیستم‌های متمرکز، غالباً یک مدل همکاری وجود دارد — روند کاری متمرکز. یک هاب یا مخزن مرکزی قادر است کدها را بپذیرد و همه کار خود را با آن همگام‌سازی می‌کنند. تعدادی توسعه‌دهنده گره‌های این شبکه هستند — مشتری‌های هاب — و کار خود را با آن نقطهٔ مرکزی همگام‌سازی می‌کنند.
این بدان معناست که اگر دو توسعه‌دهنده از هاب کلون کنند و هر دو تغییراتی را اعمال کنند، اولین توسعه‌دهنده‌ای که بخواهد تغییرات را پوش کند، می‌تواند بی‌مشکل این کار را انجام دهد. اما دومی توسعه‌دهنده باید کار نفر اول را قبل از پوش کردن ادغام کند تا منجر به بازنویسی روی کارهای توسعه‌دهندهٔ اول نشوند. این مفهوم در گیت هم به اندازهٔ ساب‌ورژن (یا هر CVCS دیگری) برقرار است و این مدل کاری در گیت هم به طور بی‌نقص کار می‌کند.
اگر از قبل به روند کاری متمرکز در کمپانی یا تیم خود عادت دارید، به سادگی می‌توانید همان روند را ادامه دهید. خیلی ساده یک مخزن راه‌اندازی کنید، به تمام افراد تیم خود دسترسی پوش بدهید؛ گیت اجازه نخواهد داد که کاربران تغییرات یکدیگر را بازنویسی کنند.
فرض کنیم که جان و جسیکا هر دو در حال کار همزمان هستند. جان تغییرات خود را تمام می‌کند و آنها را روی سرور پوش می‌کند. سپس جسیکا سعی می‌کند که تغییرات خود را پوش کند، اما سرور آنها را رد می‌کند. به او گفته می‌شود که اون سعی در پوش کردن تغییرات غیر-fast-forward است و تا زمانی که فچ و مرج نکند، نخواهد توانست چنین کاری را انجام دهد. این روند کاری افراد زیادی را جذب خود می‌کند، چرا که روشی است که کثیری از افراد با آن احساس راحتی می‌کنند و آشنا هستند.
بعلاوه، این روش به تیم‌های کوچک محدود نیست. با مدل شاخه‌سازی گیت، می‌توانید صدها توسعه‌دهنده داشته باشید تا به طور موفقیت‌آمیز و همزمان به وسیلهٔ هزاران برنچ، همزمان روی یک پروژه کار کنند.
از این جهت که گیت به شما اجازهٔ داشتن چندین مخزن ریموت را می‌دهد، این امکان وجود دارد که روند کاری داشته باشید که در آن هر توسعه‌دهنده اجازهٔ نوشتن به مخزن عمومی خودش را دارد و اجازهٔ خواندن از مخازن دیگران را دارد. در این سناریو معمولاً یک مخزن استاندارد و مرکزی وجود دارد که نقش پروژهٔ «رسمی» را بازی می‌کند. برای مشارکت در آن پروژه، مشا کلون عمومی خود را از پروژه می‌سازید و تغییرات خود را به آن پوش می‌کنید. سپس می‌توانید به نگهدارندهٔ پروژهٔ اصلی درخواستی ارسال کنید تا تغییرات شما را پول کند. نگهدارندهٔ مذکور پس از این، می‌تواند مخزن شما را به عنوان یک ریموت اضافه کند، تغییرات شما را به طور محلی تست کند، آنها را در برنچ خودش مرج کند و به مخزن خودش پوش کند. این فرآیند به صورت زیر است (روند کاری مدیر-یکپارچه‌سازی. را نگاه کنید):
-
نگهدارندهٔ پروژه به مخزن عمومی پوش می‌کند.
-
یک همکار آن را کلون می‌کند و تغییراتی اعمال می‌کند.
-
همکار به کپی عمومی خودش پوش می‌کند.
-
همکار ایمیلی به نگهدارنده می‌فرستد و از او می‌خواهد که تغییرات را پول کند.
-
نگهدارنده مخزن همکار را به عنوان یک ریموت اضافه می‌کند به صورت محلی مرج می‌کند.
-
نگدارنده مرج تغییرات را به مخزن اصلی پوش می‌کند.
این روند کاری رایجی بین ابزارهای هاب-پایه مانند گیت‌هاب و گیت‌لَب است، در این ابزارها فورک کردن یک پروژه و پوش کردن تغییرات‌تان به فورکتان برای همه آسان است. یکی از اصلی‌ترین مزیت‌های این روش این است که می‌توانید به کار کردن ادامه دهید و نگهدارندهٔ مخزن اسصلی می‌تواند در هر زمانی پول کند. مشارکت‌کنندگان مجبور نیستند منتظر پروژه بمانند تا تغییرات خود را معرفی کنند — هر گروه می‌تواند با سرعتی که صلاح می‌داند کار کند.
ن این روند، نوعی روند کاری چند-مخزنی است. عموماً‌این روش برای پروژه‌های بزرگ با صدها مشارکت‌کننده به کار می‌رود؛ یکی از مثال‌های معروف هستهٔ لینوکس است. مدیران یکپارچه‌سازی مختلف مسئول بخش‌های مختلف پروژه هستند؛ به آنها ستوان (Lieutenant) گفته می‌شود. همهٔ ستوان‌ها یک مدیر یکپارچه‌سازی به نام دیکتاتور کریم دارند. دیکتاتور کریم از پوشهٔ خود به یک مخزن مرجع پوش می‌کند که همهٔ مشارکت‌کنندگان مستلزم پول کردن از آن هستند. فرآیند به این شکل کار می‌کند (روندکاری رهبر کریم را ببینید):
-
توسعه‌دهندگان معمولی روی برنچ موضوعی خود کار می‌کنند و تغییرات را به نوک
masterریبیس می‌کنند. برنچmasterآن برنچی از مخزن مرجع است که دیکتاتور به آن پوش می‌کند. -
ستوان‌ها برنچ‌های موضوعی توسعه‌دهندگان را به برنچ
masterخود پوش می‌کنند. -
دیکتاتور برنچ‌های
masterستوان‌ها را باmasterدیکتاتور ادغام می‌کند. -
در آخر دیکتاتور به آن برنچ
masterدر مخزن مرجع پوش می‌کند تا دیگر توسعه‌دهندگان بتوانند روی آن ریبیس کنند.
این نوع روند کاری رایج نیست، اما می‌تواند در پروژه‌های بزرگ یا در محیط‌های خیلی سلسله مراتبی مفید باشد. به رهبر پروژه (دیکتاتور) این امکان را می‌دهد تا بخش عظیمی از کار را واگذار کند و پیش از یکپارچه‌سازی کد بخش‌های اعظمی از آنرا از جاهای مختلف گردآوری کند.
انگشت شماری روند کاری رایج وجود دارد که معمولاً با سیستم توزیع‌شده‌ای مانند گیت اجرا می‌شود، اما اکنون می‌بینید که مشتقات بسیار بیشتری قابل پیاده‌سازی است که می‌تواند با روند کاری واقعی شما تطبیق پیدا کند. حال که (به احتمال زیاد) می‌توانید به اینکه چه ترکیبی از روندهای کاری برای شما مناسب است پی ببرید، چند مورد جزئی تر از اینکه «چگونه می‌توان نقش‌های اصلی را به نحوی ایفا کرد که روندهای مختلف را بسازند» بررسی خواهیم کرد. در بخش بعد، چند الگوی رایج مشارکت در یک پروژه را یاد خواهید گرفت.