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

Question

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

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

Как обновить все остальные ветви с помощью master кода филиала?

Answer 1

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

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

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

git checkout b1

Затем объединить:

git merge origin/master

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

git push origin b1

В качестве альтернативы, вы можете сделать ребаз:

git fetch
git rebase origin/master

Answer 2

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

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

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

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

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

2. Вы перебазируете.Люди с 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
   

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

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

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

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

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

Answer 3

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

Answer 4

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

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 и множество других ресурсов в Интернете.

Answer 5

@ 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`

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

Answer 6

Для обновления других веток, таких как (резервная копия), с вашей копией главной ветки.Вы можете выполнить любой из этих способов (перебазировать или объединить) ...

1. Перебазировать (в резервной ветви не будет сделано никаких дополнительных изменений).

2. Слияние ветвей (будет дополнительная фиксация автоматически в резервную ветвь).

   Примечание: Rebase - это не что иное, как создание новой базы (новой копии)

git checkout backup
git merge master
git push

(Повторите для других филиалов, например, для backup2 и т. Д.,)

git checkout backup
git rebase master
git push

(Повторите для других веток, если они есть, например, backup2 и т. Д.,)

Answer 7

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