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

345
Stefan Wallin

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

0

2 ответа на вопрос

1
jbenet

Could one cherry-pick the bug into the feature branch and have git automatically resolve it away

This can work if your fix introduces no conflicts. git clone https://gist.github.com/jbenet/7959265, see the history and read the reflog I pasted there.

If you resolve conflict upon cherry-picking, you could remove the commit manually when rebasing on top of master, right before merging PR in (you can tag it/write a reminder in the commit message resolving the conflict).

But IMO, I'd rebase the feature branch on top of master when the hotfix was available. This is the same as pulling in any changes from master (inc other feature branches merged recently). Thus you're not worried about your branch being out of date. Depends on what your team likes to handle-- removing merged hotfixes, or rebasing often.

0
Aaron Jensen

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

Похожие вопросы