Скотт Чакон - Pro Git

Теперь, Джессика может слить изменения тематической ветки и изменения Джона (origin/master) в свою локальную ветку master, а затем отправить её на сервер. Для начала, следует переключиться на ветку master и слить изменения тематической ветки:

$git checkout master

Switched to branch 'master'

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

Обе ветки origin/master и issue54 являются отслеживаемыми, поэтому порядок слияния не важен. Конечный результат будет идентичным вне зависимости от порядка слияния, однако история коммитов будет немного отличаться. Джессика решает слить ветку issue54 первой:

$git merge issue54

Updating fbff5bc..4af4298

Fast forward

README | 1 +

lib/simplegit.rb | 6 +++++-

2 files changed, 6 insertions(+), 1 deletions(-)

Проблем не возникает; как можно заметить, это простое перемещение вперед. Теперь Джессика сливает изменения Джона (origin/master):

$git merge origin/master

Auto-merging lib/simplegit.rb

Merge made by recursive.

lib/simplegit.rb | 2 +-

1 files changed, 1 insertions(+), 1 deletions(-)

Слияние прошло чисто и теперь история коммитов у Джессики выглядит следующим образом:

Рисунок 10. История коммитов Джессики после слияния изменений Джона.

Теперь Джессика может отправить свою ветку master в origin/master, при условии что Джон больше не отправлял изменений:

$git push origin master

...

To jessica@githost:simplegit.git

72bbc59..8059c15 master -> master

Каждый разработчик сделал коммиты несколько раз и успешно слил изменения другого.

Рисунок 11. История коммитов Джессики после отправки на сервер.

Это один из самых простых рабочих процессов. В течение некоторого времени вы работаете в тематической ветке, а затем сливаете изменения в ветку master когда всё готово. Чтобы поделиться проделанной работой, вы сливаете её в вашу ветку master, затем получаете и сливаете изменения из ветки origin/master если таковые имеются, и наконец, отправляете все изменения в ветку master на сервере. В общем виде последовательность выглядит так:

Рисунок 12. Общий вид последовательности событий в рабочем процессе для нескольких разработчиков.

В этом сценарии мы рассмотрим роли участников в более крупной частной команде. Вы узнаете как работать в окружении, где мелкие группы совместно работают над улучшениями, а зетем их вклад интегрируется третьей стороной.

Предположим, что Джон и Джессика вместе работают над одной функцией, при этом Джессика и Джози работают над другой. В этом случае компания использует тип рабочего процесса с менеджером по интеграции, при котором работа отдельных групп интегрируется определенными инженерами, а ветка master основного репозитория может быть обновлена только этими инженерами. При таком сценарии вся работа ведется в отдельных ветках для каждой команды, а затем объединяется интегратором.

Давайте рассмотрим рабочий процесс Джессики, так как она работает над двумя функциями, параллельно сотрудничая с разными разработчиками. Предположим, что репозиторий уже склонирован и она решает работать сначала над функцией featureA. Джессика создаёт новую ветку для этой функции и некоторое время работает над ней:

#Jessica's Machine

$git checkout -b featureA

Switched to a new branch 'featureA'

$vim lib/simplegit.rb

$git commit -am 'add limit to log function'

[featureA 3300904] add limit to log function

1 files changed, 1 insertions(+), 1 deletions(-)

В данный момент ей необходимо поделиться проделанной работой с Джоном, поэтому Джессика отправляет ветку featureA на сервер. У Джессики нет доступа на запись в ветку master (он есть только у интеграторов), поэтому для совместной работы с Джоном она отправляет изменения в другую ветку:

$git push -u origin featureA

...

To jessica@githost:simplegit.git

* [new branch] featureA -> featureA

Джессика отправляет письмо Джону с уведомлением, что внесенные ей изменения уже доступны в ветке featureA. Пока Джессика ждёт ответа от Джона, она решает поработать на другой функцией featureB вместе с Джози. Для начала, Джесика создаёт новую тематическую ветку, базируясь на состоянии ветки master на сервере:

#Компьтер Джессики

$git fetch origin

$git checkout -b featureB origin/master

Switched to a new branch 'featureB'

После этого, Джессика делает несколько коммитов в ветке featureB:

$vim lib/simplegit.rb

$git commit -am 'made the ls-tree function recursive'

[featureB e5b0fdc] made the ls-tree function recursive

1 files changed, 1 insertions(+), 1 deletions(-)

$vim lib/simplegit.rb

$git commit -am 'add ls-files'

[featureB 8512791] add ls-files

1 files changed, 5 insertions(+), 0 deletions(-)

Репозиторий Джессики выглядит следующим образом:

Рисунок 13. Начальное состояние истории коммитов Джессики.

Джессика готова отправить свою работу, но получает письмо Джози, что начальная работа уже отправлена на сервер в ветку featureBee. Теперь Джессике нужно слить изменения перед отправкой на сервер. Эти изменения она получает командой git fetch:

$git fetch origin

...

From jessica@githost:simplegit

* [new branch] featureBee -> origin/featureBee

Теперь Джессика может слить полученные изменения со своими при помощи команды git merge:

$git merge origin/featureBee

Auto-merging lib/simplegit.rb

Merge made by recursive.

lib/simplegit.rb | 4 ++++

1 files changed, 4 insertions(+), 0 deletions(-)

Одна небольшая проблема - ей нужно отправить слитые изменения из локальной ветки featureB в ветку featureBee на сервере. Для этого в комаде git push Джессика указывает названия локальной и удаленной веток, разделенных двоеточием:

$git push -u origin featureB:featureBee

...

To jessica@githost:simplegit.git

fba9af8..cd685d1 featureB -> featureBee

Это называется спецификация ссылок . В главе Спецификации ссылок приведено более детальное описание спецификаций ссылок Git и различные способы их использования. Так же обратите внимание на флаг -u; это сокращение для --set-upstream, который настраивает ветки для упрощения отправки и получения изменений в дальнейшем.

После этого, Джессика получает письмо от Джона, в котором он сообщает, что отправил некоторые изменения в ветку featureA и просит их проверить. Джесика выполняет команду git fetch для получения этих изменений:

$git fetch origin

...

From jessica@githost:simplegit

3300904..aad881d featureA -> origin/featureA

Теперь, она может посмотреть что именно было изменено командой git log:

$git log featureA..origin/featureA

commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6

Author: John Smith

Date: Fri May 29 19:57:33 2009 -0700

changed log output to 30 from 25

Наконец, Джессика сливает изменения Джона в свою ветку featureA: