Хорошей практикой является, как только это станет возможным после того, как человек А отменит изменения на dev
, чтобы человек b перенес эти изменения в свою ветвь b
. Это так, что человек b
работает над последним кодом, и его возможное слияние с dev
легко.
Вариант 1, тянуть
- Передать все изменения в ветку
feature_branch
(состояние git показывает clean
)
git checkout dev
git pull
- извлекает изменения на компьютер b
и объединяет эти изменения в локальную ветвь b
. Эта операция обычно должна быть «ускоренной перемоткой вперед» (чтобы не возникало конфликтов слияния)
git checkout feature_branch
git merge develop
- объединяет изменения с b
локального dev
на feature_branch
.
git mergetool
- разрешение конфликтов
git commit ...
- совершить слияние
С этой опцией b
и локальные dev
и feature_branch
имеют последние изменения.
Вариант 2, выборка
- Передать все изменения в ветку
feature_branch
(состояние git показывает clean
)
git fetch origin dev
- загружает последние изменения в dev
, но не объединяет их с локальными dev
git merge origin/dev
- объединяет изменения из загруженной версии dev
в feature_branch
.
В этом сценарии локальные feature_branch
b
будут иметь самые последние изменения, начиная с dev
, так как они находятся в репо удаления , и их локальный dev
не будет иметь этих изменений. Это нормально, так как b не работает на dev
, он работает на feature_branch
.
Мне нравится вариант 2, поскольку мне не нужно оформлять заказ dev
, но оба варианта одинаково верны.