Git: Are MERGING master into feature branch and REBASING feature branch on master equivalent?

Question

Does merging master into a feature branch and rebasing feature branch on master have same end result in every possible situation, or should I favor one or other in a specific context and why? I know merging creates additional commit for better history comprehension, but I'm more interested in the actual outcome of an operation and it's probability to succeed. So is there an actual difference, or could I choose either approach based on convention (or even use them both inclusive)?

Also, how often should I need to sync feature branch with master ? Is it a good practice to merge/rebase every time I return to develop a specific feature, or should I keep the feature isolated from the rest of the architecture for as long as possible?

How to scope with situation when multiple features are highly dependent of each other? Should the features be developed as a single feature branch, or as a distinct feature branches merged to public feature branch? Lets say, in Spring framework , many configurations and layers are dependent of each other. What is the common workflow to keep it all whole and sync?

Answer 1

Both merging and rebasing solve the same problem in a very different way. Unlike rebasing, merging is non-destructive. However, as long as you follow the Golden Rule of Rebasing, everything will work fine, and you can enjoy having a neat commit history. The rule is "don't use rebasing with public branches."

Also, how often should I need to sync feature branch with master?

This is mostly a matter of taste. As explained in Pro Git , there are different Branching Workflows that one can choose from.

Answer 2

Rebasing and merging are not equal in all situations as when you rebase on master you are actually make new commits on top of master, which will have a different id and contents. This is why it is important to not rebase public branches. However, rebasing can give you a nice clean history.

As for the branch section of the question: it appears that what you are looking for is a branching model. One of the most popular branching model is git flow which uses a merge model.

http://nvie.com/posts/a-successful-git-branching-model/

The essence of the git flow model is the use of master, release, develop, and feature branches (among others) to organise the state that your code is in. With this model it should be easy to tell when to merge, as it will be at certain stages, for example: a feature is complete or you are going to do your next release.