

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

======
ubercore
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
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
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.

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

~~~
kenmazy
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.

------
clwoodson
I prefer thought driven development.

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

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

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

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

~~~
josegonzalez
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.

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

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

