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

первая строка подразумевается как тема письма, а всё остальное -

тело письма. Пустая строка, разделяющая сообщение, критически важна

(если существует детальное описание); такие утилиты как rebase

могут запутаться, если вы запустите сразу две.

Последующие параграфы должны отделяться пустыми строками.

- Списки тоже подходят

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

предваряются одиночным пробелом, а разделяются пустой строкой, но

соглашения могут отличаться

Вам и вашим разработчикам будет гораздо проще, если все сообщения ваших коммитов будут так выглядеть. В проекте Git все сообщения хорошо отформатированы - выполните команду git log --no-merges, чтобы увидеть как выглядит хорошо отформатированная история коммитов.

В последующих примерах, как и практически везде в этой книге, для краткости не используется расширенное форматирование; вместо этого используется опция -m команды git commit. Делайте как мы говорим, а не так как делаем мы.

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

В такой среде вы можете использовать рабочий процесс, при котором выполняемые действия анологичны использованию Subversion или другой централизованной системе. Вы всё ещё можете использовать преимущества создания коммитов оффлайн, значительно более простое ветвление и слияние, но процесс будет очень похожим; основное отличие в том, что слияние происходит на стороне клиента, а не на сервере во время коммита. Давайте посмотрим что происходит, когда два разработчика начинают работать вместе и используют общий репозиторий. Первый разработчик Джон клонирует репозиторий, вносит изменения и делает коммит локально. (В последующих примерах сообщения протокола заменены на ... с целью их немного сократить.)

#Компьютер Джона

$git clone john@githost:simplegit.git

Initialized empty Git repository in /home/john/simplegit/.git/

...

$cd simplegit/

$vim lib/simplegit.rb

$git commit -am 'removed invalid default value'

[master 738ee87] removed invalid default value

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

Второй разработчик Джессика делает тоже самое - клонирует репозиторий и делает коммит:

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

$git clone jessica@githost:simplegit.git

Initialized empty Git repository in /home/jessica/simplegit/.git/

...

$cd simplegit/

$vim TODO

$git commit -am 'add reset task'

[master fbff5bc] add reset task

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

Затем Джессика отправляет изменения на сервер:

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

$git push origin master

...

To jessica@githost:simplegit.git

1edee6b..fbff5bc master -> master

Джон так же пытается отправить свои изменения:

#Компьютер Джона

$git push origin master

To john@githost:simplegit.git

! [rejected] master -> master (non-fast forward)

error: failed to push some refs to 'john@githost:simplegit.git'

Джону запрещено отправлять изменения, так как Джессика уже отправила свои. Это особенно важно для понимания, особенно если вы привыкли к Subversion, потому что, как вы могли заметить, разработчики не редактировали один и тот же файл. Если Subversion автоматически делает слияние на сервере при условии, что редактировались разные файлы, то в Git вы должны слить изменения локально. Джон должен получить изменения Джессики и слить их локально, прежде чем сможет отправить свои:

$git fetch origin

...

From john@githost:simplegit

+ 049d078...fbff5bc master -> origin/master

В этот момент локальный репозиторий Джона выглядит примерно так:

Рисунок 5. Расходящаяся история Джона.

У Джона есть ссылка на отправленные Джессикой изменения, но он должен применить их к своей работе прежде, чем сможет отправить свои:

$git merge origin/master

Merge made by recursive.

TODO | 1 +

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

Процесс слияния проходит гладко - история коммитов у Джона выглядит примерно так:

Рисунок 6. Репозиторий Джона после слияния с origin/master.

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