853

I have a branch called "dmgr2" in development, and I want to pull from the master branch (live site) and incorporate all the changes into my development branch. Is there a better way to do this?

Here is what I had planned on doing, after committing changes:

git checkout dmgr2
git pull origin master

This should pull the live changes into my development branch, or do I have this wrong?

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
Matthew Colley
  • 10,816
  • 9
  • 43
  • 63
  • 2
    first commit all your changes in dmgr2 branch. and then point to master 1.git checkout master and then get the latest change 2.git pull 3.git merge dmgr2 4.git push -u origin master And then go back to your dmgr2 5.git checkout dmgr2 – mat_vee Nov 20 '13 at 16:57
  • i have already committed all my changes to the dmgr2 branch, sorry forgot to add that – Matthew Colley Nov 20 '13 at 16:58
  • 6
    if i perform step 4, wont that push my development changes into master? i dont want to do that – Matthew Colley Nov 20 '13 at 17:17
  • So what you're saying is you want to bring the changes from your master branch, into your dev branch? – JcKelley Nov 20 '13 at 17:49
  • Based on the question, I think this should be a rebase not merge. The merge can occur after changes are reconciled. –  Sep 07 '14 at 11:55
  • 29
    Switch to `dev` branch with a `git checkout dev`. Then `git pull --rebase origin master`. If you are lucky, there will be no conflicts and dev will have the latest changes from master. – jww May 02 '16 at 12:06
  • This is not working for me. Can someone please help me explain? I'm getting this message `fatal: Need to specify how to reconcile divergent branches.` – amnesic Sep 13 '22 at 08:06

10 Answers10

1213

The steps you listed will work, but there's a longer way that gives you more options:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

The fetch command can be done at any point before the merge, i.e., you can swap the order of the fetch and the checkout, because fetch just goes over to the named remote (origin) and says to it: "gimme everything you have that I don't", i.e., all commits on all branches. They get copied to your repository, but named origin/branch for any branch named branch on the remote.

At this point you can use any viewer (git log, gitk, etc) to see "what they have" that you don't, and vice versa. Sometimes this is only useful for Warm Fuzzy Feelings ("ah, yes, that is in fact what I want") and sometimes it is useful for changing strategies entirely ("whoa, I don't want THAT stuff yet").

Finally, the merge command takes the given commit, which you can name as origin/master, and does whatever it takes to bring in that commit and its ancestors, to whatever branch you are on when you run the merge. You can insert --no-ff or --ff-only to prevent a fast-forward, or merge only if the result is a fast-forward, if you like.

When you use the sequence:

git checkout dmgr2
git pull origin master

the pull command instructs git to run git fetch, and then the moral equivalent of git merge origin/master. So this is almost the same as doing the two steps by hand, but there are some subtle differences that probably are not too concerning to you. (In particular the fetch step run by pull brings over only origin/master, and it does not update the ref in your repo:1 any new commits winds up referred-to only by the special FETCH_HEAD reference.)

If you use the more-explicit git fetch origin (then optionally look around) and then git merge origin/master sequence, you can also bring your own local master up to date with the remote, with only one fetch run across the network:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

for instance.


