Git rebase ignoring same changed lines

Question

I had a weird issue with git rebase I’m trying to understand. Another developer and me are working on the same project, both pushing/pulling from develop branch. We are working on the same files so we expect some conflicts to arise when pushing/pulling from git.

So what we do is:

1. My colleague commits and pushes all his changes first.
2. I commit my changes as well but, before pushing, I pull from the repo to get the new updates. The pull finishes with no conflicts. I’m a bit surprised but I think it’s just luck we didn’t modify the same exact lines.
3. After that I push my commit doing a git rebase, with no errors or whatsoever.

We’re perfectly happy with the operation until we realise there are some lines that were commented in my version but not in my colleague’s. As my version was the last one pushed, the lines remain commented on the repo.

Why git didn’t complain about the same line being different in each version? I know git notices comments and marks them as changes. Is it because I rebased instead of doing a merge-commit? Can anyone help me understand what happened? I'm afraid of this kind of changes going unnoticed and leading to errors later on the project.

Answer 1

Your git flow is wrong, two things here:

1) Never use git rebase (or other commands that modify the history) on public branches. It is OK to create the branch, do some work on it, rebase and push it, but don't do the rebase when it is already pushed and used by other people.

2) You're probably coming from something like svn and got used to work on a single branch. Git has lightweight branches and it is better to create new branch for every change:

• Never commit directly to the master branch, it will be your integration branch which puts finished features together
• Create a new branch for each new feature and do the development there
• Once feature is done, review the change: if it is good, merge it to master
  • If there are conflicts then revert the merge (or if you use github, it will not allow you to merge it)
  • Merge master back to your branch
  • Resolve conflicts
  • Push the final branch version

3) Don't use GUI clients for anything except the history browsing

Why you should never rebase public branches

Let's imagine the following situation: there is a branch named feature created from the master.

Both you and your colleague have this branch and work on it (that's what I mean by "public" branch).

1) You and colleague have a feature branch

... O ---- O ---- A ---- B      origin/master
                   \
                    ----        origin/feature
                     \
                      --- C     your/feature
                      \
                       \-- D    colleague/feature

2) You rebase your feature branch on top of master.

Note that we changed the history and have new C' commit on the your/feature branch and it is not derived from the origin/feature anymore:

... O ---- O ---- A ---- B ---         origin/master
                   \     \
                    ---   \            origin/feature
                     \     \
                      \     --- C'     your/feature
                       \
                        \-- D          colleague/feature

3) Now you have a branch which isn't related to the origin/feature and colleague/feature. It is like if you created a new branch and moved your changes onto it.

If you try to to push your feature branch back to the origin repository, git will tell you that branches have diverged.

You still can use --force to push it and the history will be this:

... O ---- O ---- A ---- B ---         origin/master
                   \     \
                    \     \       /--  origin/feature
                     \     \     /
                      \     --- C' --  your/feature
                       \
                        \-- D          colleague/feature

See what happened?

Now your colleague's branch is disconnected from yours and origin, so he will have problems pushing / pulling the changes.

At this point he can try to use --force and overwrite your variant of the feature branch.

This way you can end up losing some changes. Well, nothing is really lost and can be restored, but it may be complex to deal with such situations.