Что является более умным способом для reset "ветки dev в Git?

У меня есть ветки master и dev. Всякий раз, когда я объединяю dev в master, я должен использовать метод --no-ff (без быстрой перемотки вперед). Что я делаю в данный момент, после слияния:

Это позволяет мне продолжить разработку на dev после слияния. Есть ли более умный/более короткий способ сделать это?

Изменить:

Просто продолжая фиксировать dev и объединяясь с master, получается следующий график:

Однако, если я удалю dev и снова вернусь из master, у меня может быть следующий график:

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

Что касается того, почему у меня этот подход в первую очередь: my master - это в основном SVN, где мне разрешено только определенные сообщения о совершении (и, следовательно, ограниченное количество коммитов). Поэтому я развиваюсь на dev, и когда я готов, я сливаюсь, чтобы освоить и оставить правильное сообщение фиксации.

Контекст:

Я использую рабочий процесс, описанный в этом ответе. Я как-то понял, что мне нужно удалить dev и перевернуть от master после того, как я нажму изменения SVN.

Ответы

Ответ 1

TL; DR

В Git ветвь с именем dev, указывающая на данное коммитирование (например, cf2308e), остается одной и той же ветвью, даже если вы ее удалите и заново создадите. Имя ветки содержит ссылку на фиксацию; Git не несет никакой другой истории, связанной с веткой, поэтому то, что вы делаете, по своей сути не полезно для Git или для вас.

Продолжить после слияния

У меня есть мастер и dev ветки. Всякий раз, когда я объединяю dev в master, я должен использовать метод -no-ff (без быстрой перемотки вперед).

Обычно это делается, когда они хотят принудительно выполнить слияние, а не ускоренную перемотку вперед. Некоторым магазинам нравится делать это, чтобы отслеживать слияния из ветки в сообщениях фиксации, так как Git commites фактически не несет никакой информации о филиале. В Git членство ветвления выводится из предков коммитов, а не хранится как явные данные, например, в некоторых других системах управления распределенной версией.

Однако нет никакой полезной причины для фактического удаления объединенной ветки с "reset dev." Вы можете продолжить разработку в ветки dev, а Git будет достаточно умным, чтобы не повторять слияние с тем же самым коммитом при следующем объединении с мастером.

Удаление и повторное создание dev на самом деле не купит вам ничего, если вы просто хотите снова отвести кончик мастера. Поскольку вы не используете ветки темы с полезными именами, и вы не делаете раздавленные коммиты, мой совет состоит в том, чтобы просто продолжить работу над dev после слияния с мастером.

Сброс ветки

Единственный реальный прецедент для этого заключается в том, что вы объединяете нечто, отличное от кончика ветки dev. В этом случае вы можете отказаться от чего-либо от разработчика, который еще не находится на сервере. Если это случай:

git checkout master
git merge --no-ff <some_commit>

git checkout dev
git reset --hard master
git push --force origin dev

Обратите внимание, что если вы перемотаете кончик ветки, вам, вероятно, придется принудительно нажать, чтобы reset указатель на вашем пульте. Повторная перемотка также заставит любого из вас или из благословенного репозитория отреагировать на повторное клонирование или выполнить принудительное reset ветки dev. Например:

git checkout dev
git fetch --all
git reset --hard origin/dev

Ответ 2

Чтобы избежать необходимости удалять dev и повторно создавать, если из master, вы можете просто git reset --hard master в то время как на ветке dev.