[rules-dev] IMPORTANT: git merges

Cristiano Gavião cvgaviao at gmail.com
Thu May 9 19:12:51 EDT 2013


Hi, just to complement what Edson stated, I would like to recommend this
article. it is very instructive:

http://randyfay.com/content/rebase-workflow-git

and read the comments too because there are a good example with figures
there.

regards,

Cristiano


2013/4/25 Edson Tirelli <ed.tirelli at gmail.com>

>
>    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.:
>
> https://github.com/droolsjbpm/droolsjbpm-knowledge/network
>
>    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:
>
> http://git-scm.com/book
>
>    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
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
"Tudo vale a pena se a alma não é pequena..."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20130509/3e834ce9/attachment.html 


More information about the rules-dev mailing list