Слияние ветки разработки с мастером - это не то, что я предполагал

Мы используем упрощенную версию Gitflow, где большая часть нашей работы идет непосредственно на разработку, и только во время выпуска мы сливаем обратно в мастер.

Мы только что сделали наш первый релиз, и поэтому это был мой первый раз, когда я объединил разработку обратно с мастером, так как я сначала создал основную ветку в начале и разветвил ее.

То, что я предполагал, было одним коммитом, объединенным с веткой master, таким образом, что если я позже извлеку master в чистую папку, я увижу только исходный коммит и коммит нового выпуска. Вместо этого я вижу всю историю коммитов ветки разработки в моей истории основной ветки.

Я понимаю, почему это так. В конце концов, это всего лишь 2 объединенные ветки, и быстрое слияние просто заархивирует мастер до кончика моей ветки разработки. Но это не то, что я себе представлял. Мне кажется странным проверять основную ветку и иметь возможность видеть всю историю всей работы, которая привела к ней из другой ветки.

В этом случае я задумываюсь над тем, почему мы поддерживаем как ветки разработки, так и ветки master, если мы все равно собираемся объединить их вместе, видеть одну и ту же историю и использовать теги для обозначения выпущенных коммитов (мы небольшая компания) ?

Так поступает большинство людей? Это правильно (я знаю, что это загруженный вопрос)? Или люди обращаются с мастером иначе, чем со всеми другими ветками, и, возможно, делают сквош-слияние или слияние без ff, чтобы создать более чистую историю мастер-веток?


git merge branch master
person Dave Ludwig    schedule 08.09.2020    source источник
comment
git поток требует слияний без быстрой перемотки вперед. Чтобы просмотреть историю только от первого родителя, добавьте --first-parent к запросам истории.   -  person jthill    schedule 08.09.2020

Ответы (1)


arrow_upward
2
arrow_downward

Если вы используете рабочий процесс, вдохновленный gitflow, то вы, вероятно, захотите использовать параметр --no-ff при слиянии.

git checkout master
git merge --no-ff dev

Это вызывает фиксацию слияния, даже если в противном случае была бы возможна быстрая перемотка вперед, поэтому вы получаете

--- O ----------- M <--(master)
     \           /
      x -- x -- x <--(dev)

Несмотря на это, по умолчанию большинство команд git по-прежнему будут отображать подробную историю (включая коммиты dev), но вы можете переопределить это, используя параметр --first-parent.

git log --first-parent master

Тем не менее, есть и другие причины, по которым вы можете разделить ветки master и dev, даже если вы в конечном итоге собираетесь перемотать dev в master. Одна из причин заключается в том, чтобы убедиться, что master всегда является самым последним выпущенным состоянием. Вы можете сделать это с помощью тегов версии, но, возможно, вам нужно одно имя, которое всегда означает последний выпуск, и/или, может быть, вы хотите, чтобы самый последний выпуск был тем, что по умолчанию извлекается в новом выпуске. клон, или, может быть, другие вещи, характерные для вашей команды и проекта.

person Mark Adelsberger    schedule 08.09.2020
comment
Использование --no-ff кажется именно тем, что мне нужно. Спасибо за информацию. - person Dave Ludwig; 09.09.2020