All,
We noticed lately that an increasing number of
git merges is happening in the Drools/jBPM codebase. Git
merges can be easily identified in the "network" graph in
github repo, or by using any other Git client tool, as
parallel lines in the branch history. E.g.:
Please note that each and every merge, while
not a big problem by itself, increases the risk of overriding
code changes (i.e., losing code) as well as increases future
maintenance cost. If you want know more about it, feel free to
ask, or just trust me on this... :)
Git offers an alternative to merges in the form
of "rebase". Rebase enables developers to commit code on top
of the most recent change in the branch, instead of in
parallel to it. It guarantees no code will be lost when doing
that, and makes it easier to maintain code in the future. If
you don't know how to rebase code, please read one of the many
git books/documentation available on line, like:
Also feel free to ask and I will be happy to
help.
There is just one case where rebase can not be used:
* You should NEVER rebase a commit that was
published to a public repository before.
Also, the github pull request "merge" button
uses merge instead of rebase. While it is very quick and easy
for a developer to click on that button, please note that it
introduces merges, and at the same time commits code that was
not tested by the person doing the merge. It is acceptable for
small code fixes, but for anything larger than a few lines of
code changes, you should pull the changes into your machine
rebasing them, run the tests to make sure they are still clean
and only after that push the PR changes to the public repo.
Please be aware of that and try to minimize
merges by using rebase whenever possible.
Thanks,
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com