Обновить ветки Git от мастера

Ответ 1

У вас есть два варианта:

Первый - это слияние, но это создает дополнительную фиксацию для слияния.

Оформить каждую ветку:

git checkout b1

Затем слейте:

git merge origin/master

Затем нажмите:

git push origin b1

В качестве альтернативы вы можете выполнить rebase:

git fetch
git rebase origin/master

Ответ 2

У вас есть в основном два варианта:

• Вы сливаетесь. Это на самом деле довольно просто и идеально локальная операция:

  git checkout b1
  git merge master
  # repeat for b2 and b3
  

  Это оставляет историю точно так же, как это произошло: вы разветвлялись от мастера, вы вносили изменения во все ветки, и, наконец, вы включили изменения из мастера во все три ветки.

  git может справиться с этой ситуацией очень хорошо, она предназначена для слияний, происходящих во всех направлениях, в то же время. Вы можете доверять ему, что сможете правильно собрать все потоки. Просто не волнует, объединяет ли ветвь b1 master или master merges b1, объединение слияния все равно относится к git. Единственное различие заключается в том, какая ветвь заканчивается, указывая на это слияние.

• Вы переустанавливаете. Люди с SVN или подобным фоном находят это более интуитивно понятным. Команды аналогичны случаю слияния:

  git checkout b1
  git rebase master
  # repeat for b2 and b3
  

  Люди любят этот подход, потому что он сохраняет линейную историю во всех ветвях. Однако эта линейная история - это ложь, и вы должны знать, что она есть. Рассмотрим этот график фиксации:

  A --- B --- C --- D <-- master
   \
    \-- E --- F --- G <-- b1
  

  Слияние приводит к истинной истории:

  A --- B --- C --- D <-- master
   \                 \
    \-- E --- F --- G +-- H <-- b1
  

  Однако rebase дает вам эту историю:

  A --- B --- C --- D <-- master
                     \
                      \-- E' --- F' --- G' <-- b1
  

  Дело в том, что коммиты E', F' и G' никогда не существовали и, вероятно, никогда не тестировались. Они даже не компилируются. На самом деле довольно просто создать бессмысленные коммиты через rebase, особенно когда изменения в master важны для разработки в b1.

  Следствием этого может быть то, что вы не можете различить, какая из трех коммитов E, F и G действительно ввела регрессию, уменьшив значение git bisect.

  Я не говорю, что вы не должны использовать git rebase. Он имеет свое применение. Но всякий раз, когда вы его используете, вам нужно знать, что вы лжете об истории. И вы должны хотя бы скомпилировать тест на новые коммиты.

Ответ 3

git rebase master - это правильный способ сделать это. Слияние будет означать, что для слияния будет создано фиксация, тогда как перезагрузка не будет.

Ответ 4

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

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Примечания:

• Не переустанавливайте ветки, с которыми вы сотрудничали с другими.
• Вы должны переустанавливать ветку, к которой вы будете объединяться, которая не всегда может быть мастером.

Там есть глава, посвященная перезагрузке http://git-scm.com/book/ch3-6.html и загрузке других ресурсов в Интернете.

Ответ 5

Вы можете объединить, или вы можете применять отдельные фиксации по ветвям, используя git cherry-pick.

Ответ 6

@cmaster сделал наилучший отработанный ответ. Вкратце:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Вы не должны переписывать историю ветвей, а не сохранять их в реальном состоянии для будущих ссылок. При слиянии с мастером он создает один дополнительный фиксатор, но это дешево. Commits не стоит.