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

Question

Мы команда из нескольких разработчиков, которые имеют нашу основную ветку и разрабатывают функции в функциональных ветках. Мы выпускаем ветки 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 автоматически разрешит ее после окончательной перебазировки, когда мы потеряли ветку удаленного отслеживания непосредственно перед тем, как объединить новую перебазированную версию ветви функций с master?

Answer 1

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

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

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

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

Answer 2

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