Commit Driven Development

http://tosbourn.com/2012/08/development/commit-driven-development/

by tosbourn • 14 years ago

15 16 14 years ago

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.

tosbourn4• 14 years ago

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

josegonzalez3• 14 years ago

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".

clwoodson• 14 years ago

I prefer thought driven development.

edb• 14 years ago

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.

tosbourn4• 14 years ago

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

harlanlewis• 14 years ago

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

tosbourn4• 14 years ago

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

elviejo• 14 years ago

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

kenmazy• 14 years ago

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.

walle_• 14 years ago

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

ubercore• 14 years ago

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.

unfoldedorigami• 14 years ago

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.

ericclemmons• 14 years ago

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.

Commit Driven Development

Related Stories