The Benefit of Rebasing

Consider the following situation: you have got the develop branch from the remote repository. You start to implement your new feature but other devloper do the same. Sometimes they are faster than you and push their changes to the remote develop branch before you do. You have a problem: is there a conflict between their work and your's?

In this situation you would consider it a big advantage, if you had started your work after the other developers had pushed their changes. Thus you may ask the question: when I would apply my changes (i.e. my commits) on top of the actual develop branch, do conflicts arise or are my changes and the changes of the others compatible?

Exactly this question is answered by the command "git rebase develop". You are working in your branch "myFeature". Git returns to a common ancestor commit of both branches (that must exist, you departed from develop in the past!), saves all changes you have committed in your branch "myFeature" starting from that ancestor. Then it takes the actual branch "develop" and applies your changes one after the other. There are two outcomes:

• you didn't change resources that the other developers changed and the other developers didn't change resources you changed.

• you are lucky, nothing to do. Git says "fast forward" to express that. Fine.

• other developers and you changed the same resource, Git complains about a conflict. Fine too, but work.

• use a merge-tool (e.g. that builtin into eclipse) to solve the conflict by copying, ignoring or editing the resources one after the other, then commit your edit. This will complete the rebase. You have solved the problem.

In both cases your branch now originates from the current develop. If you have rebased, do not forget to run all tests!