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

Краткое (50 символов или меньше) описание изменений

Текст более детального описания, если необходим. Старайтесь

не первышать длинну строки в 72 символа. В некоторых случаях

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

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

(если существует детальное описание); такие утилиты как 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.

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

$git push origin master

...

To john@githost:simplegit.git

fbff5bc..72bbc59 master -> master

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

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

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

Рисунок 8. Тематическая ветка Джессики.

Для синхронизации с Джоном Джессика получает изменения:

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

$git fetch origin

...

From jessica@githost:simplegit

fbff5bc..72bbc59 master -> origin/master

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

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

Джессика считает, что её тематическая ветка готова, но так же хочет знать какие изменения следует слить со своей работой перед отправкой на сервер. Для прояснения ситуации он выполняет команду git log:

$git log --no-merges issue54..origin/master

commit 738ee872852dfaa9d6634e0dea7a324040193016

Author: John Smith

Date: Fri May 29 16:01:27 2009 -0700

removed invalid default value

issue54..origin/master - это синтаксис фильтра, который указывает Git отображать только список коммитов, которые существуют в последней ветке (в данном случае origin/master), но отсутствуют в первой (в данном случае issue54). Более детально этот синтаксис рассматривается в главе Диапазоны коммитов.

В данном случае, в выводе команды мы видим только один коммит, сделанный Джоном и ещё не слитый Джессикой. Если она сольёт origin/master, то это будет единственный коммит, который изменит локальное состояние.