Stop Branching Agile is soccer, not american football

It totally depends on how you work. Agile isn't set in stone. That's why it's named Agile.<p>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.<p>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.<p>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.<p>And finally... Just because we are branching doesn't mean we aren't sharing that branch. Git makes that really easy, too.

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.<p>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:<p><pre><code> [branch] autosetuprebase = always</code></pre>

This article : utter piffle.