(каждый коммит представлен кружком).
(пунктирные линии: требуются дополнительные слияния)
Пролог
- Эта вещь написана быстро и определенно содержит ошибки, но должна дать хороший обзор подхода.
Обзор
У нас есть сценарий использования, очень похожий на ваш, и это наиболее оптимизированное решение, которое мы нашли до сих пор.
Вам понадобятся 3 разных филиала:
- master (это ваша основная ветвь, весь - полезный - код, который пишут разработчики, наконец-то приходит сюда)
- Производство
pre-release -> это временная ветка. это время между тем, когда вы демонстрируете что-то клиенту, и временем, когда эта штука поступает на рабочий сервер.
- обратите внимание, что производство и предварительная версия в конечном итоге являются более старой версией главной ветви, то есть главной, исключая некоторые из ее последних изменений. Поэтому любые изменения, которые непосредственно вносятся в предварительную версию (на основе запроса клиента), должны быть объединены с master. также любые изменения в производственной ветке (исправления критических ошибок) должны быть объединены с основной веткой, а также с предварительной версией, если она активна. Это самое важное, что нужно учесть, иначе вы окажетесь в беспорядке, очень похожем на наличие более чем одной кодовой базы в одном репозитории git.
Для рутинных задач:
Разработчик Foo будет:
git pull
git checkout -b new_feature
, а затем записывает свой код и часто фиксирует ветку new_feature.
Как только она закончит:
git pull << to get the latest changes on master (in the picture you see Foo's branch is 2 commits behind master's ~HEAD)
git rebase -i master << -i to be interactive, so she can pull out some of the local changes she's made e.g. local changes config files or customized loggers for her own benefit, etc.
git merge --no-ff master << merge the changes with master
git push << push to the repository
Тестовый сервер:
Как только вы будете достаточно хороши для тестирования / демонстрации клиенту, вы можете создать временную ветку:
git pull
git checkout master
git checkout -b pre-release
Возможно, вам понадобится несколько пользовательских конфигов для вашей тестовой машины, чтобы вы могли иметь ветку (test_server_local_changes) и предоставлять ее пользователю. если у вас есть новая ветка перед выпуском, выполните: git pull и git rebase -i pre-release
На этом этапе, если клиент запрашивает изменения, разработчик должен отойти от предварительной версии и, после внесения изменений, объединить свою ветку как с основной, так и с предварительной версией.
Производственный сервер:
Как только ваш клиент утвердит изменения:
Производство git pull и git checkout и предварительный релиз git rebase
Возможно, вы захотите обслуживать производственный филиал. Или, если у вас есть пользовательские изменения, специфичные для вашего производственного сервера, лучше иметь для него отдельную ветку (production_local_changes) с парой дополнительных изменений и всегда перебазировать их в производственной ветке.
Исправления критических ошибок:
Предположим, кто-то найдет критическую ошибку на вашем производственном сервере, затем Боб создаст ветку из производственной ветви, исправит ошибку, зафиксирует ее и затем объединит свою ветку с производственным сервером, а затем извлечет и перебазирует prodction_local_changes. Но тогда, изменение не будет присутствовать в мастере, поэтому ему также нужно будет объединиться с мастером, а также с предварительной версией, если она активна, и перебазировать test_server_local_changes.
Примечания
По моему мнению, в git (в отличие от SVN, как я помню в те уродливые дни его использования) пользователи должны переходить по веткам всякий раз, когда это необходимо, и фиксировать их так часто, как это имеет смысл.
Каждый пользователь может и должен иметь свою локальную ветвь, имеющую все его собственные конфигурации, и объединять ее или делать выборку первым делом, когда они разветвляются из любой из 3 основных ветвей. Они всегда могут перебазировать -i и удалить свои локальные изменения, прежде чем вернуться к любой из этих 3 веток. То же самое относится и к производственной и предварительной версии ветвей, от них должна быть ветвь для всех локальных конфигураций.
Мне нравится gitolite, и я думаю, что это хороший инструмент, который можно использовать поверх git для управления разрешениями, иметь своего рода центральное хранилище и упрощать использование git.