Маленький закрытый проект
Наиболее простой тип организации, с которой вы легко можете столкнуться это частный проект с одним или двумя другими разработчиками. Под термином частный я подразумеваю закрытый код, недоступный для чтения остальному миру. Вы и все остальные разработчики имеете право записи в репозиторий.
В этой среде вы можете придерживаться рабочего процесса, похожего на тот, который вы бы использовали в Subversion или другой централизованной системе. Вы по-прежнему получите такие преимущества, как локальные коммиты (коммиты в offline) и возможность гораздо более простого ветвления и слияния, но сам рабочий процесс может оставаться очень похожим. Главное отличие заключается в том, что слияние происходит на стороне клиента, а не на стороне сервера во время фиксации изменений.
Давайте посмотрим, как выглядел бы процесс, когда два разработчика начинают работать вместе с общим репозиторием.
Первый разработчик, Андрей, клонирует репозиторий (
Клонировать
репозиторий Git), делает изменения и фиксирует их в своём локальном
репозитории (). В результате создаётся локальный коммит eb9bcb5.
Второй разработчик, Василий, выполняет то же самое: клонирует репозиторий, делает изменения и фиксирует их коммитом 76bc0e8:
Теперь Василий отправляет свою работу в удалённый репозиторий ().
Вскоре после этого Андрей также пытается отправить свои изменения ():
Андрей не может выполнить отправку изменений, так как за это время Василий уже отправил свои.
Это очень важно понять, особенно если вы привыкли к Subversion, так как мы видим, что эти два разработчика не редактировали один и тот же файл. Хотя в том случае, когда редактировались разные файлы Subversion и выполняет автоматическое слияние на сервере, при использовании Git'а вы должны сначала слить коммиты локально. Другими словами Андрей должен сначала получить изменения Василия, слить их в свой локальный репозиторий, а затем уже отправить результат в удалённый репозиторий.
В качестве первого шага Андрей выполняет команду .
Слияние прошло без проблем, история коммитов Андрея теперь выглядит как на рисунке:
Теперь Андрей может протестировать свой код, дабы удостовериться, что он по-прежнему работает нормально, а затем отправить свою работу, уже объединённую с работой Василия, в удалённый репозиторий ().
В результате история коммитов Андрея выглядит так, как показано на рисунке:
Тем временем, Василий работал над тематической веткой. Он создал тематическую ветку () с названием Проект54 и сделал три коммита в этой ветке (). Он ещё не получал изменения Андрея, так что его история коммитов выглядит, как показано на рисунке:
Василий хочет синхронизировать свою работу с Андреем, так что он извлекает изменения с сервера ():
Эта команда извлекает наработки Андрея, которые он успел выложить. История коммитов Василия теперь выглядит как на рисунке:
Теперь Василий может слить свою тематическую ветку в ветку master, слить работу Андрея ( origin/master) в свою ветку master и затем отправить изменения на сервер. Сначала он переключается на свою основную ветку (), чтобы объединить всю эту работу:
Он может слить сначала ветку origin/master, а может и Проект54 — обе они находятся выше в истории коммитов, так что не важно, какой порядок слияния он выберет. Конечное состояние репозитория должно получиться идентичным независимо от того, какой порядок слияния он выберет, только история коммитов будет немного разная.
Он решает слить ветку Проект54 первой ():
Никаких проблем не возникло. Как видите, это была обычная перемотка вперёд.
Теперь Василий сливает работу Андрея ( origin/master) ().
Слияние проходит нормально, и теперь история коммитов Василия выглядит так, как показано на рисунке:
Теперь указатель origin/master доступен из ветки master Василия, так что он может спокойно выполнить (полагая, что Андрей не отправлял свои изменения за это время):
В результате история коммитов Василия выглядит так, как показано на следующем рисунке. Каждый разработчик несколько раз выполнял коммиты и успешно сливал свою работу с работой другого:
Это один из простейших рабочих процессов. Вы работаете некоторое время, преимущественно в тематической ветке. Когда вы готовы поделиться этой работой с другими, вы сливаете её в ветку master, извлекаете изменения с сервера и сливаете origin/master (если за это время произошли изменения), и, наконец, отправляете свои изменения в ветку master на сервер. Общая последовательность действий выглядит так, как показано на рисунке:
