The title of this article is intentionally provocative.

Git is a flexible tool that allows many kinds of workflow for using it. Here is the workflow I favour for teams:

• The master branch is meant to be always releasable.

• Every commit in master MUST pass the full test suite, though not all commits in merged change sets need to do that.

• Changes are done in dedicated branches, which get merged to master frequently - avoid long-lived branches, since they tend to result in much effort having to be spent on resolving merge conflicts.

  • If frequent merging is, for some reason, not an option, at least rebase the branch onto current master frequently: at least daily. This keeps conflicts fairly small.

• Before merging a branch into master, rebase it onto master and resolve any conflicts - also rebase the branch so it tells a clean story of the change.

  • git rebase -i master is a very powerful tool. Learn it.

  • A clean story doesn't have commits that fix mistakes earlier in the branch-to-be-merged, and introduces changes within the branch in chunks of a suitable size, and in an order that makes sense to the reader. Clean up "Fix typo in previous commit" type of commits.

• Update the NEWS file when merging into master. Also Debian packaging files, if those are included in the source tree.

• Tag releases using PGP signed, annotated tags. I use a tool called bumper, which updates NEWS, version.py, debian/changelog, tags a release, and updates the files again with with +git appended to version number.

  • Review, update NEWS, debian/changelog before running bumper to make sure they're up to date.

• Name branches and tags with a prefix foo/ where foo is your username, handle, or other identifier.

• If master is broken, fixing it has highest priority for the project.

• If there is a need for the project to support older releases, create a branch for each such, when needed, starting from the release's tag. Treat release branches as master for that release.