[rules-dev] GIT: lesson learned when working on a big task

[Edson Tirelli]

   All, just to share something I recently realized (although in hindsight
might be obvious).

   As everybody knows, everyone working in a project with GIT, should be
using a cloned repository, and only push to the blessed repository when it
is safe. Even more than that, working on a branch created specifically for
your feature makes things a lot easier, specially to send pull requests.

   The problem is that when you are working on a large feature with many
commits, for several weeks in a row, you have to keep rebasing your work on
top of master so that you can be sure your code includes the work of
everybody else. But when you are rebasing like 30+ commits (my case with
the serialization work), each commit representing one step on your changes,
it is possible that each rebase will cause many conflicts.... even worse,
the same file will probably cause several conflicts during a single rebase.

   The solution to the problem is actually very simple... when you
accumulate several commits and you start having problems with rebase, just
squash all your commits into a single commit. This way your new single
commit will contain the whole change, and not a sequence of small changes.
More than that, the change will be consistent with the HEAD of the
branch/master at the time you do it and once you resolve any eventual
conflicts, you will not need to resolve them anymore in future rebases.

   The ProGIT book shows you how to do this [1], but please remember the
golden rule:

"NEVER EVER REBASE COMMITS THAT YOU PUSHED TO THE BLESSED REPOSITORY"

   Just thought it was worth sharing.

[1] http://progit.org/book/ch6-4.html

   Edson

-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120319/a9ece184/attachment.html