If you git rebase and push, vs if you git pull, merge, and push, does it help the project maintainer the work of merging?
It is said that if we don't git rebase, the project maintainer person may ask you to rebase your changes (say, the bugfix1122-branch) to the tip of the master or development branch.
But does it save the project maintainer's time for merging it? I thought either we git pull, merge, and push, we also merge it, so the project maintainer doesn't have to. Is that true? Is rebasing mainly to flatten the history, like flattening a tree to a linear structure, so that the git history is more linear?
Yes, rebasing a branch onto master and merging master in before opening a Pull Request have the same effect, as far as helping the project maintainer with the merge goes.
You are right in saying that rebasing is mainly done to flatten history. However, there's a special case in which I believe it outperforms a merge: when you have conflicts. A rebase will force you to fix conflicts as the commits are applied, so that the conflict resolution won't be seen by the maintainer of the project. A merge, on the other hand, will force you to resolve conflicts all at once, creating a merge commit as a result, which can make things harder to understand for the maintainer.
That being said, this becomes less of problem if GitHub is being used, as it allows the maintainer to review changes rather than reviewing commits. Personally, I like to review commits, that's why I prefer to rebase. In the end, it all comes down to what the maintainer prefers, so look for instructions in the CONTRIBUTING.md file (if available) before opening the Pull Request.
Asked in February 2016Viewed 3,891 timesVoted 12Answered 1 times