-
1. Почеток
- 1.1 За верзиска контрола
- 1.2 Кратка историја на Git
- 1.3 Основи на Гит
- 1.4 Командната линија
- 1.5 Инсталирање на Git
- 1.6 First-Time Git Setup
- 1.7 Getting Help
- 1.8 Заклучок
-
2. Основите на Git
-
3. Гранење во Git
- 3.1 Гранење објаснето
- 3.2 Основно разгранување и спојување
- 3.3 Branch Management
- 3.4 Работни процеси
- 3.5 Далечински гранки
- 3.6 Ребаза
- 3.7 Заклучок
-
4. Git на Сервер
- 4.1 Протоколите
- 4.2 Добивање на Git на сервер
- 4.3 Генерирање на вашиот SSH јавен клуч
- 4.4 Поставување на серверот
- 4.5 Гит демон
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Опции за домаќини на трети лица
- 4.10 Заклучок
-
5. Дистрибуиран Git
- 5.1 Дистрибуирани работни процеси
- 5.2 Придонес кон проект
- 5.3 Приватен мал тим
- 5.4 Одржување на проект
- 5.5 Заклучок
-
6. GitHub
-
7. Git Алатки
- 7.1 Revision Selection
- 7.2 Интерактивно стажирање
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Напредно спојување
- 7.9 Rerere
- 7.10 Дебагирање со Git
- 7.11 Submodules
- 7.12 Збивање
- 7.13 Заменување
- 7.14 Складирање на ингеренции
- 7.15 Заклучок
-
8. Персонализација на Git
- 8.1 Git Configuration
- 8.2 Git Атрибути
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Заклучок
-
9. Git и други системи
- 9.1 Git како Клиент
- 9.2 Мигрирање кон Git
- 9.3 Заклучок
-
10. Внатрешноста на Git
- 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 Заклучок
-
A1. Appendix A: Git во други околини
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Заклучок
-
A2. Appendix B: Вметнување на Git во вашите апликации
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Appendix C: Git команди
- 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 Дистрибуиран Git - Дистрибуирани работни процеси
Сега кога имате оддалечено Git складиште кое е поставено како фокусна точка за сите развивачи да го споделат нивниот код, а вие сте запознаени со основните команди Git во еден локален работен проток, ќе погледнете како да користите некои од дистрибуираните работни чекори дека Git ви овозможува.
Во ова поглавје, ќе видите како да работите со Git во дистрибуирана средина како соработник и интегратор. Тоа е, ќе научите како успешно да придонесете со кодот и да го направите што е можно поедноставно за вас и за одржувачот на проектот, како и за тоа како успешно да го одржувате проектот со голем број на развивачи кои придонесуваат.
Дистрибуирани работни процеси
За разлика од Централизираните системи за контрола на верзии (CVCS), дистрибуираната природа на Git ви овозможува да бидете многу пофлексибилни во тоа како програмерите соработуваат во проекти. Во централизирани системи, секој развивач е јазол кој работи подеднакво подеднакво на централен центар. Меѓутоа, во Git, секој развивач е потенцијално и јазол и центар, односно секој развивач може да придонесе за кодот во други складишта и да одржува јавното складиште на кое другите може да ја базираат својата работа и за што можат да придонесат. Ова отвора широк спектар на можности за работа за вашиот проект и / или вашиот тим, така што ќе покриеме неколку вообичаени парадигми кои ја користат оваа флексибилност. Ќе ги надминеме силните страни и можните слабости на секој дизајн; можете да изберете еден за користење, или можете да ги мешате и да одговарате на функциите од секоја од нив.
Централизиран работен тек
Во централизирани системи, генерално постои единствен модел на соработка - централизиран работен тек. Еден централен центар, или repository, може да прифати код, и сите ги синхронизираат нивните дела со неа. Голем број на развивачи се јазли - потрошувачи на тој центар - и се синхронизираат со тоа едно место.
![Centralized workflow.](png/centralized_workflow.png)
Ова значи дека ако двајца развивачи клонираат од центарот и двете прават промени, првиот инвеститор кој ќе ги притисне своите промени назад може да го стори тоа без никакви проблеми. Вториот развивач мора да се спои во работата на првиот, пред да ги турка промените, за да не ги пребрише промените на првиот инвеститор. Овој концепт е исто како и во Git, како што е во Subversion (или било кој CVCS), и овој модел работи одлично во Git.
Ако веќе сте задоволни со централизиран работен проток во вашата компанија или тим, лесно можете да продолжите да го користите тој работен тек со Git. Едноставно креирајте едно складиште, и на сите им го давајте пристапот до вашиот тим; Git нема да дозволи корисниците да презапишуваат едни со други. Кажи Џон и Џесика да почнат да работат во исто време. Џон ја завршува својата промена и го турка до серверот. Тогаш Џесика се обидува да ги протурка нејзините промени, но серверот ги отфрла. Таа е кажано дека таа се обидува да ги придвижи промените кои не се брзаат напред и дека нема да може да го стори тоа додека не достигне и спои. Овој работен тек е атрактивен за многу луѓе, бидејќи тоа е парадигма со која многумина се запознаени и задоволни.
Ова исто така не е ограничено само на мали тимови. Со разгранетиот модел на Git, можно е стотици програмери успешно да работат на еден проект преку десетици гранки истовремено.
Workflow за интеграција-менаџер
Бидејќи Git ви овозможува да имате повеќе далечински складишта, можно е да имате работно место каде што секој развивач има пристап до запис во сопственото јавното складиште и чита пристап до сите други. Ова сценарио често вклучува канонско складиште кое го претставува "официјалниот" проект. За да придонесете за тој проект, создавате свој јавен клон на проектот и ќе ги промените. Потоа, можете да испратите барање до одржувачот на главниот проект да ги повлече промените. Одржувачот потоа може да го додаде вашето складиште како далечински управувач, да ги тестира промените локално, да ги спои во нивната гранка и да го врати назад во нивното складиште. Процесот функционира на следниот начин (види << wfdiag_b >>):
-
Одржувачот на проектот турка во своето јавно складиште.
-
Еден соработник клонира дека складиштето и прави промени.
-
Соработникот се турка до сопствената јавна копија.
-
Соработникот испраќа одржувач е-мејл барајќи од нив да ги повлечат промените.
-
Одржувачот додава складиште на доверителот како далечински управувач и се спојува локално.
-
Одржувачот ги турка приложените промени во главното складиште.
![Integration-manager workflow.](png/integration-manager.png)
Ова е многу чест работен тек со алатки базирани на Hub, како што се GitHub или GitLab, каде што лесно може да се приклучи проект и да се придвижат вашите промени во вашата вилушка за сите што ќе видат. Една од главните предности на овој пристап е тоа што можете да продолжите да работите, а одржувачот на главното складиште може да се повлече во вашите промени во секое време. Соработниците не мора да чекаат проектот да ги инкорпорира нивните промени - секоја партија може да работи со сопствен чекор.
Работен тек на диктаторот и поручникот
Ова е варијанта на работен тек со повеќе складишта. Тоа генерално се користи од големи проекти со стотици соработници; еден познат пример е Linux кернелот. Различни менаџери за интеграција се одговорни за одредени делови од складиштето; тие се нарекуваат lieutenants. Сите поручители имаат еден менаџер за интеграција познат како добронамерниот диктатор. Добротворниот диктатор турка од неговиот директориум до референтно складиште од кое сите соработници треба да се повлечат. Процесот функционира вака (види << wfdiag_c >>):
-
Редовните програмери работат на нивната тема гранка и rebase нивната работа на врвот на "господар". Гранката
господар
е онаа на референтното складиште на кое диктаторот притиска. -
Поручникот ги обединува гранките на теми на програмерите во нивната "мајсторска" гранка.
-
Диктаторот ги спојува "мајсторите" на поручниците во диктаторската "мајсторска" гранка.
-
Конечно, диктаторот притиска дека "господар" гранка до референтното складиште, така што другите развивачи можат да се ослободат од неа.
![Benevolent dictator workflow.](png/benevolent-dictator.png)
Овој вид на работа не е вообичаен, но може да биде корисен во многу големи проекти или во високо хиерархиски средини. Тоа им овозможува на проектниот лидер (диктаторот) да делегира голем дел од работата и да собира големи подмножества на кодот на повеќе точки пред да ги интегрира.
Краток преглед на работните процеси
Ова се некои најчесто користени работни процеси кои се можни со дистрибуиран систем како Git, но може да се види дека многу варијации се можни за да одговараат на конкретниот работен процес во реалниот свет. Сега, кога можете (се надевам) да одредите која работна комбинација може да ви работи, ќе покриеме некои поспецифични примери за тоа како да ги постигнете главните улоги што ги сочинуваат различните текови. Во следниот дел, ќе дознаете за неколку заеднички обрасци за придонес кон проектот.