Каков наилучший (и самый безопасный) способ объединения ветки Git в мастера?

Создается новая ветвь из master, мы называем ее test.

Есть несколько разработчиков, которые либо передают на master, либо создают другие ветки, а затем сливаются в master.

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

Я сделал бы git pull origin master из test.

Вопрос 1: Правильно ли это? Другие разработчики могли легко работать с теми же файлами, с которыми я работал. Кстати,

Выполняется моя работа над test, и я готов снова объединить ее с master. Вот два способа, о которых я могу думать:

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test

B:

git checkout test
git pull origin master
git checkout master
git merge test

Я не использую --rebase, потому что, по моему мнению, rebase получит изменения от master и уложит мой поверх этого, поэтому он может перезаписать изменения, сделанные другими людьми.

Вопрос 2: Какой из этих двух методов прав? В чем разница?

Цель состоит в том, чтобы сохранить ветвь test обновленной с вещами, происходящими в master, и позже я смогу объединить их обратно в master, надеясь сохранить график как можно более линейный.

Ответы

Ответ 1

Как бы я это сделал

git checkout master
git pull origin master
git merge test
git push origin master

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

git всегда пытается уважать ваши и другие изменения, и так будет --rebase. Я не думаю, что могу объяснить это правильно, поэтому посмотрите книгу Git - Rebasing или git -ready: введение в перезагрузку для небольшого описания. Это довольно крутая функция

Ответ 2

Это очень практичный вопрос, но все ответы выше не практичны.

подобно

git checkout master
git pull origin master
git merge test
git push origin master

Этот подход имеет два вопроса:

  1. Это небезопасно, потому что мы не знаем, есть ли какие-либо конфликты между тестовой веткой и главной ветвью.

  2. Он "сжимал" все тестовые коммиты в одно объединение слияния на master; то есть на главной ветке, мы не можем видеть все журналы изменений тестовой ветки.

Поэтому, когда мы подозреваем, что возникнут некоторые конфликты, мы можем выполнить следующие операции git:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Слейте тестовое merge перед commit, избегайте быстрого переадресации с помощью --no-ff,

Если конфликт встречается, мы можем запустить git status чтобы проверить сведения о конфликтах и попытаться решить

git status

Когда мы решаем конфликты или если нет конфликта, мы commit и push их

git commit -m 'merge test branch'
git push

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

Поэтому лучшим методом является использование rebase вместо merge (предположим, когда в это время мы решили конфликты ветвей).

Ниже приведен простой пример, для расширенных операций см. Http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

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

Единственное, чего вам нужно избегать: никогда не используйте rebase в публичной ветки, как master branch.

Никогда не выполняйте следующие операции:

git checkout master
git rebase -i test

Подробная информация о https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

приложение:

Ответ 3

Ни перебаза, ни слияние не должны перезаписывать никому изменения (если вы не решите сделать это при разрешении конфликта).

Обычный подход при разработке

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Когда вы будете готовы объединиться в мастер,

git checkout master
git log ..test # if you're curious
git merge test
git push

Если вы беспокоитесь о нарушении чего-то в слиянии, git merge --abort есть для вас.

Использование push, а затем pull, как средство слияния, является глупым. Я также не знаю, почему вы нажимаете тест на происхождение.

Ответ 4

Сначала я бы сделал ветвь, которая должна быть объединена, максимально чистой. Запустите свои тесты, убедитесь, что состояние соответствует желаемому. Убери новых коммитов с помощью git squash.

Помимо ответа KingCrunches, я предлагаю использовать

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Вы могли сделать много коммитов в другой ветке, которая должна быть только одна коммит в основной ветке. Чтобы сохранить историю коммитов настолько чистой, насколько это возможно, вы можете сжать все свои коммиты из тестовой ветки в один коммит в основной ветке (см. Также: Git: сквошить или не сквошить?). Затем вы также можете переписать сообщение коммита в нечто очень выразительное. То, что легко читать и понимать, не копаясь в коде.

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

Итак, на GitHub я заканчиваю тем, что делаю следующее для функциональной ветки mybranch:

Получить последнюю версию от происхождения

$ git checkout master
$ git pull origin master

Найдите базовый хеш слияния:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Теперь убедитесь, что только первое pick, остальное s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Затем выберите очень хорошее сообщение коммита и нажмите на GitHub. Сделайте запрос на извлечение.

После объединения запроса на удаление вы можете удалить его локально:

$ git branch -d mybranch

и на GitHub

$ git push origin :mybranch

Ответ 5

Это рабочий процесс, который я использую на своей работе с командой. Сценарий, как вы описали. Во-первых, когда я закончил работу над test, я переустанавливаю мастер, чтобы вытащить все, что было добавлено в мастер, в то время, когда я работал над ветвью test.

git pull -r upstream master

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

Ответ 6

git checkout master
git pull origin master
# Merge branch test into master
git merge test

После слияния, если файл будет изменен, тогда при слиянии он будет через ошибку "Разрешить конфликт"

Итак, тогда вам нужно сначала разрешить все ваши конфликты, тогда вы должны снова выполнить все свои изменения, а затем нажать

git push origin master

Это лучше, кто сделал изменения в тестовой ветке, потому что знал, какие изменения он сделал.

Ответ 7

Я бы использовал метод rebase. В основном потому, что он отлично отражает ваш случай семантически, т.е. то, что вы хотите сделать, - это обновить состояние вашей текущей ветки и "притвориться", как если бы она была основана на последних.

Поэтому, даже не проверив master, я бы:

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

Конечно, только выборка из источника не обновляет локальное состояние вашего master (поскольку оно не выполняет слияние), но это совершенно нормально для нашей цели - мы хотим избежать переключения, ради экономии времени.

Ответ 8

Старый поток, но я не нашел свой способ сделать это. Это может быть полезно для тех, кто работает с rebase и хочет объединить все коммиты из ветки поверх master. Если есть конфликт, вы можете разрешить его для каждого коммита.

Получить Мастер и Филиал в актуальном состоянии:

git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>

Слияние ветки поверх мастера:

git checkout <branch_name>
git rebase master

Если вы столкнетесь с конфликтами во время перебазирования:

Сначала разрешите конфликт в файле. Затем:

git add .
git rebase --continue

Как только rebase закончится, перебазируйте ветку поверх мастера:

git checkout master
git rebase <branch_name>

Ответ 9

Это просто, просто выполните следующие шаги.

  • Git мастер проверки
  • Git merge
  • Git кнопка начала оригинала ИЛИ Если он бросает какую-либо ошибку, вы также можете сделать принудительное нажатие

Git Нажмите начальный мастер

Что это.