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

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

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

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

 jww08 февр. 2018 г., 21:15
Еще одна простая задача, затрудненная Git. Разработчики Git должны использовать переполнение стека в качестве обратной связи в своем цикле SDLC. 300 000 человек должны указать, что что-то не так с рабочим процессом Git. Им нужно нанять эксперта по UX, потому что они явно не могут сделать это самостоятельно.
 wjandrea18 окт. 2017 г., 17:45

Ответы на вопрос(7)

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

 Junchen Liu07 янв. 2016 г., 13:42
rebase и объединить обе работы, rebase лучше всего подходит для частных филиалов, потому что он дает более чистый график истории. этот ответ самый лучший
 stormwild15 июл. 2013 г., 05:24
Если вы единственный, кто работает с удаленной веткой, вы можете использовать функцию git push --force origin, чтобы обновить удаленную ветку перебазированной локальной веткой.stackoverflow.com/questions/8939977/...
 Matt Smith23 нояб. 2012 г., 00:30
Как насчет того, когда вы уже выдвинули к исходной точке, если вы перебазируете, вы будете переписывать историю коммитов, и это будет конфликтовать с вашей удаленной веткой. Я думаю, что rebase должен использоваться только при извлечении или когда вы не выдвинули удаленную ветку.
 WillC23 нояб. 2016 г., 22:47
Необходимо прояснить компромисс между ясностью (отлично подходит для одного пользователя или небольшой команды) или грязной правдой (для веток кода с несколькими участниками - требуется для удобства обслуживания (по моему опыту - YMMV)).

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

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

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

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

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

git checkout backup
git merge master
git push

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

git checkout backup
git rebase master
git push

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

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

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

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

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

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

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

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

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

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

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

 arn-arn28 мар. 2019 г., 15:37
это помогло. Благодарю.
 piratemurray06 дек. 2016 г., 23:02
История это ложь
 blamb25 апр. 2019 г., 19:44
@cmaster - это отличная возможность скрыть несколько этапов перебазирования, хотя для меня это не история, а история - это то, что я делал с кодом, а не столько, сколько пришлось делать репо для отслеживания того, что я делаю, так что да, может быть, все, что не нужно для журналов git overhead, или для сохранения только истории кода, перейдите с rebase. Лично мне не нравится объединять ветки с 5 другими ветвями, что я и должен делать в этом конкретном потоке, поэтому я вижу свет там.
 Priti14 мар. 2019 г., 19:31
Спасибо, я использую "git merge any-branch-name", чтобы объединить один код ветви с другим. Локально я могу проверить код ветви 1, пока я нахожусь на ветви 2
 Rod19 авг. 2015 г., 08:14
Я объединял другую ветку с исходным кодом (не основную), и дополнительными шагами, чтобы добавить к этому приятному ответу, было обновить его в моем локальном репо перед слиянием (чтобы иметь последний код локально):git checkout <source branch> git pull, Затем продолжаем с выше:git checkout b1 ...
 blamb25 апр. 2019 г., 00:32
When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort".  так что да, я действительно слился первым, прежде чем я попробовал это, это был просто концептуальный тест, так что будьте осторожны! Лично мне нравится опция слияния, кому все равно, из какой ветки она написана, до сих пор ее правильная история.
 blamb25 апр. 2019 г., 00:32
или вы могли бы закончить с этим, из такого сценария, огромным беспорядком (только сначала ветвь)$ git rebase production First, rewinding head to replay your work on top of it... Applying: ADDED TO ENV AS TEST Using index info to reconstruct a base tree... M Puppetfile Falling back to patching base and 3-way merge... Auto-merging Puppetfile CONFLICT (content): Merge conflict in Puppetfile Failed to merge in the changes. Patch failed at 0001 ADDED TO ENV AS TEST The copy of the patch that failed is found in: /home/user/src/puppet4-controlrepo/.git/rebase-apply/patch
 cmaster25 апр. 2019 г., 00:52
@blamb Конфликты слияния происходят с обоимиgit merge а такжеgit rebase, Там не избежать этого.git rebase обладает тем преимуществом, что позволяет скрывать несколько этапов перебазирования (то есть перебазирование одной и той же ветви на несколько последовательных коммитов, чтобы уменьшить количество конфликтов на каждом этапе). Тем не менее, сам факт того, что ребаз лжет об истории, намного проще испортить добро в таком многоступенчатом ребазе ... Вот почему я всегда предпочитаю слияние, даже когда это означает, что мне нужно загромождать историю несколькими коммитами слияния ,
 WillC23 нояб. 2016 г., 22:44
Как давний пользователь SVN, я предпочитаю вариант слияния перебазированию: при любом контроле версий очень и очень важно вести точный учет внесенных вами изменений и почему. Я вижу привлекательность перебазирования для упрощения кажущейся истории, но затем вам следует вернуться и добавить к коммиту комментарии E ', F', G '- и желательно, чтобы ребаз автоматически добавлялся к этим комментариям. В противном случае, если процесс build / test / test-deploy обрывается на G ', вам нужно выяснить, почему изменения были сделаны без полной информации.

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

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

Вы можете объединить, или вы можете применить отдельные коммиты через филиалы с помощьюмерзавец.

Решение Вопроса

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

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

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

git checkout b1

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

git merge origin/master

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

git push origin b1

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

git fetch
git rebase origin/master
 Yves Lange25 янв. 2016 г., 12:12
Вы объединяете мастера в b1. Почему тыgot push origin master... не имеет смысла. Вы не меняете основную ветку. Я думаю, что это ошибка с 119 upvote: /
 beyondtheteal05 июл. 2018 г., 17:28
Для тех из нас, кто читает позже - беспокойство @Kursion по поводу опечатки было решено редактором автора. Кроме того, второй ответ с наивысшим рейтингом ниже говорит в основном то же самое, что и этот ответ, но с диаграммой структуры ветвей и предупреждением о том, почему вы не хотите перебазировать.
 Dr_Zaszuś10 апр. 2018 г., 15:32
Этот ответ не очень полезен, потому что не ясно, что происходит со структурой ветви. Кажется, чтоmaster ветвь исчезнет совсем.
 Patrick16 нояб. 2011 г., 19:55
Я обеспокоен этим подходом. Когда я запускаю git log --graph, график показывает, что мастер фактически объединен с веткой темы. Это вызовет какие-либо проблемы в долгосрочной перспективе? Я думал, что лучшая практика - это всегда объединять ветку темы с мастером. Прокомментируйте, пожалуйста.
 Weston Ganger12 янв. 2017 г., 18:33
Не используйте метод слияния, используяgit rebase master правильный ответ
 Hampus Ahlgren06 июн. 2013 г., 19:57
Ищите эту проблему, если вы собираетесь с рабочим процессом слияния:randyfay.com/node/89
 cmaster13 февр. 2015 г., 18:19
@HampusAhlgren Что по сути сводится к следующему: не давайте власть людям, которые не могут с этим справиться. Конечно, я понимаю, что существуют другие системы контроля версий, которые работают по-другому, чем git, и я знаю проблемы, которые возникают у меня, когда мне нужно использовать SVN. Но всякий раз, когда я это делаю, я вдвойне осторожен, чтобы не делать что-то неправильно и проверять, что я действительно делаю то, что хотел, потому что я знаю, что я не понимаю svn так же хорошо, как я понимаю git. Я ожидал бы такой же осторожности от svn (или чего-либо еще) gui, делающего git.

Ваш ответ на вопрос