Сохранение чистой истории git при использовании gitflow - неотправленные коммиты на разработке

Используя gitflow, при создании release-1.0.0ветви и объединении ее с обеими ветвями masterи developобеими ветвями будет отсутствовать коммит:

masterне будет коммит, где release-1.0.0было слияние сdevelop
developне будет коммит, где release-1.0.0было слияние сmaster

Вместо этого после hotfix-1.0.1создания и слияния с ним master, когда слияния с develop, коммиты для слияния будут включать в себя предыдущий коммит, с которым release-1.0.0был слит master; так это будет выглядеть так:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Если это звучит запутанно, вы можете легко заметить, что все, что вы видите develop, обычно отстают на пару коммитов master(хотя разработка, теоретически, должна быть только впереди, поскольку это основная ветвь. Эти коммиты являются слиянием с release-x.x.xв master).

Как с этим обращаться, чтобы поддерживать чистую историю?

git gitflow

— Кристофер Франциско
источник

Пожалуйста, определите «чистую историю».

— Джейс Браунинг

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

— FP

Слияние с мастером будет «копией», нет необходимости объединять его для разработки. Делайте оперативные исправления из предыдущей ветки релиза, а не мастера, и объединяйте их оттуда, и у вас не возникнет проблемы. Мастер не добавляет много к модели, так что вы действительно можете полностью отказаться от нее, ИМО.

— Axl

@axl Я понимаю, что ты имеешь в виду, но я пытаюсь следовать gitflow как можно ближе к его документации. Я бы предпочел не делать никакого «хакза», потому что поскольку gitflow уже принят многими многими разработчиками, у них уже должно быть решение для этой простой вещи

— Кристофер Франсиско

Есть несколько дискуссий о том, как решить различные проблемы с GitFlow на GitHub и в других местах. Иногда там просто нет серебряной пули.

— Axl

Я думаю, что хороший подход состоит в том, чтобы избежать двух "основных" веток, master и development, которые являются избыточными. Это подробно объяснено здесь , заклейменным cactus-flowавтором.

Некоторые моменты выделяются в отличие от git-потока:

Всего одна основная ветка
Только ускоренные слияния

Для меня важно последнее, так как после долгого использования git-flow мне еще предстоит увидеть, что полезного в --no-ffслияниях.

Я пытаюсь следовать gitflow как можно ближе к его документации. Я бы предпочел не делать никаких «хакз», потому что поскольку gitflow уже принят многими разработчиками, у них уже должно быть решение для этой простой вещи.

ИМХО это твоя большая ошибка. У вас нет причин придерживаться мерзавца настолько, насколько это возможно. Он может быть использован в тысячах проектов, но это не влияет на ваш, не делает его хорошим.

Git-flow - хорошая отправная точка, но вы должны подумать об адаптации его к своим инструментам и рабочему процессу, а не наоборот.

— Серхио Басурко
источник