git pull from master into the development branch

Question

I have a branch called dmgr2 (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?

Answer 1

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

git checkout dmgr2 # you have reached and are currently into  " branch dmgr2"

git fetch origin # gets you up to date with the 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 traced to your repository, but named origin/branch for any branch named branch on the remote.

At this point, you can use any viewer like 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 1 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.

Answer 2

When you do a git pull origin master from your dmgr2 branch, you'll pick up changes from master. Here's what you need to know:

Switch to your development branch, dmgr2

Code:

git checkout dmgr2

Fetch and merge changes from master into dmgr2

Code:

git pull origin master.

When Git finds conflicts, it will ask you to resolve the conflicts. Once all conflicts have been resolved, stage files by using git add, and finally complete the merge by committing changes with git commit.

Check and Test:

Merge result should be checked in the development environment for correctness.

Alternative: git fetch + git merge

A second approach is to break the pull into two steps (optional, but useful for review):

Code:

git fetch origin master

git merge origin/master

This will enable you to fetch changes but won't merge them in automatically. This means that you can review first then merge.

Actually, both do the trick. Your original plan (in dmgr2, that is: git pull origin master) to pull live changes into your development branch is good.