Я и моя команда используем функциональные ветви (с git). Мне интересно, какая стратегия лучше всего подходит для проверки кода перед слиянием с мастером.
- Я извлекаю новую ветку от мастера, давайте назовем ее fb_ # 1
- Я совершаю несколько раз, а затем хочу объединить его с мастером
- Перед слиянием кто-то должен сделать обзор кода
Теперь есть 2 возможности:
первый
- Я объединяю master с fb_ # 1 (а не fb_ # 1 с master), чтобы сделать его как можно более современным
- Товарищ по команде рассматривает изменения между главной головой и головой fb_ # 1
- Если fb_ # 1 в порядке, мы объединяем fb_ # 1 с мастером
- Плюсы: нет устаревшего кода в обзоре
- Минусы: если кто-то еще сливает что-то между "1" и "2" его изменения появляются в обзоре, хотя они принадлежат другому обзору.
второй
- Товарищ по команде просматривает изменения между точкой извлечения (git merge-base master fb_ # 1) и головой fb_ # 1
- Плюсы: мы видим, что именно изменилось во время работы над веткой функций
- Минусы: в обзоре может появиться устаревший код.
Какой путь вы считаете лучше и почему ? Может быть, есть другой более подходящий подход?
источник
git show HEAD
. Поскольку это будет коммит слияния fm , в нем будут перечислены оба родителя. Итак, у вас есть хеш мм . Кроме того, вы можете тривиально увидеть родителя вgitk
любом другом git-браузеретретий
Вы перебазируете ветку на master, чтобы обновлять ее и хранить изменения отдельно.
Это создает новую историю отрасли. Это будут новые ревизии с новыми идентификаторами, которые будут иметь такое же содержимое, но будут получены из последней версии мастера и не будут ссылаться на старые ревизии. Старые ревизии по-прежнему доступны в «reflog», если вам нужно сослаться на них, например, потому что вы обнаружили, что допустили ошибку при разрешении конфликта. Кроме того, они бесполезны. Git по умолчанию сокращает журнал после 3 месяцев и удаляет старые ревизии.
Вы используете интерактивное перебазирование (
git rebase -i
иgit commit --amend
), чтобы изменить порядок, отредактировать и очистить изменения, чтобы каждое из них сделало логически закрытое изменение.Это снова создает новую историю, на этот раз с дополнительным преимуществом, благодаря которому вы можете реструктурировать изменения, чтобы сделать их более осмысленными во время проверки.
Плюсы:
Обычно дополнительная работа означает, что вы сначала тщательно просматриваете код, и это также поймает много проблем.
Это то, что делают Linux и Git. И нет ничего необычного в том, что серии из 20-25 патчей представляются на рассмотрение и несколько раз переписываются в этих проектах.
На самом деле Linux делал это с самого начала в проекте, когда они выбирали тарболы и патчи. Когда много лет спустя Линус решил создать git, это было основной причиной реализации
rebase
команды и ее интерактивного варианта. Также из-за этого у git раздельное представление об авторе и коммиттере . Автор - это тот, кто первым создал ревизию, а автор, который последним коснулся ее. Поскольку и в Linux, и в Git патчи по-прежнему отправляются по электронной почте, они почти никогда не являются одним и тем же человеком.источник
merge --no-ff
--no-ff
имеет свои плюсы и минусы. Я лично нахожу это больше шума чем что-либо. YMMV.На самом деле существует третья возможность - и, скорее всего, множество других, поскольку GIT - это скорее реализация структуры SCM, чем реализация методологии SCM. Эта третья возможность основана на
rebase
.rebase
Субкоманда GIT принимает серию фиксации ( как правило , от вашей точки ветвления на кончик темы ветвиtopic
) и воспроизводить их в другом месте ( как правило , на кончике интеграции отрасли, напримерmaster
).rebase
Субкоманда производит новые коммиты, что дает возможность перегруппировки фиксаций в форме , которая легче обзор. Это дает новую серию коммитов, аналогичную той, что былаtopic
раньше, но появлялась с корнем в верхней части ветви интеграции. Эта новая ветвь все еще вызываетсяtopic
GIT, так что старая ссылка отбрасывается. Я неофициально помечаюtopic-0
исходное состояние вашей веткиtopic-1
и так далее по разному рефакторингу.Вот мое предложение для вашей
topic
ветки:(Необязательный шаг) Вы в интерактивном режиме перебазировать вашу тему ветвь
topic
на ее точку ветвления (см--fixup
опцииcommit
и-i
и--autosquash
опцию наrebase
), что дает возможность переписать свои коммиты таким образом , что легче обзор. Это приводит к ответвлениюtopic-1
.Вы перебазируете ветку своей темы в верхней части ветки интеграции, это похоже на слияние, но «не загрязняет» историю слиянием, которое является просто артефактом разработки программного обеспечения. Это приводит к ответвлению
topic-2
.Пошлите
topic-2
товарищу по команде, который рассматривает это против наконечникаmaster
.Если
topic-2
все в порядке, тогда объедините его с мастером.П р и м е ч а н и е - Ветви - где ветвь ссылается на дерево коммитов - все будут называться GIT одинаково, поэтому в конце процесса только ветвь
topic-2
имеет имя в GIT.Плюсы:
Минусы:
topic-0
, есть три ветви артефактыtopic-0
,topic-1
иtopic-2
которые созданы в фиксации дерева. (Хотя в любое время только один из них имеет имя в GIT.)В вашем 1-м сценарии «если кто-то слил что-то между« 1 ». и «2.» »означает промежуток времени между созданием точки ветвления и временем, когда вы решили объединиться. В этом сценарии «если кто-то слил что-то между« 1 ». и «2.» относится к промежутку времени между перебазированием и слиянием, которое обычно очень мало. Таким образом, в сценарии, который я предоставляю, вы можете «заблокировать»
master
ветку на время слияния, не нарушая существенно ваш рабочий процесс, в то время как в первом сценарии это нецелесообразно.Если вы делаете систематические обзоры кода, вероятно, хорошей идеей будет перестановка коммитов адекватным образом (необязательный шаг).
Управление артефактами промежуточной ветви представляет сложность, только если вы делитесь ими между репозиториями.
источник
topic-0
,topic-1
иtopic-2
ветви. Во время второй перезагрузки предыдущая версия не имеет значения. Так что все было бы естьtopic@{1}
,topic@{2}
,topic@{yesterday}
, иtopic@{3.days.ago}
т.д. , чтобы сохранить свою задницу в случае , если вы обнаружили , ввинчиваетесь разрешением конфликтов в перебазировании.topic
. Потому что ветка в git это просто имя.topic
в GIT, это всегда одна из ветвей (ветвь , как и в фиксации дерева, а не как в GIT ссылке) Я маркированtopic-0
,topic-1
,topic-2
.