3 ms·

Commit Driven Development

15 points by tosbourn 14y ago

josegonzalez 14y 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.
- tosbourn 14y ago
  You might not know what it is going to be, but you should know what it will do.
  - josegonzalez 14y 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".
    - tosbourn 14y ago
      A very fair point, but surely Task Driven Development is more about how you write something, not about the workflow around it.
      - josegonzalez 14y ago
        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.
clwoodson 14y ago
I prefer thought driven development.
edb 14y 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.
- tosbourn 14y ago
  That is very true, to be honest my post was food for thought more than a call to action.
harlanlewis 14y 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.
- walle_ 14y ago
  I made a simple proof of concept of the workflow. https://github.com/walle/git-cdd https://github.com/walle/git-cdd
- tosbourn 14y ago
  I would imagine the amount of commits might actually shrink, because there is more focus to each commit.
- elviejo 14y 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 14y 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.
ubercore 14y 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 14y 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 14y 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.

15 points by tosbourn 14y 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.

tosbourn 14y ago
You might not know what it is going to be, but you should know what it will do.
- josegonzalez 14y 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".
  - tosbourn 14y ago
    A very fair point, but surely Task Driven Development is more about how you write something, not about the workflow around it.
    - josegonzalez 14y ago
      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.

clwoodson 14y ago

I prefer thought driven development.

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

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

harlanlewis 14y 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.

walle_ 14y ago
I made a simple proof of concept of the workflow. https://github.com/walle/git-cdd https://github.com/walle/git-cdd
tosbourn 14y ago
I would imagine the amount of commits might actually shrink, because there is more focus to each commit.
elviejo 14y 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 14y 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.

ubercore 14y 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 14y 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 14y 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.