Мы команда из пары разработчиков, у которых есть наша главная ветка и мы разрабатываем функции в ветках функций. Мы разветвляем релизные ветки главной версии, когда выпускаем. Все исправления ошибок производятся в главной версии, а затем тщательно отбираются в соответствующую релизную ветку.
Мы хотим иметь атомарные коммиты слияния для каждой новой функции, которые мы можем откатить и разделить, как описано в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 Можно ли выбрать ошибку и перенести ее в ветку feature, а затем заставить git автоматически устранить ее после окончательного перемещения, когда мы оставляем удаленную отслеживаемую ветку без присмотра непосредственно перед слиянием новой перемещенной версии ветки feature в master?
решение1
Можно ли выбрать ошибку и перенести ее в ветку функций, а git автоматически ее исправить?
Это может сработать, если ваше исправление не приводит к конфликтам. git clone https://gist.github.com/jbenet/7959265Посмотрите историю и прочитайте reflog, который я туда вставил.
Если вы разрешаете конфликт методом отбора, вы можете удалить коммит вручную при перемещении на вершину master, прямо перед слиянием PR (вы можете пометить его/написать напоминание в сообщении коммита, разрешающем конфликт).
Но, на мой взгляд, я бы перебазировал ветку feature на master, когда исправление стало доступно. Это то же самое, что и втягивание любых изменений из master (включая другие ветки feature, недавно объединенные). Таким образом, вам не придется беспокоиться о том, что ваша ветка устареет. Зависит от того, что предпочитает делать ваша команда — удалять объединенные исправления или часто перебазировать.
решение2
Если вам действительно нужно исправление ошибки в вашей ветви функций, объедините ветку исправления ошибки. Разговор о bisect/rollback/что-то еще был FUD — bisect, по моему опыту, отлично справляется со сложными историями слияния. Модель, предложенная в этом посте, создает искусственные проблемы (например, ту, о которой вы задаете вопросы), и буквально ее единственным преимуществом является более чистыйсмотрящийистория. Мы использовали эту модель пару лет, прежде чем поняли преимущество отсутствия перебазирования. Я перебазирую, когда мне нужно очистить собственную историю (сжать коммиты, изменить сообщения коммитов и т. д.), но только это не влияет ни на кого ниже по течению (например, если я работаю над веткой в одиночку).