Как реализовать ветку развертывания в Git

Обновление от февраля 2021 года: сам Git по-прежнему не подходит, но среда действий GitHub может помочь.

2009: Я не уверен, что Git предназначен для использования таким образом.

Сначала быстрый совет Линуса, всегда красочный и информативный. ;)

Git очень фундаментально отслеживает состояние проекта, а не состояние файла. Это означает, что вы НЕ МОЖЕТЕ пытаться объединить файл. Это бессмысленная операция в git, и на самом деле любая SCM, которая позволяет это, обречена на то, чтобы стать сплошным дерьмом (*).

(*) И я говорю это не только потому, что git этого не делает. Это гораздо более фундаментально, чем это. Как только вы начнете выполнять ветвление и слияние для каждого файла, вы в основном облажаетесь и больше никогда не сможете работать над проектом в целом - у вас больше нет четко определенной истории, которая на самом деле является история всего проекта.

Там.

Тем не менее, вы могли:

• управлять этими файлами config / doc в отдельных подпроектах git (примечание: здесь обсуждалось использование подмодулей)
• или запишите частичное слияние (используя нашу стратегию для файлов, которые мы не хотим объединять), а затем - изменить его.

Другие решения в этом потоке включают работу над серверной веткой на вашем сервере развертывания.

Development        Deployment

#origin/master:
x--x               $ git clone

                   # master
                   x--x

                   $ git checkout -b deployment origin/master

                   x--x
                       \ 
                        -- #deployment

                   $ .... #makes changes for config files
                          #or other specific deployment files

                   x--x
                       \
                        --d1--d2 # no need to push that branch ever.

#new developments
x--x--x--x

                   $ git pull --rebase #pull origin/master and 
                                       #replay current branch on top of it
                   x--x--x--x
                             \
                              --d1'--d2' #SHA1 rewritten in deployment branch
                                         #not important since this branch 
                                         #is not pushed (published)
         
              

Я делаю глупые трюки вроде:

• Пусть приложение прочитает файл config
• Добавьте config.development и config.production, но не config в репозиторий
• Пусть ваш сценарий развертывания не только клонирует репозиторий, но и cp config.production config

Имеет ли это хоть какой-то смысл?

У меня работает нормально.

У меня это работает, и я вношу лишь незначительные изменения конфигурации для развертывания (3 строки в файлах конфигурации).

1. Клонируйте свой репозиторий с GitHub или где бы то ни было. Туда, где вы хотите развернуться.

2. Запустите git checkout -b deployment origin/master.

3. Внесите свои изменения (нажмите, если хотите).

4. Всякий раз, когда у вашего мастера (или любой другой ветки, из которой вы выполняли развертывание) есть изменения, которые вы хотите развернуть, просто git pull --rebase.

Это простое решение, и оно, безусловно, работает для меня, я не могу говорить с ним или нет, это делает его «дерьмовым», как предлагают другие, но оно, безусловно, очень полезно для наших целей.

Быстрый ответ: никогда не объединяйте ветви. На самом деле вам вообще не нужно их объединять, просто объедините этапы разработки (также известные как «мастер») в развертывание, чтобы объединить исправления и общие изменения.

Если вы хотите, чтобы ваша история была красивой, вы можете хранить файлы развертывания в некоторых коммитах поверх вашей чистой ветки. Затем, когда пришло время развернуть новую версию, вы проверяете ветку развертывания и git rebase master, чтобы поместить эти коммиты поверх исходной ветки.

Таким образом, вы также можете легко вносить изменения в файлы конфигурации и изменять верхний коммит с помощью 'git commit --amend'.

У меня была похожая проблема, и я создал крошечный проект под названием config-magic, чтобы с этим справиться.

Config-magic позволяет создавать файлы конфигурации шаблонов, а затем профили данных для каждого из этапов разработки / подготовки / производства. Затем вы запускаете «cfg dev» для создания файлов конфигурации «dev», «cfg staging» для создания промежуточной конфигурации и т. Д.

