Применяет ли git-flow линейную историю в некоторых ветвях?

Question

Я все еще пытаюсь перейти от мерзавца к мерзавцу.Я знаю, что могу использовать любую функцию git в git-flow, но меня больше всего интересует, что она обрабатывает автоматически.

Давайте предположим, что есть два разработчика Алиса и Боб, работающие над функциями A и B соответственно.Когда Алиса готова, она может сделать git flow feature finish A, чтобы создать коммит слияния в своей локальной ветке develop на основе коммита C. Теперь, если Боб заканчивает свою функцию в то же время, и он получил то же самое, его коммит слияниятакже будет основан на C. Теперь, если Алиса нажмет, а затем снова загрузит Боба, ему придется слить или перебазировать, и мы получим нелинейную историю на ветке develop, в случае, если он сливается.

Правильно ли это до сих пор, или git-flow как-то автоматически обрабатывает эту ситуацию?Если есть какой-то автоматический механизм, что нужно будет настроить для его работы?

Самое простое решение, вероятно, состоит в том, чтобы всегда извлекать develop перед завершением функций.Однако я не уверен, что это действительно возможно, в зависимости от способа совместного использования хранилища (может быть недоступно в это время).

РЕДАКТИРОВАТЬ (разъяснения проблемы):

Как показывают ответы, мой пример не был ясен.Итак, сначала картина того, что, на мой взгляд, является проблемой:

C - это начальный коммит в ветви разработки.

Алиса создает некоторую работу над функциями в ветви функций:

develop    feature/A
|           |
v           v
C-A1-A2-A3-A4

В то же время Боб также работает для другой функции

C-A1-A2-A3-A4
 \
  B1-B2-B3-B4

Теперь Алиса заканчивает функцию и добавляется коммит слияния для разработки (я хочу это).

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA

Теперь Боб заканчивает эту функцию, и снова добавляется коммит слияния для разработки (я также хочу, чтобы, просто в другом месте:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA <- develop for Alice
 \
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

Однако теперь Алиса или Боб должны слиться с разработкой, создавая дополнительный коммит:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA-MAB <- I don't want this MAB commit
 \               / 
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

То, что я хотел бы иметь вместо этого, было бы примерно таким:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA-MB
 \               / 
  B1-B2-B3-B4- -

Как вы можете видеть, история все еще нелинейна, однако основная линияветвь разработки содержит только коммиты слияния из функций (и никаких дополнительных коммитов слияния, как в другом случае).

Что мне нравится в этом, так это то, что вы можете легко следить за изменениями в истории и видеть,удлинить до прежних характерных веток или, если они были слияниями в развитии.Вся эта информация может быть получена непосредственно из DAG.

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

Answer 1

git-flow ничего такого не делает.

Он предназначен для поддержки модели ветвления, описанной здесь (которая на самом деле просто симпатичная картинка для тех вещей, которые рекомендуют разработчики Git). Эта картинка включает в себя слияния. Вы увидите то же самое по всему тексту. Под каждым типом ветки вы увидите типы веток, в которые они должны быть объединены . Существуют примеры команд, использующих --no-ff для принудительного предотвращения линейной истории и взамен записи слияний.

Это рабочий процесс, который действительно использует Git, и одной из основных сильных сторон Git является ветвление и слияние. Этот рабочий процесс процветает при слиянии; Нелинейная история не только неизбежна, но и желательна .

Вам следует прочитать раздел под названием «Включение готовой функции в разработку» из описания рабочего процесса. Краткая цитата:

Флаг --no-ff заставляет слияние всегда создавать новый объект фиксации, даже если слияние может быть выполнено с ускоренной перемоткой вперед. Это позволяет избежать потери информации об историческом существовании ветви объекта и объединяет все коммиты, которые вместе добавили функцию.

...

К сожалению, я пока не нашел способ сделать --no-ff поведением по умолчанию для git merge, но так оно и должно быть.

Вы хотите эти коммиты слияния. Вы действительно делаете.

Answer 2

Джефроми прав в том, что нет никакого вреда в том, чтобы это MAB слилось с историей.

Существует способ избежать этого коммита, потому что тот (допустим, что это B), который толкает свое слияние функций в центральный репо, не объединяет другой коммит слияния (здесь MA) в собственная история. Вместо этого второй должен уничтожить локальный коммит слияния (MB) и повторить слияние, где первый родитель теперь не C, а коммит слияния первого (MA). Таким образом, второй разработчик теперь создает слияние, которое содержит другое слияние и собственную ветку (новый MB).

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