On Thu, 13 Jun 2013 11:00:42 -0400
Paul Smith <p...@mad-scientist.net> wrote:
> Hi all. This is just a simple question. Most of the discussions of
> "merge from master to my branch" I've seen recommend this:
> git checkout master
> git pull
> git checkout <mybranch>
> git merge master
> I did things this way at first, but as I understood git more it seemed
> to me that far simpler, and completely equivalent (with the exception
> that the master branch is not updated, which is fine) would be:
> git fetch
> git merge origin/master
> Is there some downside to this alternative that I'm not seeing, or
> other consideration (philosophical or otherwise) that should be taken?
If you have a local branch named "master" which is set to track
"origin/master", the second sequence won't update it because `git pull`
in the first sequence does fetching *and* then merging of what was
fetched into the currently checked out branch -- "master".
Note that you might as well be *not* interesting in having such a local
"master" branch at all! For instance, if you intend to contribute to
someone else's project, and forked a local branch "my-feature" off that
repo's "master" branch, you might freely go on with the approach you
asked about -- that is, fetch from the remote periodically and then --
at key times -- integrate the updated remote's "master" branch into
your local branch. But note that in this particular case you might be
interested in periodical rebasing your local branch instead.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.