Get changes from master into branch in Git

Question

In my repository I have a branch called aq which I'm working on.

I then committed new work and bugs in master.

What is the best way to get those commits into the aq branch? Create another new branch out of master and merge it with aq?

Solution 1

Check out the aq branch, and rebase from master.

git checkout aq
git rebase master

Solution 2

You should be able to just git merge origin/master when you are on your aq branch.

git checkout aq
git merge origin/master

Solution 3

First check out to master:

git checkout master

Do all changes, hotfix and commits and push your master.

Go back to your branch, 'aq', and merge master in it:

git checkout aq
git merge master

Your branch will be up-to-date with master. A good and basic example of merge is 3.2 Git Branching - Basic Branching and Merging.

Solution 4

There is no guarantee that the master bug fixes are not amongst other commits, hence you can't simply merge. Do

git checkout aq
git cherry-pick commit1
git cherry-pick commit2
git cherry-pick commit3
...

assuming those commits represent the bug fixes.

From now on though, keep bug fixes in a separate branch. You will be able to just

git merge hotfixes

when you want to roll them all into the regular dev branch.

Solution 5

This (from here) worked for me:

git checkout aq
git pull origin master
...
git push

Quoting:

git pull origin master fetches and merges the contents of the master branch with your branch and creates a merge commit. If there are any merge conflicts you'll be notified at this stage and you must resolve the merge commits before proceeding. When you are ready to push your local commits, including your new merge commit, to the remote server, run git push.

View more solutions

Comments

[Douglas F Shearer]

Merge isn't the ideal solution when you want to pull in changes from a parent branch. See the following for why rebase is better: stackoverflow.com/questions/457927/…

[Bombe]

If rebase is “better” depends completely on the specific situation.

[Slee]

can rebase come from any other branch? Ie. git rebase otherbranch? It seems I was a little off in my question, I branched from a branch then made changes to the original branch.

[Adam Dymitruk]

origin master may have commits besides the bug fix commits.

[Michael Küller]

why don't you just call "git merge master" instead of "git merge origin/master"?

[Foo Bar User]

If im right, rebase on the pull request it will show all the master commits. if you use merge/origin master all master commits will be shown as 1 commit, which it makes it easier for code review.

[garbagecollector]

Use rebase if your branch is local and hasn't been pushed to origin. Use merge if your branch is already pushed. rebase will rewrite history.

[erick2red]

Sometimes, git merge would be better. If both branches evolved over time, you should consider which is best for you.

[mtet88]

@Slee you answered yourself... it's not the solution for this situation

[Toskan]

why don't you just call "git merge master" instead of "git merge origin/master"?

[Chris Kooken]

@Toskan you can run into issues where your local master isn't up to date with the remote. This way it insures that you are merging in the remote copy of the code.

[ebuat3989]

Late to the party, but this is a great overview of when to rebase vs merge: atlassian.com/git/tutorials/merging-vs-rebasing/…

[Hanmant]

If your previous commits on branch aq are public then don't do rebase. atlassian.com/git/tutorials/rewriting-history/git-rebase

[Magne]

NB: This will copy the commits to the aq branch, but also still leave the commits on master, which I presume wasn't your intention. So you'd have to rollback master to the commit before the ones you wanted to move, for instance by using git stash then git reset --hard <SHA of last commit you want to keep>, and then git stash pop

[quasoft]

Here is one more thoughtful article on merging vs rebasing: kristopherwilson.com/2015/02/12/stop-merging-master

[cameck]

Make sure to checkout master, pull latest changes and then change to feature branch. I forgot to do that and kept wondering why my changes weren't applying :P

[nurettin]

@garbagecollector I am against rebase (I can, but won't rebase) I see no reason to gamble with rebase. It just makes things needlessly complex. You always have the question "Did I push this to remote?" to ponder and it is a pain to explain to newcomers. Some people say it avoids merge commits. But I want to have merge commits. They are not clutter, they document when branches are merged. So for the last time, can we finally stop acting like we are all committing to master? If you dislike merge commits in log so much, just filter them with --no-merges.

[Fabien Haddadi]

In the SVN world, we can specify date intervals. Is that the case in the Git world too? Let's suppose I am only interested in merging changes into my branch from master for the past 24 hours, how would I do this?

[Luis D Urraca]

if private branch and no one else see it, then use rebase, otherwise don't use it -> hackernoon.com/git-merge-vs-rebase-whats-the-diff-76413c1173‌​33

[guychouk]

Important to note that this solution is perfect if a merge is required specifically, that is, if the master branch cannot be rebased for some reason.

[MikeBeaton]

This is not doing what you think it is doing. git merge a b merges branches a and b into the current branch. But git merge a when you are on branch a will do nothing (which is why this looks a bit like it's doing what you think it's doing). (See git-scm.com/docs/git-merge#Documentation/… .)

[RedYeti]

Why no fast forward?

[kdperspective]

@MichaelKüller the only way ti avoid git merge origin/master would be to first do git checkout master and then do a git pull and then do git merge master. That way your local is in sync with remote master.

[Will Eccles]

It's worth noting that if someone else has a branch branched from yours (or changes otherwise linked to your existing history), rebasing will be a nightmare. If your branch is purely local, this will be fine, but be careful rewriting history which is already published!

[SherylHohman]

If you are not ready to merge aq into master yet, this cannot be a solution. Very important spokesperson if others are on your project. It also seems to defeat the purpose of a separate branch.

[MikeBeaton]

(Spokesperson? Autocorrect typo?) Anyway, this solution is about merging some changes from master into aq, as per the original question, so I'm not sure I understand the problem you're suggesting? Certainly, you could eventually merge aq later to master, after doing either of the above solutions I mention, and after then committing further changes to both - it would cause no issues.

[Carl Walsh]

If you don't git fetch this will merge in your local git repo's understanding of where origin/master -- which could be behind what's live on the remote. There's a reason that pull runs fetch before it run merge.