лучшая практика git с dev и master в удаленном - PullRequest
0 голосов
/ 06 января 2019

Удаленно, у меня есть две ветви: dev и master.

Я реализовал 3 функции (Feature A, B, C) и для каждой из них есть локальная ветвь. Затем я объединяю эти 3 функции в ветку dev по одной. Когда-нибудь я захочу выпустить свои изменения, чтобы объединить dev и master с помощью сквош-слияния. Теперь удаленный мастер имеет функции A, B и C.

Затем я реализовал Feature D и объединился с локальной веткой Feature D в dev. Я объединяю разработчика с мастером, отправляя запрос на извлечение. Тем не менее, я обнаружил, что коммиты Feature A, B, C также отображаются в этом запросе на извлечение. Это очень запутанно, но я нашел здесь ответ, чтобы объяснить это: Github "Squash and Merge" - последующий запрос на извлечение, показывающий все предыдущие изменения Что упоминает лучшую практику, это удалить ветку после слияния. Однако я не могу удалить ветку dev. Я хотел бы знать, что является лучшей практикой, в моем случае есть два удаленных филиала? Разумно ли мне объединять dev с Feature D в master, игнорируя дублирующие коммиты в запросе pull?

Ответы [ 3 ]

0 голосов
/ 06 января 2019

У вас есть функциональные ветви, ветка dev и ветка master. Похоже, ваш рабочий процесс очень похож на Git-Flow - успешная модель ветвления Git - кроме несоответствия dev против develop и без release ветвей.

Gitflow и аналогичные модели ветвления переносят изменения между develop и master с real слияниями - не с squash слияниями, как в вашем случае. Git видит слияние сквоша как новый коммит - он не отслеживает информацию о том, что вы объединили две строки работы (master и develop). Реальное слияние делает именно это отслеживание. Если вы используете реальное слияние, то git может сделать вывод, что A, B и C уже слиты, и опустить их в запросе на получение для D.

.
0 голосов
/ 06 января 2019

Сквошное слияние не является хорошей стратегией между двумя долгоживущими ветвями, которые необходимо синхронизировать. Наилучшим вариантом будет слияние master с dev, исправление конфликтов слияния и слияние dev с master

git checkout dev
git merge master
# Fix merge conflicts and commit, probably nothing appears as changed
git checkout master
git merge dev --no-ff # or use git merge dev --ff if you don't want a separate merge commit

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

0 голосов
/ 06 января 2019

почему вы не можете удалить ветку dev? потому что ты боишься потерять изменения, которые ты сделал? если это так, вы можете использовать git reset --soft для их хранения, удалите dev и создайте новый, а затем отмените их. если это не так, возможно, пытаясь перебазировать dev с master, используя флаг -i

...