

Agile Git Workflow - twampss
http://geewax.org/2009/11/21/agile-git-workflow.html

======
timtadh
I have to completely disagree with rebasing the feature branch onto the
mainline branch. That is bad idea. Here is what they are doing:

    
    
       1.  Branch off of master to work on the feature
       2. Work, work, work, commit, commit, commit
       3. Pull down any updates to master
       4. Rebase and squash the feature branch to master’s HEAD
       5. Merge the feature branch back to master
       6. Push up to the shared repository
    

Their Rational for Step 6:

"When you’re ready to share this feature with the rest of your team, they
probably won’t care about all your interim commits (for example, you added and
then changed feature.py). We can package up all the commits into one big
commit (sort of like the one big patch against master you used before) by
using git’s rebase command."

Some of the history that was used in developing the feature may be useful for
someone else trying to a) figure out how the code works or b) trying to fix a
bug in the program. By chunking the development of the feature into on patch
you eliminate the nuances which would have helped later on.

Even beyond the development concerns, version control systems have great power
to model your actual development process. Not just the one that is on paper,
but the one that produces the code which ships. By eliminating history of
development you loose the ability to discover this useful information. So
don't rebase your feature branch merge into the mainline.

~~~
dschobel
I disagree with your disagreement. Rebasing/squashing can really help clean up
the development history and actually make it a ton more useful as a historical
reference.

Like all things in programming, discretion is key and obviously it can be
overdone, but anecdotally, I've found that it makes the history so much more
useful to lump related changesets together.

In short, categoricals like "don't do it, you'll lose history" don't really
hold much water for me. _Of course_ it can be over done. But done right, it
really is a great feature of git and a god-send on larger projects (check out
the actual git source log for an example).

~~~
icefox
I would have to second this. I will almost always squash (or split) commits in
a branch before review to have it merged back into the master branch. I try to
have each commit do a specific individual task. While adding docs to the api
could be a separate function (just because you did it last) I would rather
have that squashed so in two years when you are looking at the new function
you see the api docs that go with it. This doesn't mean everything should be
in 1 commit and it also doesn't mean 30 commits. Common sense plays a big role
here.

------
jorgem
Can someone translate this into Mercurial? Thanks.

