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

$git request-pull origin/master myfork

The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:

John Smith (1):

added a new function

are available in the git repository at:

git://githost/simplegit.git featureA

Jessica Smith (2):

add limit to log function

change log output to 30 from 25

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

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

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

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

$git checkout -b featureB origin/master

#(work)

$git commit

$git push myfork featureB

#(email maintainer)

$git fetch origin

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

Рисунок 17. История коммитов в начале работы над featureB.

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

$git checkout featureA

$git rebase origin/master

$git push -f myfork featureA

Эти действия перепишут историю ваших коммитов, которая станет похожа на История коммитов после работы над featureA..

Рисунок 18. История коммитов после работы над featureA.

Так как вы перебазировали ветку, то должны указать флаг -f во время отправки на сервер, чтобы переписать историю ветки featureA коммитами, не являющимися её потомками. Альтернативным решением может быть отправка этих исправлений в ветку с другим названием (например, featureAv2).

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

$git checkout -b featureBv2 origin/master

$git merge --no-commit --squash featureB

#(change implementation)

$git commit

$git push myfork featureBv2

Опция --squash берет все изменения из указанной ветки, объединяет их и создаёт новый коммит в текущей ветке без создания коммита слияния. Опция --no-commit указывает Git не создавать новый коммит автоматически. Это возволит взять изменения из другой ветки, внести дополнительные изменения и только потом создать новый коммит.

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

Рисунок 19. История коммитов после работы над featureBv2.

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

Рабочий процесс схожий - вы создаёте тематическую ветку для каждого набора патчей, над которыми собираетесь работать. Основное отличие - это способ их передачи проекту. Вместо того, чтобы создать форк и отправить в него свои изменения, вы генерируете e-mail версию для каждого набора коммитов и отправляете её в почтовую рассылку разработчиков: