Слияние филиалов от Git

Question

Наша среда разработки состоит из dev, demo и master ветвей. Мы используем JIRA для отслеживания проблем, и каждый раз, когда мы начинаем выпуск, мы отключаем dev, вносим необходимые изменения и, наконец, выталкиваем ветку.

Для тестирования мы сначала объединить ветвь (что соответствует названию вопроса JIRA) в dev, проверить его, а затем сливаются в demo, проверить его, а затем сливаются в master.

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

Предположим, у нас есть обычная среда, dev, demo и master. Существует три вопроса: TEST-1, TEST-2 и TEST-3. Вопросы завершаются в том порядке, в котором они были созданы, путем отделения от dev, работающего на ветке, а затем совершения и нажатия ветви. Затем я объединяю ветвь в dev, прежде чем разветвляться снова для следующей проблемы.

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

git fetch origin 

Это позволит мне увидеть новые ветви. Предположим, мы хотим только внести изменения для TEST-3. Бежим команду:

git merge origin/TEST-3 

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

Это не то, что мы хотим, так как при таком поведении мы не можем отменить отдельные ветви.

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

Answer 1

Как вы описали, ваш рабочий процесс должен работать так, как вы хотите. Единственное уточнение, которое я мог бы посоветовать, заключается в использовании git merge --no-ff origin/TEST-3, чтобы объединить работу с конкретной ветвью, поэтому git всегда создает фиксацию слияния на dev, что при необходимости можно вернуться позже, даже если слияние тривиально.

Ты уверен, что ветки TEST-1, TEST-2, и TEST-3 были созданы с dev правильно? Если разработчик, работающий с TEST-2, создал новый филиал на основе TEST-1 по ошибке, например, слияние в TEST-2 также объединит все коммиты на TEST-1, которые были сделаны до точки перехода. git checkout -b TEST-2 создаст ветку под названием TEST-2 , начиная с текущей вывешенной ветки, поэтому было бы легко случайно отбросить последний билет, над которым вы работали по ошибке. Указание явной начальной точки с чем-то вроде git checkout -b TEST-3 origin/dev может вызвать меньше проблем.

Между тем, вы можете диагностировать историю вы уже создали с git log как так:

# Show an ASCII art graph of all branch heads. Depending on the complexity 
# of your repository, this may or may not be too noisy to be useful. 
git log --oneline --decorate --graph --all 

# Graphing specific branches might be more readable: 
git log --oneline --decorate --graph dev origin/TEST-3 

# Show the commits that are reachable by TEST-3, but not by dev. 
# This tells you exactly what work you're about to merge in 
# If TEST-3 includes TEST-2 or TEST-1 by mistake, you'll see extra commits here. 
git log --oneline origin/TEST-3 ^dev 
# Or equivalently: 
git log --oneline dev..origin/TEST-3 

Если у вас уже есть работа на ветке, которая была основана на неправильном отправную точку, вы можете переместить совершающее вы хотите вернуться к dev с git rebase --onto:

# I like to include the -i to see what commits I'm about to move before 
# the rebase actually happens. 
git rebase -i --onto dev TEST-3 TEST-2