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

Я использую git для проекта PHP, я думаю, что это очень удобно. Есть одна вещь, которая будет здорово, если я заставлю его работать.

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

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

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

есть ли удобный способ сделать такую вещь? Как это обычно делается?

19
branch deployment git

11 ответов

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

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

Git очень принципиально отслеживает состояние проекта, а не файла. Это означает, что вы очень не можете попытаться "объединить файл". Это бессмысленная операция в git, и на самом деле любой SCM, который позволяет это в значительной степени, обречен быть полным куском sht ().

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

там.

что сказал, Вы могли бы:

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

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

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)
11

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

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

  2. Run git checkout -b deployment origin/master.

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

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

Это простое решение, и оно, безусловно, работает для меня, я не могу говорить с wether или нет, это делает его "shi*t", как предлагают другие, но это, безусловно, очень полезно для наших целей.

5

я делаю некоторые глупые трюки, как:

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

есть ли в этом смысл?

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

4

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

3

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

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

2

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

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

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

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

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

1

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

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

1

cherry-pick, похоже, работает для этого для этого (за счет загрязнения журналов немного).

проверка git-B тестирование внесение изменений и фиксация ГИТ выезд мастера git checkout-b развертывание внесение изменений и фиксация git checkout master

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

1

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

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

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

то же самое касается подсказки 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
1

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

0

это легко и чисто.

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

> git checkout deployment-1234

теперь вы можете внести конкретные изменения в развертывание. Как только это будет сделано, совершите это:

> git commit -as

вернуться обратно в ветку master.

> git checkout master

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

> git merge --no-ff deployment-1234

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

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

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

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

0