GIT fecth and rebase

Question

I am new to GIT and not able to understand how the second rebase command resulted in merge issue:

$ git rebase origin/develop
Current branch feature/featurename is up to date.

$ git fetch
remote: Microsoft (R) Visual Studio (R) Team Services
remote: We noticed you're using an older version of Git. For the best experience, upgrade to a newer version.
remote: Found 50 objects to send. (31 ms)
Unpacking objects: 100% (50/50), done.
From https://.....
   df825005..000000cf  develop          -> origin/develop

$ git rebase origin/develop
First, rewinding head to replay your work on top of it...
Applying: .....
C:/work/.../rebase-apply/patch:61: trailing whitespace
Using index info to reconstruct a base tree...
M       br/br
Falling back to patching base and 3-way merge...
Auto-merging case/TTest.cpp
 CONFLICT (submodule): Merge conflict in br/br

I understand that both rebase and fetch will refer to origin/develop however I do have a 'set-upstream' branch in our VSTS (build system) - so did the fetch fetched from my feature branch in VSTS?

Answer 1

I understand that both rebase and fetch will refer to origin/develop ...

This isn't quite right.

What git fetch does is connect your Git (which has an independent copy of all of its commits—your own commits and everyone else's commits as of the last time you connected your Git to all the other Gits you connect-to)—to some other Git.

The other Git may have commits that you don't. If so, your Git asks their Git for the commits that they have, that you don't. They hand over their commits-that-they-have-that-you-don't; your Git stores those commits permanently, in your repository, under their hash IDs; and then your Git records, for your usage, which commits are their tip commits. That is, they have a branch named develop. You just got a listing, from them, of what commit hash their develop names. But you may well have your own branch named develop, so your Git does not touch your develop at all. Instead, it just updates your memory of their develop, which your Git calls origin/develop.

When you run git rebase origin/develop, your Git does not call up another Git, it just looks at your saved memory in your own origin/develop. So your first git rebase did nothing as the memory you had of their develop, stored in your origin/develop, did not require doing anything. Then you ran git fetch, which obtained new commits from their Git and updated your memory of their develop by updating your origin/develop. Then your second git rebase looked at your updated memory, found that there was something to do, did it, and that process resulted in the merge conflict you saw.

Answer 2

Git just told you in its output what happened:

Current branch feature/featurename is up to date.

This means that, at the moment, before fetch, your branch indeed is based on origin/development. So your history looks something like this:

  feature/featurename
      /
-o---o
  \
  origin/development

Now you called the git fetch command which checks if there were new commits pushed to the remote repository. Turns out, there were, and git informs you what was changed with the message:

From https://.....
   df825005..000000cf  develop          -> origin/develop

This means that branch develop on the remote repository https://..... moved from df825005 to 000000cf (nice hash, btw), so your remote branch origin/develop was updated accordingly. Now your history looks like this:

  feature/featurename
      /
-o---o
  \
    --o <- origin/development

The branch feature/featurename is no longer based on top of origin/development, so when you run rebase you have to go through the whole process (branch no longer up to date and no fast-forward possible)

First, rewinding head to replay your work on top of it...

This is a preparation step for doing a rebase - HEAD is put at the top of the origin/develop branch as it will now try to put your commits there.

Applying: .....

Here was the name of the commit git is now applying where HEAD is. Right now its the top of the origin/develop but if you had more commits to be rebased it would move forward, obviously.

Falling back to patching base and 3-way merge...

Git failed to automatically apply your commit, as there were files modified both in your commit and in the origin/develop branch. So now git will have to do...

Auto-merging case/TTest.cpp

The clever git alghoritms might avoid conflicts in this file so it will try to automerge it

CONFLICT (submodule): Merge conflict in br/br

No luck! Unfortunately, git wasn't able to automerge the file and has left you with this responsibility. You either have some exotic version of git, or you've trimmed the output, but git will usually include one more very helpful line:

When you have resolved this problem, run "git rebase --continue".

So now all you have to do is resolve the conflict in the usual way, and once you're done, do git rebase --continue. Now git will try to apply the next commit, if there are any left.

I strongly recommend reading a tutorial of your choice about git - it seems like you are highly confused about the very fundamental concepts of git, which are very different from version control systems like svn