Поддержание ветки в актуальном состоянии с мастером

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

  1. Начальное ветвление и проверка:

    git checkout master

git pull

git checkout -b my_branch

  2. Поработайте в my_branch, затем периодически:

    git checkout master

git pull

git checkout my_branch

git merge master --no-ff

При необходимости повторите шаг 2 с периодическими нажатиями на удаленный my_branch.

Затем, когда все будет готово к слиянию:

git checkout master

git merge my_branch --no-ff

Звук в порядке?


git git-branch git-merge
person larryq    schedule 03.11.2013    source источник

Ответы (2)


arrow_upward
22
arrow_downward

Вы можете упростить свои команды:

1.

git fetch
git checkout -b my_branch origin/master

2.

git fetch
git merge origin/master

git fetch обновляет ваши удаленные ветки, обычно нет необходимости иметь локальную копию ветки, если вы не планируете работать с этой веткой.

Вы можете опустить --no-ff после установки git config --global merge.ff false.

git help config говорит:

   merge.ff
       By default, Git does not create an extra merge commit when merging
       a commit that is a descendant of the current commit. Instead, the
       tip of the current branch is fast-forwarded. When set to false,
       this variable tells Git to create an extra merge commit in such a
       case (equivalent to giving the --no-ff option from the command
       line). When set to only, only such fast-forward merges are allowed
       (equivalent to giving the --ff-only option from the command line).

Имейте в виду, что git pull — это просто комбинация git fetch и git merge.

Обычно вы просто хотите git pull --rebase, что по сути является git fetch плюс git rebase, и создает гораздо более чистую историю.

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

person michas    schedule 03.11.2013
comment
Спасибо за ваш (и Кристофа) ответ. Чтобы ответить на ваш вопрос, нет причин для периодических толчков, кроме как в качестве резервной копии на случай, если мой ящик умрет. И в случае, если кто-то захочет, чтобы мой код выполнял свою собственную работу - маловероятно, пока мой код не попадет в мастер, плюс выполнение перебазирования в общедоступной ветке может привести к проблемам, поэтому я понимаю (но не уверен, почему именно .) - person larryq; 04.11.2013
comment
rebases — палка о двух концах. с одной стороны, они часто ведут к гораздо более ясной истории. с другой стороны, они создают совершенно новые коммиты со старым содержимым. Если вы подтолкнете свои коммиты, кто-то другой может (теоретически) создать свои собственные изменения на этих коммитах. Если вы позже решите перебазировать свои коммиты, вы фактически сделаете старые коммиты недействительными, и все изменения будут основываться на них. - Даже если вы удалите свою старую ветку, другая может подтолкнуть свои изменения и, следовательно, также подтолкнуть ваши старые изменения, что приведет к дублированию коммитов и беспорядку в результате. :) - person michas; 04.11.2013
comment
Еще раз большое спасибо. Я читал о git pull --rebase и не знаю на 100%, что произойдет, если я вызову его, находясь (скажем) в настоящее время в my_branch. В этом случае команда извлекает из удаленного my_branch, а затем выполняет перебазирование... в какую ветку? Я бы предположил, что не мастер, поскольку я нигде не упомянул об этом в команде. Так что это должно быть перебазирование против my_branch, что звучит немного странно для меня, поскольку я всегда перебазировал две отдельные ветки. Но я предполагаю, что это возможно, и теперь, когда я об этом думаю, почему бы и нет? - person larryq; 05.11.2013
comment
git pull и git pull --rebase оба работают с настроенным восходящим потоком (см. git branch -vv). Обычно локальная ветвь my_branch будет отслеживать удаленную ветвь origin/my_branch. Но перед тем, как вы нажмете в первый раз, вполне нормально отследить источник/мастер. git pull --rebase просто извлекает текущую версию вышестоящей ветки, сбрасывает вашу ветку до этой версии и воспроизводит все сделанные вами коммиты. Следовательно, вы получаете одни и те же изменения только на основе текущей версии вышестоящей ветки. - person michas; 05.11.2013
comment
вы можете увидеть перебазирование в работе с git tag old_state; git pull --rebase; gitk HEAD old_state. Учитывая, что вы уже сделали некоторые локальные коммиты и есть новые коммиты в восходящем потоке, вы должны увидеть как ваши исходные коммиты, основанные на старой версии восходящего потока, так и перебазированные коммиты, основанные на текущей версии восходящего потока. - person michas; 05.11.2013

arrow_upward
14
arrow_downward

Я бы посоветовал использовать рабочий процесс rebase. Поэтому вместо использования git pull вы должны использовать git pull --rebase.

Я бы сделал то же самое с веткой функций. Поэтому вместо git merge master --no-ff я бы использовал git rebase master. Однако, если функциональная ветвь предназначена для совместного использования с коллегами во время разработки, вам лучше периодически объединять основную ветвь с функциональной ветвью.

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

Обязательно прочитайте это.

Рабочий процесс Git и вопросы о перебазировании и слиянии

person Christoph    schedule 03.11.2013