Вопрос: Лучший (и самый безопасный) способ объединить ветвь git в мастер


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

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

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

я бы сделал git pull origin masterиз test,

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


Моя работа над 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надеясь сохранить график как можно более линейный.


1427


источник


Ответы:


Как я это сделаю

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

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

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


2106



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

подобно

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в публичном филиале, как мастер-ветвь.

как следующая операция:

git checkout master
git rebase -i test

никогда не выполняйте эти операции.

Детали для https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

приложение:


251



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

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

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


71



Besides KingCrunches answer, I suggest to use

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

You might have made many commits in the other branch, which should only be one commit in the master branch. To keep the commit history as clean as possible, you might want to squash all your commits from the test branch into one commit in the master branch (see also: Git: To squash or not to squash?). Then you can also rewrite the commit message to something very expressive. Something that is easy to read and understand, without digging into the code.

edit: You might be interested in

So on GitHub, I end up doing the following for a feature branch mybranch:

Get the latest from origin

$ git checkout master
$ git pull origin master

Find the merge base hash:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Now make sure only the first is pick, the rest is s:

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

Next choose a very good commit message and push to GitHub. Make the pull request then.

After the merge of the pull request, you can delete it locally:

$ git branch -d mybranch

and on GitHub

$ git push origin :mybranch

20



This is the workflow that I use at my job with the team. The scenario is as you described. First, when I'm done working on test I rebase with master to pull in whatever has been added to master during the time I've been working on the test branch.

git pull -r upstream master

This will pull the changes to master since you forked the test branch and apply them, and then apply the changes you've made to test "on top of" the current state of master. There may be conflicts here, if the other people have made changes to the same files that you've edited in test. If there are, you will have to fix them manually, and commit. Once you've done that, you'll be good to switch to the master branch and merge test in with no problems.


3



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

After merging, if the file is changed, then when you merge it will through error of "Resolve Conflict"

So then you need to first resolve all your conflicts then, you have to again commit all your changes and then push

git push origin master

This is better do who has done changes in test branch, because he knew what changes he has done.


1