Дистрибуирани начини на работа
За разлика од централизираните системи за контрола на верзиите (CVCSs), дистрибуира-ната природа на Git ви овозможува да бидете далеку по флексибилни во начинот на кој девелоперите колаборираат на проектите. Во централизираните системи, секој девелопер е јазол (node) кој што повеќе или помалку подеднакво работи на централна осовина (hub). Во Git, секој девелопер потенцијално е и јазол и осовина, односно секој девелопер може да контрибуира со код во други репозиторија а исто така може да одржува јавно репозитори врз основа на кое другите девелопери ќе ја базираат својата работа, или пак во истото да контрибуираат. Тоа отвора широк дијапазон на потенцијални начини на работа за вашите проекти и/или вашите тимови, па тука ќе покриеме неколку основни парадигми кои што ја користат таа флексибилност. Ќе ги покриеме силните и слабите страни на секој од нив, а вие може да изберете еден од нив да го користите, или пак да ги комбинирате особините од сите нив.
Централизиран начин на работа
Кај централизираните системи, генерално постои еден колаборациски модел - централи-зиран начин на работа. Една централна осовина (hub), или репозитори кое што може да прифаќа изворен код, и сите ја синхронизираат својата работа во однос на тоа репозитори. Девелоперите се јазли(nodes) - конзументи на таа осовина - и ја синхронизираат својата работа кон тоа едно место (види слика 5-1).
Слика 5-1. Централизиран начин на работа.
Тоа значи дека ако два девелопери клонираат од тој хаб и двајцата направат промена, првиот девелопер кој што ќе ги уфрли(push) неговите измени во хабот - тоа ќе го направи без проблем. Вториот девелопер мора да ги спои (merge) неговите измени со измените од првиот девелопер пред да ги уфрли во заедничкото репозитори, за да не бидат пребришани измените од првиот девелопер. Овој коцепт важи и кај Git како што важи и во Subversion (или било кој CVCS), и одлично работи во Git.
Доколку имате мал тим или веќе користите централизиран начин на работа во вашата компанија или тим, многу лесно може да продолжите со таквиот начин на работа и со Git. Едноставно креирајте репозитори, и дајте им на сите членови од тимот права да уфрлаат промени во него; Git нема да дозволи корисниците да си ги пребришуваат измените еден со друг. Доколку еден девелопер клонирал, направил измени, и проба да ги уфрли неговите измени додека некој друг девелопер веќе уфрлил некои измени во меѓувреме, серверот ќе го одбие барањето на тој девелопер. Ќе му биде кажано дека пробува да уфрли измени кои што се non-fast-forward, и тоа нема да може да го направи се додека не ги превземе(fetch) и спои(merge) измените. Овој начин на работа е атрактивен за многу луѓе затоа што е еден вид парадигма со која што многумина се запознаени и задоволни.
Начин на работа на Менаџер за Интеграција
Бидејќи Git дозволува да има повеќе оддалечени репозиторија, може да постои начин на работа каде што секој девелопер ќе има права за запишување единствено во своето репозитори, и права за читање на сите други репозиторија. Ова сценарио најчесто пропишу-ва кое репозитори ќе го претставува “официјалниот” проект. За да учествувате во таков проект, треба да направите јавно репозитори клон на проектот, и да уфрлате измени во него. Понатаму, може да пратите барање до оној што го одржува проектот да ги повлече(pull) вашите промени. Тие можат да го додадат вашето репозитори како оддалечено (remote repository), да ги тестираат вашите промени локално, да ги спојат во нивната гранка на развој, и сето тоа да го уфрлат во нивното репозитори. Процесот функционира вака (види слика 5-2):
1. Одржувачот на проектот уфрла во неговот јавно репозитори. 2. Учесниците го клонираат тоа репозитори и прават измени. 3. Учесникот уфрла во своето јавно репозитори. 4. Учесникот му испраќа e-mail на одржувачот со барање да ги земе/повлече(pull) измените. 5. Одржувачот го додава репозиторито на учесникот како оддалечено и ги спојува изме-ните локално. 6. Одржувачот ги уфрла(push) споените измени во главното репозитори.
Слика 5-2. Начин на работа на Менаџер за Интеграција.
Ова е вообичаен начин на работа кај сајтовите како GitHub, каде што е многу лесно да направите нова гранка од проектот (fork), и да ги уфрлате вашите измени во вашата гранка за да може сите да ги видат. Една од главните предности на овој пристап е тоа што може да си продолжите со работа, а одржувачот на проектот може да ги повлече вашите измени во било кое време. Учесниците не мора да чекаат нивните измени да бидат вклучени во проектот - секој може да си работи според свое темпо.
Dictator and Lieutenants Workflow
This is a variant of a multiple-repository workflow. It’s generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. The benevolent dictator’s repository serves as the reference repository from which all the collaborators need to pull. The process works like this (see Figure 5-3):
- Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
- Lieutenants merge the developers’ topic branches into their master branch.
- The dictator merges the lieutenants’ master branches into the dictator’s master branch.
- The dictator pushes their master to the reference repository so the other developers can rebase on it.
Figure 5-3. Benevolent dictator workflow.
This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, because as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. Now that you can (I hope) determine which workflow combination may work for you, I’ll cover some more specific examples of how to accomplish the main roles that make up the different flows.