This is a nice little-p process. I've kind of stumbled into it from time to time when I'm having trouble nailing down what I want to do. Tower.app actually helps, because it leaves your commit message betweens cancels.

I say little-p because I've found it to be a nice tool in certain circumstances, but it's not a very proscriptive process, and it's not always clear that you need it until you already find yourself doing it. So it's nice to identify that it happens, and to give yourself a chance to take advantage by pausing and reflecting before you commit, but honestly that's just good practice regardless.

For me, sometimes I'll write some code, get a commit message ready, then realize as I'm writing my message that there's a better/clearer/more general solution to what I just did, and I use that as an opportunity to improve my commit.

I'm not sold on doing this at the commit level, but we have been using Pull Requests on Github in this fashion for Wufoo and SurveyMonkey. We start with an initial commit to start the branch for a new feature and then immediately initiate a Pull Request. That pull request contains a list of items that need to be done for the feature and as it gets developed you can see how commits are working towards making that pull request ready. This also helps tremendously with code reviews because you can do them as the feature is being developed.

What's nice about this method for us is that you can just look at the list of active pull requests for a project and see what features are in active development and get an easy way to drill down into the progress of each.

I guess you could call it Pull Request Driven Development.

We do something quite similar.

Because issues and PRs are hopelessly intermingled in Github, we create issues with the sole intent of creating an initial PR "feature/1234-api-auth" so we can reference and close the initial ticket.

The issue describes what is the problem and what needs to be accomplished, while the PR body describes what actions will be taken and the overall progress.

How might a commit-first Git workflow look? I'm imagining a lot more use of squash/fixup and the like than sounds fun.

Usually I write a little code, commit what it is supposed to do, then fixup all the little edge cases and bugs that come naturally. But what's important is that first commit is sets up a little problem with a clear goal, and then everything afterwards works toward that goal.

Two extremely useful aliases:

  [alias]

  fi = !sh -c 'git commit -m \"fixup! $(git log -1 --format='\\''%s'\\'' $@)\"' -    
                                                                                                             
  ri = rebase --interactive --autosquash

First alias allows me to create a commit prefixed with fixup! very easily. So workflow looks like this:

  2536aw3 implementing feature foo
  sfd93ja fixup! implementing feature foo
  ok4jzvd fixup! implementing feature foo
  k4okvxx fixup! implementing feature foo
  2okoswa fixup! implementing feature foo
  zxvorm3 fixup! implementing feature foo
  ko2koaa fixup! implementing feature foo

And then I rebase when git log --graph --pretty goes off the screen.

In Code Complete McConnell writes an example in which he writes the main ideas of how his code will work as comments in an empty file.

so maybe one would go on write this comments, commit them as the 'How', and then in the first commit message write the 'What'? then do the first commit and continue from there.... making the 'How' work

I made a simple proof of concept of the workflow. https://github.com/walle/git-cdd

I would imagine the amount of commits might actually shrink, because there is more focus to each commit.

I prefer thought driven development.

This X driven development stuff is getting out of hand. Because I know what my next block of code is going to be once I've written the commit message.

You might not know what it is going to be, but you should know what it will do.

I'll also know:

  - All the TODOs
  - Applicable Nota Bene's (you know, "this breaks in X")
  - Whether or not I'll be distracted before completing the task with something else that would need a different summary.

Yes, I know what it will do, but a good commit message isn't a generic one-liner that describes it beforehand. What you are looking for is "task driven development".

A very fair point, but surely Task Driven Development is more about how you write something, not about the workflow around it.

False. "Task Driven Development" (notice the quotes?) is not about how I write something. That is decided elsewhere. Same for workflow. My commit messages don't dictate either of those.

Here is an example task I completed yesterday:

    #1982: Automatically update events widget

That, to the uninitiated, means diddly-squat. It ended up being "write a wordpress shortcode plugin that hooks into our API for event retrieval". The commit message was as follows:

    SG Shortcode
    
    Instructions coming. Depends upon APC being enabled for caching to
    work properly. Triggered through the use of `[events]` shortcode

I then had a few cleanup commits, and some calibration of things such as curl timeout, apc cache length, and shortcode option support. I also added some documentation of the feature to our internal wiki and sent out an email to the people who would end up using the feature. I'll probably end up yelling at one of them today to see how he's using it.

How I write something was largely irrelevant in the beginning, so long as it completed the task. In this instance, there was a bit of back and forth in the github issue concerning the implementation, but for smaller things there usually isn't any back and forth. The scope of the task and the depth of it's affects should drive the workflow around your development, not a commit message you through together on the off-chance that the task is still relevant at the end of the day.

If you have a large enough task that you are using commit messages to plan out how a feature will work, you're gonna have a bad time. You might want to start chunking your work into smaller, more manageable, testable components, otherwise whatever the hell you ended up writing is going to be full of failboat.

This is EXACTLY what an integration test gives you, start there and let it drive your commit message instead, no need for a new mantra.

That is very true, to be honest my post was food for thought more than a call to action.