Мы используем следующий рабочий процесс git в моей компании при написании новой истории:
- Создание ветки темы от master (production / stable)
- Создайте столько коммитовпри желании реализовать функцию.
- сделать git merge --squash из этой ветки темы в ветку qa .
- QA людей обзор.
- Если все хорошо, код объединяется с веткой ua.Если команда принятия пользователей благословляет его, она объединяется с мастером и в конечном итоге развертывается.
- Если проверка не проходит, разработчик должен исправить.По сути, перезапуск процесса на шаге 2.
Примечание. Может быть до двух недель с момента объединения кода точки в ветвь qa и времени, в течение которого qa отклоняет / принимает его.
Если проблем нет, то код в конечном итоге превращается в master.Тем не менее, я ищу лучшие практики для случаев, когда QA обнаруживает проблему, и вы должны ее исправить.Я хотел бы, чтобы ветвь qa выглядела как можно более "нетронутой".
На мой взгляд, вот варианты:
- Вернуть исходный сжатыйсделайте коммит в ветке qa, перебазируйте ветку темы из qa, исправьте ваш код в ветке темы, снова объедините его с qa.Проблема: оставляет icky возвратный коммит вокруг.
- Удалите существующую ветку темы, воссоздайте ее из ветки qa, создайте простой коммит, чтобы исправить проблему, объединитесь обратно в qa.Проблема: распределяет изменения кода для функции по коммитам, отличным по времени и месту.
- Избавьтесь от сжатых слияний до qa, перебазируйте отдельные коммиты из qa в существующую ветку темы, исправьте с помощью другого коммита, объедините в qa.Проблема: множественные коммиты затрудняют отслеживание изменений при их перемещении в ветку ua, а затем в мастер.
Вопрос: Есть ли лучший способ переноса нескольких коммитов для одного объекта через несколько долгоживущихветви (master -> topic -> qa -> ua -> master), когда объединенный код может потребоваться исправить?