Какой рабочий процесс Git подходит для нашего случая?

64
9

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

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

Выполняйте свою работу на местном уровне. Обновите тестовый сервер и сообщите клиенту. Если клиент одобрил изменения, обновите производство.

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

Сначала я думал, что иметь 3 ветки master для производства стабильных релизов, test на тестовом сервере (должны быть объединены в от dev) и dev где код. Я не уверен, хорошо ли это подходит.

спросил(а) 2021-01-25T13:08:07+03:00 4 месяца, 3 недели назад
1
Решение
88

enter image description here

(каждая фиксация представлена кругом). (пунктирные линии: требуется дополнительное слияние)

пролог

    Эта вещь написана быстро и, безусловно, имеет ошибки, но должна дать хороший обзор подхода.

обзор

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

Вам понадобятся 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 branch is 2 commits behind master ~HEAD)
git rebase -i master << -i to be interactive, so she can pull out some of the local changes she 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 production и git rebase pre-release

Вы можете использовать производственную отрасль. Если у вас есть пользовательские изменения, характерные для вашего производственного сервера, лучше иметь отдельную ветвь для него (production_local_changes) с несколькими дополнительными изменениями и всегда переустанавливать его на производственную ветвь.

Критические ошибки:

Предположим, что кто-то найдет критическую ошибку на вашем рабочем сервере, тогда Боб создаст ветку из производственной ветки, исправит ошибку, зафиксирует ее, а затем объединит свою ветку с производственным сервером, а затем вытащит и переустановит prodction_local_changes. Но тогда изменение не будет присутствовать в мастер, поэтому ему также нужно будет объединиться с мастером, а также с предварительным выпуском, если он активен и rebase test_server_local_changes.

Заметки

    На мой взгляд, в git (в отличие от SVN, поскольку я помню эти уродливые дни его использования), пользователи должны разветвляться, когда это необходимо, и совершать так часто, как это имеет смысл.

    Каждый пользователь может и должен иметь свою локальную ветку, имеющую все свои собственные конфигурации, и объединить ее или сделать вишневый выбор, когда они отходят от любого из трех основных ветвей. Они могут всегда переустанавливать -i и удалять свои локальные изменения, прежде чем они вернутся к любому из этих трех ветвей. То же самое относится к производственным и предварительным выпускам веток, там должна быть ветка для всех конфигураций, которые являются локальными для каждого.

    Мне нравится gitolite, и я считаю, что это хороший инструмент для использования на git для управления разрешениями, иметь своеобразное центральное репо и упростить использование git.

ответил(а) 2021-01-25T13:08:07+03:00 4 месяца, 3 недели назад
88

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

Вначале наша экосистема включала ветки для каждого сервера, производство, стадию и развитие - синхронизация изменений между ветвями иногда создавала проблемы слияния, которые были очень расстраивающими. В настоящее время у нас есть все серверы с производственной отделкой, и мы сохранили себе немало головных болей. Мы проверяем все, что перед тем как pull ИНГ на сервере - если необходимо протестировать более радикальные изменения кодирования вы также можете переключать ветки. Там много гибкости.

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

ответил(а) 2021-01-25T13:08:07+03:00 4 месяца, 3 недели назад
63

Похоже, вам не нужны 3 ветки, но больше похоже на по крайней мере 2 хранилища. Каждый разработчик имеет собственный, по крайней мере, локальный репозиторий, и у всех есть доступ для вытягивания, и это "ветвь dev". Затем есть тестеры, которые должны знать, кто обязуется тестировать, и команда тестирования несет ответственность за сохранение официального хранилища с рабочими коммитами. (Общее количество репозиториев = количество участников + 2)

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

ответил(а) 2021-01-25T13:08:07+03:00 4 месяца, 3 недели назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема