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?

In the future, you could also start your bugfix branch from a common ancestor of master and other branches that will need the fixes, so that you can merge it into all of those branches, without picking anything else up. — Cascabel, Mar 17 '11 at 18:11
@Jefromi but that's out of his control if he's not the sole person working on the project. other people update the master. hell, you yourself may update the master from a third branch, and the situation would be unavoidable, and in need of a general solution. — ahnbizcad, Apr 09 '15 at 16:19
@ahnbizcad I'm pretty sure he's in control of where he starts his own branch. If his branch is a common ancestor of the ones he'll want to merge into, and people subsequently add to those branches, it'll still be a common ancestor. — Cascabel, Apr 09 '15 at 16:20
guys question, does this command do it, `git pull origin my_branch_name` — Basheer AL-MOMANI, Oct 16 '17 at 12:09

score 1090 · Accepted Answer · edited Jul 05 '16 at 16:06

1090

Check out the aq branch, and rebase from master.

git checkout aq
git rebase master

edited Jul 05 '16 at 16:06

Peter Mortensen

30,738
21
105
131

answered Mar 17 '11 at 14:54

Douglas F Shearer

25,952
2
48
48

2

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. – Slee Mar 17 '11 at 15:39
4

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. – Foo Bar User Jan 30 '14 at 10:19
4

Sometimes, `git merge` would be better. If both branches evolved over time, you should consider which is best for you. – erick2red May 25 '15 at 15:48
100

Late to the party, but this is a great overview of when to rebase vs merge: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/workflow-walkthrough – bogeylicious Dec 12 '15 at 01:06
9

If your previous commits on branch aq are public then don't do rebase. https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase – Hanmant Jan 12 '17 at 06:54
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 `, and then `git stash pop` – Magne Feb 15 '17 at 08:39
Here is one more thoughtful article on merging vs rebasing: http://kristopherwilson.com/2015/02/12/stop-merging-master/ – quasoft Jul 09 '17 at 12:52
1

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 – cameck Feb 23 '18 at 19:42
if private branch and no one else see it, then use rebase, otherwise don't use it -> https://hackernoon.com/git-merge-vs-rebase-whats-the-diff-76413c117333 – Eric Labashosky Nov 01 '19 at 11:56

score 418 · Answer 2 · answered Mar 17 '11 at 14:54

418

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

git checkout aq
git merge origin/master

answered Mar 17 '11 at 14:54

Chris Kooken

32,730
15
85
123

3

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: http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions – Douglas F Shearer Mar 17 '11 at 15:00
63

If rebase is “better” depends completely on the specific situation. – Bombe Mar 17 '11 at 15:01
1

origin master may have commits besides the bug fix commits. – Adam Dymitruk Mar 17 '11 at 22:08
19

why don't you just call "git merge master" instead of "git merge origin/master"? – Michael Küller Oct 02 '13 at 15:56
210

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. – garbagecollector Apr 24 '14 at 19:49
3

why don't you just call "git merge master" instead of "git merge origin/master"? – Toskan Aug 13 '15 at 01:13
22

@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. – Chris Kooken Aug 13 '15 at 17:55
15

@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. – nurettin Apr 18 '18 at 06:19
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? – Fabien Haddadi Jan 29 '19 at 02:00
@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. – kdperspective Jul 23 '20 at 11:25
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`. – Carl Walsh Feb 04 '22 at 22:15

score 134 · Answer 3 · edited Jul 05 '16 at 16:10

134

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.

edited Jul 05 '16 at 16:10

Peter Mortensen

30,738
21
105
131

answered Aug 21 '14 at 16:33

Hrishikesh Mishra

3,295
3
27
33

score 37 · Answer 4 · edited Jan 16 '18 at 18:05

37

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.

edited Jan 16 '18 at 18:05

Cameron Clough

547
6
15

answered Mar 17 '11 at 22:07

Adam Dymitruk

124,556
26
146
141

Thank you, I'll steal your tip, and use from now on. I like this idea of bug fixes in a separate branch. Although, I'd maybe wanna separate out any bug fixes, known to cause more bugs (if possible) – Harsh Oct 07 '22 at 04:51

hestellezg · Answer 5 · 2019-12-11T19:34:37.263

30

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.

edited Dec 11 '19 at 19:34

answered Sep 26 '19 at 15:14

hestellezg

3,309
3
33
37

1

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. – guychouk Dec 14 '19 at 23:55

score 22 · Answer 6 · answered Apr 10 '18 at 02:24

22

Merge it with aq

git checkout master
git pull
git checkout aq
git merge --no-ff master
git push

answered Apr 10 '18 at 02:24

alditis

4,633
3
49
76

7

Why no fast forward? – RedYeti Jul 06 '20 at 13:52

score 21 · Answer 7 · answered May 15 '20 at 06:10

Scenario :

I created a branch from master say branch-1 and pulled it to my local.
My Friend created a branch from master say branch-2.
He committed some code changes to master.
Now I want to take those changes from master branch to my local branch.

Solution

git stash // to save all existing changes in local branch
git checkout master // Switch to master branch from branch-1
git pull // take changes from the master
git checkout branch-1 // switchback to your own branch
git rebase master // merge all the changes and move you git head  forward
git stash apply // reapply all you saved changes

You can find conflicts on your file after executing "git stash apply". You need to fix it manually and now you are ready to push.

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! — Will Eccles, Sep 23 '21 at 19:05

score 16 · Answer 8 · answered Mar 17 '11 at 14:54

16

Either cherry-pick the relevant commits into branch aq or merge branch master into branch aq.

answered Mar 17 '11 at 14:54

Alan Haggai Alavi

72,802
19
102
127

6

@Slee you answered yourself... it's not the solution for this situation – mtet88 Jun 30 '15 at 14:30

Alen Lee · Answer 9 · 2019-03-18T06:04:17.753

9

Easy way

# 1. Create a new remote branch A base on last master
# 2. Checkout A
# 3. Merge aq to A

edited Mar 18 '19 at 06:04

answered May 19 '17 at 10:06

Alen Lee

2,479
2
21
30

score 8 · Answer 10 · answered Jul 06 '16 at 12:12

For me, I had changes already in place and I wanted the latest from the base branch. I was unable to do rebase, and cherry-pick would have taken forever, so I did the following:

git fetch origin <base branch name>  
git merge FETCH_HEAD

so in this case:

git fetch origin master  
git merge FETCH_HEAD

MikeBeaton · Answer 11 · 2020-02-18T11:59:42.760

EDIT:

My answer below documents a way to merge master into aq, where if you view the details of the merge it lists the changes made on aq prior to the merge, not the changes made on master. I've realised that that probably isn't what you want, even if you think it is!

Just:

git checkout aq
git merge master

is fine.

Yes, this simple merge will show that the changes from master were made to aq at that point, not the other way round; but that is okay – since that is what did happen! Later on, when you finally merge your branch into master, that is when a merge will finally show all your changes as made to master (which is exactly what you want, and is the commit where people are going to expect to find that info anyway).

I've checked and the approach below also shows exactly the same changes (all the changes made on aq since the original split between aq and master) as the normal approach above, when you finally merge everything back to master. So I think its only real disadvantage (apart from being over-complex and non-standard... :-/ ) is that if you wind back n recent changes with git reset --hard HEAD~<n> and this goes past the merge, then the version below rolls back down the 'wrong' branch, which you have to fix up by hand (e.g. with git reflog & git reset --hard [sha]).

[So, what I previously thought was that:]

There is a problem with:

git checkout aq
git merge master

because the changes shown in the merge commit (e.g. if you look now or later in Github, Bitbucket or your favourite local git history viewer) are the changes made on master, which may well not be what you want.

On the other hand

git checkout master
git merge aq

shows the changes made in aq, which probably is what you want. (Or, at least, it's often what I want!) But the merge showing the right changes is on the wrong branch!

How to cope?!

The full process, ending up with a merge commit showing the changes made on aq (as per the second merge above), but with the merge affecting the aq branch, is:

git checkout master
git merge aq
git checkout aq
git merge master
git checkout master
git reset --hard HEAD~1
git checkout aq

This: merges aq onto master, fast-forwards that same merge onto aq, undoes it on master, and puts you back on aq again!

I feel like I'm missing something - this seems to be something you'd obviously want, and something that's hard to do.

Also, rebase is NOT equivalent. It loses the timestamps and identity of the commits made on aq, which is also not what I want.

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. — SherylHohman, Nov 12 '21 at 13:28
(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. — MikeBeaton, Nov 13 '21 at 16:31

score 3 · Answer 12 · answered Jan 27 '17 at 23:12

You have a couple options. git rebase master aqonto the branch which will keep the commit names, but DO NOT REBASE if this is a remote branch. You can git merge master aq if you don't care about keeping the commit names. If you want to keep the commit names and it is a remote branch git cherry-pick <commit hash> the commits onto your branch.

score 1 · Answer 13 · answered Nov 04 '19 at 22:19

1

You can also do this by running a single line.
git merge aq master

This is equivalent to

git checkout aq
git merge master

answered Nov 04 '19 at 22:19

prafi

920
9
11

1

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 https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-ltcommitgt82308203 .) – MikeBeaton Feb 18 '20 at 09:22

score -1 · Answer 14 · answered Mar 30 '23 at 05:36

1.git stash - apply this when you have uncommitted changes
2.git checkout master 
3.git pull 
4.git checkout branch1 (branch1 - Your working branch)
5.git rebase master 
6.git stash apply - apply whether you stashed uncommitted changes

You might find merging conflicts after applying stashes. Solve it manually

Get changes from master into branch in Git

14 Answers14

Linked

Related