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

Я новичок в Git, и теперь я в этой ситуации:

У меня четыре ветки (master, b1, b2 и b3).
После того, как я работал над b1-b3, я понял, что мне нужно что-то изменить на ветке, который должен быть во всех других ветвях.
Я изменил то, что мне нужно в master и... вот моя проблема:

Как обновить все другие ветки с помощью кода ветвления master?

Ответ 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 не стоит.