Затем я подключил это к сценариям, так что при развертывании в промежуточном режиме я локально запускаю «cfg staging», а затем scp по всем файлам конфигурации после обновления кодовой базы из git.

"Фактические" файлы конфигурации игнорируются git. До сих пор это работало для меня очень хорошо.

https://github.com/apinstein/config-magic/tree

Я думал обо всех этих решениях для моей ситуации, но ни одно из них, похоже, не применимо. Я редактирую как на своем живом сервере, так и на сервере разработки. Rebase работает хорошо, если вам не нужно повторно публиковать эту ветку, но я вношу изменения в свою ветку развертывания и публикую их обратно в основной репозиторий. Подмодуль работает только в том случае, если ваши файлы находятся в отдельном подкаталоге, мои файлы конфигурации находятся в нескольких местах. Наш метод слияния не будет работать так хорошо, потому что мне нужно сначала вытащить эту ветку, а затем большую ветку. Возможно, это сработало бы, если бы все еще было их объединение, и я мог бы при необходимости вытащить правильную ветку конфигурации. На данный момент работает .gitignore, и я просто вручную загружаю файлы.

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

Cherry-pick, кажется, работает для этого (за счет небольшого загрязнения журналов).

git checkout -b testing внести изменения и зафиксировать git checkout master git checkout -b deploy внести изменения и зафиксировать git checkout master

сделайте все в разделе master и git cherry-pick testing или git cherry-pick deploy, чтобы применить различия, необходимые для переключения с текущей системы на версию для тестирования или развертывания.

Я упоминал ранее файлы патчей. Я отказался от этого и вместо этого сохранил ветки развертывания.

то есть я отключаю master с новой веткой с именем master-deployed и вношу изменения в этой ветке, которые мне нужны только в тестовой версии на сервере сборки (т.е. добавляю предупреждение о том, что это не живая версия, и другой сервер db в web.config).

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

То же самое и с tip of qa, у которого есть ветка qa-deployed.

Я использую флаг --onto, чтобы быть уверенным, что если вся ветка будет перезаписана, то патч не заберет с собой все старые коммиты.

Итак, на сервере сборки сборка qa выглядит примерно так:

git reset --hard
git clean -xfd
git checkout -f qa-deployed
git rebase --onto qa HEAD^ qa-deployed
build-script

в настоящее время у меня есть несколько файлов исправлений, и сервер сборки применяет эти исправления для соответствующих версий. хотя я в данный момент сомневаюсь в этом

Это просто и чисто.

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

> git checkout deployment-1234

Теперь вы можете внести изменения, специфичные для развертывания. Как только это будет сделано, зафиксируйте его:

> git commit -as

Вернитесь в свою главную ветку.

> git checkout master

Сразу же слейте ветку развертывания. Это изменит вашу основную ветку с этими изменениями, специфичными для развертывания, но не волнуйтесь, мы отменим ее.

> git merge --no-ff deployment-1234

Чтобы отменить изменения, просто проверьте файлы перед слиянием и зафиксируйте их с исправлением.

> git checkout HEAD^ .
> git commit --amend

Вот и все. Теперь git считает, что файл изменяется при первой фиксации развертывания-1234, как это уже было рассмотрено мастером и признано неподходящим. Таким образом, он никогда не добавит эти изменения в основную ветку, даже если вы попытаетесь объединить всю ветку развертывания-1234 с главной. (Попробуй!)

Я также использую другой метод в проекте, который требует лучшего контроля. Плохо то, что вы можете создать конфликт во время будущего слияния развертывания-1234 с master. Это нормально, если эти слияния выполняются вручную. Но если вам нужно автоматическое слияние, лучше, если я смогу предотвратить этот систематический конфликт. Поэтому вместо этого я создал сценарий, который может применять и отменять изменения, относящиеся к развертыванию. Тогда сами изменения не обязательно должны быть в репозитории, вместо этого то, что появляется в репозитории, будет этим скриптом.