рабочий процесс git для слияния с использованием быстрой перемотки вперед

Я использую git в нескольких проектах со многими разработчиками. Мой обычный рабочий процесс заключается в локальном ветвлении для конкретной функции/запроса, слиянии моих изменений в локальную ветку, отслеживаемую вверх по течению как быстрое слияние вперед, и отправке изменений. Я всегда делаю ветки даже для одного коммита. Я никогда не делаю локальную фиксацию в ветке, которой делюсь с другими, поэтому я могу свободно перебазировать/сбрасывать локально, пока не отправлю свои изменения вверх по течению. В качестве предпочтения я предпочитаю, чтобы мои слияния выполнялись с быстрой перемоткой вперед, когда это возможно. В качестве примера, если все для версии 1 проекта выдвигаются всеми разработчиками в ветке origin/v1, я бы:

git checkout v1
git checkout -b feature-A
#Do work on feature-A branch.  Test, rebase --interactive to clean up

В конце концов я нахожусь в точке, где хочу объединить свои изменения в v1 локально и нажать на origin/v1. Я сделаю git fetch origin с проверенным feature-A. Если будут внесены изменения, я проверю v1 и объединим

git fetch origin
#If New changes are present checkout v1 and merge
git checkout v1
git merge origin/v1 #I could pull but I prefer to fetch, log origin/v1, and then merge

Теперь, чтобы добиться быстрого слияния вперед для feature-A, я извлекаю feature-A, перебазирую в v1, извлекаю v1, объединяю feature-A и нажимаю v1 обратно в origin.

git checkout feature-A
git rebase v1
git checkout v1
git merge --ff-only feature-A
git push origin v1

Нет ничего плохого в коммитах без быстрой перемотки и нет ничего плохого в коммите слияния. Опять же, это просто вопрос предпочтений. Мне интересно, есть ли лучший рабочий процесс для выполнения того же самого без прохождения всех проверок веток. Может быть команда git, о которой я не знаю, которая будет работать после того, как я перебазирую feature-A поверх обновленной ветки v1.

https://stackoverflow.com/a/4157106/620304 похоже, что это может помочь. Возможный рабочий процесс может состоять в том, чтобы обновить v1 последними изменениями из источника и обновить v1 до HEAD feature-A локально после перебазирования:

#Starting from feature-A currently checked out
git fetch origin
#New changes are present
git checkout v1
git merge origin/v1
git checkout feature-A
#In I didn't fetch anything from origin's v1 branch I can skip the commands between the comments
git rebase v1
git branch -f v1 feature-A
git push origin v1

Я уверен, что может быть еще лучший способ. Любая помощь/вклад очень ценится.


person Joel    schedule 26.02.2013    source источник
comment
Вам не нужна ветка для каждого коммита, у вас могут быть и долгоживущие ветки (например, для разработки новых функций в виде серии коммитов). Просто перебазируйте (или объедините) их в ветку, чтобы опубликовать, когда они будут готовы.   -  person vonbrand    schedule 27.02.2013
comment
@vonbrand - согласен. Я не разветвляюсь для каждого коммита. Я предпочитаю всегда ветвление для функции, будь то 1 коммит или более. Я считаю, что ветвление проще, чем работать с веткой, отслеживаемой из вышестоящего репо.   -  person Joel    schedule 28.02.2013


Ответы (1)


Рабочий процесс, в котором используются только быстрые слияния, по сути является рабочим процессом перебазирования. Общий рабочий процесс перебазирования работает очень похоже на пример, который вы привели, за исключением git rebase origin/v1 вместо слияния.

Самая цитируемая статья, которую я видел, — это сообщение в блоге Рэнди Фэя: A Rebase Workflow for Git .

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

person David Culp    schedule 26.02.2013
comment
Просто будьте осторожны, так как rebase по своей сути является операцией перезаписи истории, вы создаете коммиты, которых никогда раньше не было (не говоря уже о том, чтобы быть протестированными). - person vonbrand; 27.02.2013