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

Джессика решает немного подправить, делает коммит и снова отправляет изменения на сервер:

$git commit -am 'small tweak'

[featureA 774b3ed] small tweak

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

$git push

...

To jessica@githost:simplegit.git

3300904..774b3ed featureA -> featureA

История коммитов у Джессики сейчас выглядит так:

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

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

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

Многие переходят на Git именно из-за возможности параллельной работы нескольких команд в различных направлениях с последующим слиянием проделанной работы. Возможность совместной работы небольших подгрупп команды в удаленных ветках без необходимости вовлекать или мешать всей команде - огромное преимущество Git. Последовательность действий в описанном рабочем процессе выглядит следующим образом:

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

Участие в публичном проекте сильно отличается. Так как у вас нет доступа обновлять ветки пероекта напрямую, то передавать проделанную работу следует другим способом. В первом примере рассматривается участие в публичном проекте по средствам форка на Git платформах, где возможно его простое создание. Много Git хостинг сайтов поддерживают такую функцию (включая GitHub, BitBucket, Google Code, repo.or.cz и другие), как и большинство тех, кто поддерживате проекты, ожидают такой стиль участия.

Следующий раздел посвящен проектам, которые предпочитают принимать исправления в виде патчей по электронной почте. Для начала, вам следует склонировать основной репозиторий, создать тематическую ветку для одного или нескольких патчей и работать в ней. Обычно, последовательность действий выглядит так:

$git clone (url)

$cd project

$git checkout -b featureA

#(work)

$git commit

#(work)

$git commit

Если вы захотите использовать rebase -i для схлопывания коммитов в единый или для перестраивания коммитов, чтобы облегчить модерирование ваших патчей – воспользуйтесь разделом Исправление истории для получения детальной информации об интерактивном перебазировании.

Когда работа в тематической ветке завершена и вы готовы передать изменения исходному проекту, перейдите на страницу исходного проекта и нажмите кнопку “Fork”, тем самым создавая доступный для записи форк проекта. Затем нужно добавить URL на созданный проект как второй удаленный репозиторий, в нашем случае с именем myfork:

$git remote add myfork (url)

После этого следует отправить проделанную работу в него. Проще отправить вашу тематическую ветку, в которой велась работа, чем сливать изменения в вашу ветку master и отправлять её. Если ваши изменения будут отклонены или какой-то из коммитов будет применен выборочно, то вы не сможете вернуть состояние вашей ветки master. Если менеджер проекта сольёт, перебазирует или выборочно применит ваши изменения, то вы сможете их получить из оригинального репозитория.

$git push -u myfork featureA

Когда ваши изменения отправлены в ваш форк, следует уведомить об этом сопровождающего проекта. Обычно, это называется запросом слияния, который вы можете создать используя веб сайт - GitHub использует собственный механизм запросов слияния, который будет рассмотрен в разделе GitHub - или используя команду git request-pull отправить её вывод по почте.

Команда request-pull принимает в качестве аргументов название базовой ветки, в которую следует влить изменения из вашей тематической ветки, и ссылку на Git репозиторий, из которого следут получать изменения, а результатом будет список всех изменений, которые вы предлагаете внести. Например, если Джессика хочет отправить Джону запрос слияния и она отправила два коммита в тематическую ветку, то ей следует выполнить команду: