5

Consider I am on master and I have remote branch develop on my remote named origin, everything is up-to-date, I have already runned git fetch.

Now is there any difference between git merge origin/develop and git pull origin develop ?

Aram810
  • 619
  • 7
  • 21

3 Answers3

7

Pull is a fetch + merge, and you explicitly merging from a remote *tracked branch, so there is no difference, even without the fetch.

if you give me a -1, at least comment what is your problem with my answer

MrKekson
  • 720
  • 6
  • 18
  • 1
    Without fetch there is difference, because I am merging with `origin/develop`, but without fetch `origin/develop` reference may not be up to date. From other side `git pull origin develop` will always merge with updated `origin/develop`. – Aram810 Apr 27 '20 at 18:24
4

Given the constraints you specified, and assuming that no one has changed anything on the remote since your git fetch, the only difference is that the default commit message will be different. One will say merge branch 'origin/develop' and the other will say merge branch 'develop' of 'url'. If you provide or write your own merge message, there is no detectable difference at all.

(The hash ID of the resulting merge commit will depend on the time so if you try this yourself you are likely to get two different commits, unless you can do both within a single second. However, the hash ID of a future commit is effectively impossible to predict: you need to know what will be in it, including the timestamps.)

torek
  • 448,244
  • 59
  • 642
  • 775
3

I would note that origin/develop is not a branch; so the question seems more like "difference between git merge remote-tracking-ref and git pull remote branch" ...

I guess we can start with the simple but trivial: At a bare minimum, the default commit message will be different. But you probably don't care about that; most people pretty much ignore merge commit messages.

Beyond that, the question comes down to what assumptions are making.

To suppose that the commands are equivalent, we have to suppose a default configuration; because some config settings change what pull does. (For example, pull can be configured to rebase local changes instead of merging.)

It sounds like you want to assume that your local tracking ref and the remote branch both point to the same commit. That's generally an iffy assumption, because even though you "just did a fetch", that doesn't preclude someone else doing a push before you do your next command.

That said, it doesn't really matter. All that means is, if you do a merge you might end up behind (if someone happened to push right after your fetch); and it's not like doing a pull is any better, because someone might do a push right after your pull... so if the world is out to get you, nothing you do will guarantee that nothing is in origin beyond what you have locally.

In fact, I'd say that if you just did a fetch, you're better off doing the merge instead of the pull, because the pull will do another fetch that doesn't make much practical difference.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • origin/develop is a branch tho. You just explicitly saying that the part behind the first/ is on a remote called origin. screencap: https://imgur.com/a/osR4UAD – MrKekson Apr 26 '18 at 15:20
  • @MrKekson : No, it isn't. It's a remote tracking ref, which is *not* the same as a branch. If you think it's a branch, try `git checkout origin/develop` and see if you don't end up in detached HEAD. (btw, not sure why you think your screen cap is relevant...) – Mark Adelsberger Apr 26 '18 at 16:00
  • 1
    This gets into the question of defining *branch:* see http://stackoverflow.com/questions/25068543/what-exactly-do-we-mean-by-branch. If you define *branch* as *name within `refs/heads/`* then a remote-tracking name is not a branch. If you define it as the string of commits identified by a branch name, then `refs/heads/master` is not a branch either! – torek Apr 26 '18 at 16:29
  • 1
    @torek - Not sure which of us you were replying to; but for the record, I would think the most useful definition of branch is "ref that you can check out, and having done so can make a commit to automatically advance the ref", that being the definition the git docs seem to use... which is practically equivalent to "within `refs/heads/`" afaik – Mark Adelsberger Apr 26 '18 at 16:38
  • Both, really. There's *how you get Git to do X* (for some *X*) and then there's the question of *How do we talk about doing X? What do we mean when we use the word Y? How do we communicate ideas between individuals?* These philosophical questions are either really interesting, or totally pointless, depending on your point of view. But then we get into questions of point of view ... and, uh, is it just me, or is it getting solipsistic in here? :-) – torek Apr 26 '18 at 16:41
  • @torek - Well, I try not to apply my thoughts on linguistics to technical matters, because a prescriptive approach to technical terminology seems somewhat necessary. (I don't care to be the guy who decides that common usage has redefined what a volt is when working on my house wiring...) Yes, people *use* branch to mean things like "path of commits" or "ref that kinda looks like a branch"; and I spend a lot of time typing answers that assert they are mistaken... – Mark Adelsberger Apr 26 '18 at 16:54