1This second part has been changed—I say "fixed"—in git 1.8.4, which now updates "remote branch" references opportunistically. (It was, as the release notes say, a deliberate design decision to skip the update, but it turns out that more people prefer that git update it. If you want the old remote-branch SHA-1, it defaults to being saved in, and thus recoverable from, the reflog. This also enables a new git 1.9/2.0 feature for finding upstream rebases.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • 42
    I'm just asking for a, uh, friend - how would you go about undoing the first code block you have here (checkout/fetch/merge)? – Rich Bradshaw Sep 17 '14 at 09:13
  • 11
    @RichBradshaw: `git checkout` is normally non-destructive and there's normally no reason to undo a `git fetch`, so it sounds like you're asking how to back out a merge commit. The answer is the same as for other commits: either `git reset` or `git revert`. For *unpublished* changes `git reset` is usually the best method; for changes others already have, `git revert` may be better, but see Linus Torvald's advice on reverting a merge: https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt – torek Sep 17 '14 at 16:15
  • How do you set which merge viewer program to use? – PositiveGuy Aug 10 '15 at 19:22
  • 2
    @WeDoTDD: I don't understand the question. There are a number of commands for viewing the commit graph (`gitk`, `git log --graph` with or without `--oneline`, and so on) and you can `git show` or `git show -m` a merge commit, or use `git diff`. In all of these cases, you're specifying the program as you enter the command on the command-line. – torek Aug 10 '15 at 20:02
  • Thanks for explanation, these subtleties with FETCH_HEAD refs (and possibly other issues which were unknown to me as a Git newbie) were the reasons why I hesitated to pull from a different branch. I always went the long way - `checkout, pull, checkout, merge`. But now I might give a try for straight `pull`. – JustAMartin Oct 01 '15 at 07:54
  • Your answer helps me get my job done, but I cannot say that totally understand what is happening for each command. Some day I hope I will. Some day I will understand git :) – steve Feb 19 '18 at 21:25
  • Tried this, tons of merge conflicts even on files I've not touched. Had to abort. Tried again with git merge branch (no origin) and it worked. *shrug* – Gringo Suave Aug 27 '18 at 22:58
  • 1
    @torek: tried your way of: git checkout branch and then git pull origin master, but it pulled all master changes as a single change which should be committed locally again, instead of pulling them with their commit history and messages, so after updating local master and switching to branch, "git rebase master" does the job with all conflicts to solve, and then I add to "git pull --rebase" and handle again all conflicts, and then git push origin branch to get all aligned. I guess there should be better way for it - am I right? – GM1 Feb 13 '19 at 10:20
  • @user10556443: you've definitely done something wrong here, because "my way" means: *never run `git pull` at all*. Instead, run `git fetch`, then—immediately or after looking with `git log`—run a second Git command that is *not* `git pull`. The idea here is to *forget that `git pull` exists* and stop using the verb "pull", so as to learn what Git does under the magic "pull" cover and hence understand *why* you got what you got. it's not that `git pull` is *wrong* (sometimes it's fine) but rather that people who run it don't see what Git is really doing and will get hit by these things. – torek Feb 13 '19 at 16:11
  • 1
    @torek: I agree the result I got is a tiresome process which forces me to handle repeating rebase & merge &... every time I want to get an update from master...But, the proposed way, which I admit is much easier, got all changes under a single uncommitted change at local branch without keeping master commit order/ history. I'll be glad to learn of better suggestion how to use "fetch" and keep track of master without the need to use "pull" etc. – GM1 Feb 13 '19 at 16:28
  • @user10556443 Unfortunately, if you want to use a rebase-oriented workflow rather than a merge-oriented one, there's no road to doing this without merge conflicts. The point of doing a `git merge` (instead of a `git rebase`) is to arrange for *future* work to start from the last success, rather than perpetually being "behind" and therefore having to re-resolve everything. Sometimes there's a good reason to avoid truly merging (or avoid it yet), in which case Git's "rerere" can be helpful (search for "git rerere"), but it's not a panacea. – torek Feb 13 '19 at 16:36
  • @torek: what would you expect to happen, in case as long as branch exist, I'll take "the merge way", and later rebase it back to master , when branch finishes its purpose? would all the pulled commits conflict or just fit in with original History tracked for them? – GM1 Feb 13 '19 at 17:00
  • @user10556443: branch names don't really matter much here. It's only *commits* that matter. Remember that `git rebase` *copies* commits, then abandons the originals in favor of the new copies. `git merge` (assuming it makes a true merge rather than doing a fast-forward not-a-merge) makes a new commit that remembers *two* existing previous commits. History *is* commits. Stop using the verb *pull*. Commits aren't *pulled*, they just exist (by hash ID) or don't exist. Commits don't conflict, commits are just commits. `git fetch` acquires commits that you didn't have before. – torek Feb 13 '19 at 17:26
  • @user10556443: You will probably benefit a lot by reading through the web site [Think Like (a) Git](http://think-like-a-git.net/), which gets into how commits form history, by being a directed acyclic graph. – torek Feb 13 '19 at 17:27
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/188396/discussion-between-user10556443-and-torek). – GM1 Feb 14 '19 at 08:08
  • 1
    For those who are wondering why this `git pull origin master` does not work, Github has renamed the `master` branch to `main`. So you should try `git pull origin main`. – Duke Caesar Apr 27 '22 at 04:56
46

Working in my local branch, I love to keep-up updates in the development branch named dev.

Usually, I prefer to use:

git fetch
git rebase origin/dev
the Tin Man
  • 158,662
  • 42
  • 215
  • 303
greenridinghood
  • 629
  • 5
  • 7
  • 42
    With the usual disclaimer that rebase should only be done if the local branch is local only, that is, have not been pushed anywhere as it rewrites history. – Locus Apr 24 '18 at 08:51
  • What would be the problem @Locus? – Veronica Nov 22 '20 at 11:52
  • 2
    I don't know what I was thinking when I wrote this comment, as it is stated pretty clearly in the answer that he's working on a local only branch. When you rebase a branch you change the hash for all your commits. Other people who have access to or have cloned your branch will have no way of knowing what you just did and will be using your old branch. I'm probably not qualified to answer your question, you can learn more about rewriting history [here](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History). – Locus Nov 23 '20 at 13:07
  • What will happen if a branch is not local and you use `rebase`? – vitaliis Aug 20 '21 at 17:33
  • 2
    @vitaliis Usually dev team or big dev companies, do not allow you to rewrite any history on remote branches. For example where I work, I am allowed to rewrite my own remote branch, the one I created and pushed as new. But if I try to checkout my colleague's remote branch (not dev or main/master) I might not have access to push --force (rebase - rewrite history) It's just a matter of company/team policy or regulations (financial institutions) – Xao Aug 16 '22 at 09:12
28

This worked for to get the latest code from master to my branch:

git rebase origin/master
the Tin Man
  • 158,662
  • 42
  • 215
  • 303
Pratik Gaurav
  • 661
  • 7
  • 8
24

If you're on feature-1 branch and you want to pull master -- (maybe to get the latest merged updates/reduce the chance of a merge conflicts), do:

git pull
git merge origin/master

Pulls master into your branch - Does not affect master!

This will pull anything that has gone into master into your branch since the two of you diverged.

It is fine to do this if your branch has already been made public, as it does not rewrite history.

Dr-Bracket
  • 4,299
  • 3
  • 20
  • 28
13

I have master updating and my branch updating, I want my branch to keep track of master with rebasing, to keep all history tracked properly. Let's call my branch Mybranch:

git checkout master
git pull --rebase
git checkout Mybranch
git rebase master
git push -f origin Mybranch

I need to resolve all conflicts with git mergetool, git rebase --continue, git rebase --skip and git add -u, according to the situation and git hints, until everything is solved.

Note: correction to last stage, in courtesy of Tzachi Cohen, using "-f" forces git to "update history" at server.

Now, the branch should be aligned with master and rebased, also with the remote updated, so at git log there are no "behind" or "ahead", and I just need to remove all local conflict *.orig files to keep the folder "clean".

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
GM1
  • 380
  • 3
  • 14
  • 2
    This answer is far simpler and did the job. There were 3 branches off master that were missing changes made in master. Followed these steps exactly and it worked. Thank you – Michael Jun 24 '21 at 11:19
5

You might want to use this if your histories doesn't match and want to merge it anyway:

git pull origin master --allow-unrelated-histories

See "The “fatal: refusing to merge unrelated histories” Git error" for more information.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
Mbs Yaswanth
  • 144
  • 2
  • 6
  • Please use more useful link text than "here". See "[Don’t use “click here” and other common hyperlink mistakes](https://medium.com/@heyoka/dont-use-click-here-f32f445d1021)" and "[6.1 Link text](https://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text)" for more information. – the Tin Man Feb 21 '22 at 19:55
5

If dev is clean and just want to update with main or master changes

  • git checkout dev
  • git pull origin <main or master>
  • git push origin dev
DR-MATTH
  • 121
  • 3
  • 5
1

This is my solution:

git checkout mybranch
git rebase master mybranch
git add .
git rebase --continue
git commit -a -m "test"
git pull
git push

Use git add . to stage your files.

Here is another solution for getting your master changes to your branch:

git checkout mybranch
git fetch origin
git merge origin/master

Your history of git is clear when you use rebase, but it is easier to use merge origin/master.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
keivan kashani
  • 1,263
  • 14
  • 15
  • 1
    What is the point in using rebase when merge origin/master is easier and retains the history ? – Kravitz Jan 23 '23 at 19:41
1
  1. First, fetch the code using:

    git fetch
    
  2. Then use:

    git rebase origin/dev
    
the Tin Man
  • 158,662
  • 42
  • 215
  • 303
  • 1
    Welcome to SO! Please read [answer] and its linked pages, along with "[How do I format my posts...](https://stackoverflow.com/help/formatting)" and "[How do I format my code blocks?](https://meta.stackexchange.com/questions/22186/)". – the Tin Man Feb 21 '22 at 19:52
0

The best way to doing this is

first go to master/origin

git checkout master/origin

First run " git branch temp"
then "git checkout temp"
& then "git merge development"

if any conflicts come, please resolve & commit 
and then 
1. git checkout development
2. git merge temp

After doing this all run to check

git branch 

if the result is development

if not then run

git checkout development

now you are on development branch

and you can run

git merge temp

Now you can get your master branch code into development.