I really like git-flow (http://nvie.com/posts/a-successful-git-branching-model/). I first used it nearly three years ago, and with a team of, for the first cut of the software, only two people. It actually works quite well. The most important thing about git-flow -- or any git workflow -- is how it partitions changes to your code logically. The primary benefit of these partitions to code changes is, I think, the reduction of production code churn, though this "firewalled churn" provides benefits all the way back to your develop branch, which is thankfully protected from wacky coder changes in each of their (my?!) feature branches.

In a sense, you have three protected sections:
1.) The wild west of feature branches, delineated by the develop/nightly branch,
2.) The staging environment, bordered by, in git-flow, the master-as-production branch, and
3.) The "pristine" production deploy, a sort of "one-dimensional"/breadthless section of code.

That's really all you need a code management flow to do. Protect what we're testing internally from the cruft we develop every day. Provide another protected area where we can test and fix what we think is "done". And lastly, provide a protected area for code we think is ready for deployment.

Today, my current team is looking at using GitLab to host projects, and, while looking around their site, I found a blog entry on "gitlab-flow", which, in turn, appears to be building off of the "github flow" discussed here several years ago:

http://scottchacon.com/2011/08/31/github-flow.html
> Both of these issues can be solved easily just by having a much more
> simplified process. At GitHub, we do not use git-flow. We use, and
> always have used, a much simpler Git workflow.

I'm not sure that I buy that git-flow is that difficult and *requires* a script, but fine. This alternative flow seems interesting in that it's trying (if my first read is accurate) to kill the distinction between 2.) and 3.), collapsing 2.), the hotfix, back down into 1.), wild west development, from my "sections", above. As Chacon says in the github flow blog entry, "there is no difference in the GitHub flow between a hotfix and a very small feature."

Anyhow, this is mostly to remind me to come back and take another look, but my initial reaction is that seems to invite code pollution. There are times that you'll take a dirty hack in production to minimize live code churn to keep things running well for your "real" users while you take your time to fix the underlying issues "for real" in feature branches. That is, github flow seems like it might discourage deliberate bug squashing -- if you need a major rewrite to fix a bug in a forward-looking fashion, take the time. And if you're going to argue that github flow allows you to patch quickly *and* again, deliberately, later, I'm going to argue you want the kludge to live *only* in 2. before you find you're breaking windows in ways that, in retrospect, you wish your coders were disciplined enough to ignore in their day-to-day work. They're not. Worse still, is your company? Or does that hotfix-qua-"very small feature" end up living in production and your codebase forever because it's working well enough?

That said, I'm stuck in a location whose proxy isn't letting me see the images from the blog entry, so I might have to take this all with a grain of salt for now. ;^)

Labels: ,