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?
Using git pullUse git pull to update a local repository from the corresponding remote repository. Ex: While working locally on master , execute git pull to update the local copy of master and update the other remote tracking branches. (More information on remote tracking branches in the next section.)
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.)
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With