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

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

Мы хотим иметь атомарные коммиты слияния для каждой новой функции, которую мы можем откатить и разделить пополам, как описано в https://gist.github.com/jbenet/ee6c9ac48068889b0912. Это должно дать нам историю, которая выглядит следующим образом.

* aa55ffe -  (HEAD, master) D
* 88425f8 -  C
*   7bc519f -  Merge branch 'feature-X' into master
|\
| * 9364e61 -  feature-X: 2
| * bc76674 -  feature-X: 1
|/
* 88425f8 -  B
*   7bc519f -  Merge branch 'feature-Y' into master
|\
| * 0e0deea -  feature-Y: 4
| * 11079b5 -  feature-Y: 3
| * 9364e61 -  feature-Y: 2
| * bc76674 -  feature-Y: 1
|/
* c765ae3 -  A

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

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

Fx Может ли кто-нибудь выбрать ошибку в ветке функций и заставить git автоматически устранить ее после окончательной перебазировки, когда мы потеряли ветку удаленного отслеживания непосредственно перед тем, как объединить новую перебазированную версию ветви функций с мастер?

2 ответа

Можно ли черри выбрать ошибку в ветке функций, и git автоматически устранит ее

Это может работать, если в вашем исправлении нет конфликтов. git clone https://gist.github.com/jbenet/7959265, посмотрите историю и прочитайте рефлог, который я там вставил.

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

Но IMO, я бы перебазировал ветку функций поверх мастер-версии, когда исправление было доступно. Это то же самое, что вытягивать любые изменения из мастера (в том числе другие ветви функций, объединенные недавно). Таким образом, вы не беспокоитесь о том, что ваша ветка устарела. Зависит от того, что ваша команда любит обрабатывать - удаление слитых исправлений или частая перебазировка.

Если вам действительно нужно исправление ошибки в вашей ветви функций, объедините ветку исправления ошибок. Разговор о bisect/rollback/ что бы ни было FUD- bisect, по моему опыту, прекрасно справляется со сложной историей слияния. Модель, предложенная в этом посте, создает искусственные проблемы (например, ту, о которой вы задаете вопросы), и буквально ее единственным преимуществом является более чистая история. Мы использовали эту модель за пару лет до того, как поняли, что не стоит перебазировать. Я перезагружаюсь, когда мне нужно очистить свою собственную историю (коммиты сквоша, изменения сообщений коммита и т. Д.), Но только это не влияет на кого-либо еще внизу (например, если я работаю над сольной веткой).

Другие вопросы по тегам