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

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

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

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

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

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

Оформить заказ каждой ветви:

git checkout b1

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

git merge origin/master

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

git push origin b1

Кроме того, вы можете сделать ребаз:

git fetch
git rebase origin/master

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

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

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

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

   gitможет справиться с этой ситуацией действительно хорошо, он предназначен для слияния, происходящего во всех направлениях, в то же время. Вы можете доверять этому, чтобы быть в состоянии собрать все нити вместе правильно. Ему просто не важно, b1сливается ветвь masterили masterсливается 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. Это имеет свое применение. Но всякий раз, когда вы используете его, вы должны осознавать тот факт, что вы лжете об истории. И вы должны по крайней мере скомпилировать тест новых коммитов.

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

Если вы работали над веткой время от времени или в других ветвях происходило много всего, когда вы работали над чем-то, лучше перенести вашу ветку на 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 есть глава о перебазировании и множество других ресурсов в Интернете.

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

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

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

1. Сделайте ребаз (не будет никакого дополнительного коммита, сделанного в резервную ветку).

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

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

git checkout backup
git merge master
git push

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

git checkout backup
git rebase master
git push

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

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

Есть два варианта этой проблемы.

1) git rebase

2) git merge

Только в случае слияния с обоими выше в случае слияния, будет иметь дополнительный коммит в истории

1) ветка git checkout (b1, b2, b3)

2) git rebase origin / master (в случае конфликтов разрешите локально, выполнив git rebase --continue)

3) git push

Альтернативно, опция git merge аналогична

1) git checkout "your_branch" (b1, b2, b3)

2) мастер слияния

3) git push

обновить ветку от мастера:

  git checkout master
  git pull
  git checkout your_branch
  git merge master