Commit Driven Development(tosbourn.com)
tosbourn.com
Commit Driven Development
http://tosbourn.com/2012/08/development/commit-driven-development/
16 comments
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.
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.
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.
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.
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
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
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:
Two extremely useful aliases:
[alias]
fi = !sh -c 'git commit -m \"fixup! $(git log -1 --format='\\''%s'\\'' $@)\"' -
ri = rebase --interactive --autosquash
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
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.
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:
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.
Here is an example task I completed yesterday:
#1982: Automatically update events widget
SG Shortcode
Instructions coming. Depends upon APC being enabled for caching to
work properly. Triggered through the use of `[events]` shortcode
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.
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.