

Stop Branching Agile is soccer, not american football - mainguy
http://mikemainguy.blogspot.com/2011/11/stop-branching-agile-is-soccer-not.html

======
wccrawford
It totally depends on how you work. Agile isn't set in stone. That's why it's
named Agile.

For some, it's really nice to be able to try out an idea, and if it turns out
to be impossible, just trash the branch. The alternative is to have all that
mixed in with good code, and then try to undo the mess you've made and hope
you don't introduce bugs while doing it.

Sure, there are tools (like unit testing) to help you out if you go that way,
but it's still a lot cleaner to just trash a branch.

And some of us get projects that interrupt other projects. It's nice to be
able to set that code aside and work on something else for a bit, then come
back to it.

And finally... Just because we are branching doesn't mean we aren't sharing
that branch. Git makes that really easy, too.

------
waffle_ss
People working off of their own branches in complete isolation is probably not
a good thing, even if you aren't "agile". Also, non fast-forward merging
should only really happen between long-lived branches. Short-lived
experimental/feature branches should almost always be brought back to master
with a rebase. Otherwise you are cluttering up your git history with
unnecessary merges.

In the same vein, rebase should almost always be used when you are doing a
`git pull` to sync a branch up with master - e.g. `git pull --rebase origin
master`. You can set rebase to be the default pull strategy for newly created
branches in your .gitconfig like so:

    
    
      [branch]
         autosetuprebase = always

------
bernardwilson
This article : utter piffle.

