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

Question

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

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

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

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

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

Answer 1

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

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

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

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

---

Там.

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

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

---

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

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)

Answer 2

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

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

2. Выполнить git checkout -b deployment origin/master.

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

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

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

Answer 3

Я делаю несколько глупых трюков, таких как:

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

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

У меня все в порядке.

Answer 4

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

Answer 5

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

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

Answer 6

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

git checkout -b тестирование внести изменения и совершить мастер проверки git checkout -b deploy внести изменения и совершить мастер проверки git

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

Answer 7

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

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

Answer 8

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

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

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

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

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

Answer 9

Я упоминал ранее файлы патчей. Я прекратил это и теперь поддерживаю ветки развертывания.

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

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

То же самое касается кончика 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

Answer 10

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

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

> 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 до мастера. Это нормально, если эти слияния выполняются вручную. Но если вам нужны автоматические слияния, лучше, если я смогу предотвратить этот систематический конфликт. Поэтому вместо этого я создал скрипт, который может применять и отменять изменения, связанные с развертыванием. Тогда сами изменения не обязательно должны быть в репозитории, вместо этого в репозитории появится этот сценарий.