Do-the-Right-Thing GIT Porcelain
June 4, 2010
The “Do The Right Thing” Git Porcelain
Before making any changes to a program, a good developer will make an entry in an issue tracker and then create a separate branch in which to handle the issue. Only then making the necessary changes and finally merge the changes into to the master branch when they are ready. All before finally marking off the issue as complete.
That’s the ideal anyway. It is, unfortunately, too easy to not do these things by skipping a step or never bothering with them at all. Who really wants to waste time with all this? Developer’s just want to get the job done. To remedy this, we might create a “Do The Right Thing” Git porcelain.
Lets say we had a bug to fix. We could simply invoke our DTRT command:
$ dtrt new
An editor (provided by $EDITOR) opens to allow the developer to describe the issue in detail. When saved and exited, it will automatically create a new branch with a name based on the description and check the branch out, ready to go.
Now changes can be made. When complete (which means passing tests, right?) we simply tell DTRT again.
$ dtrt done
And it will merge the current topic branch into master using the issue description we originally gave it. All done. And, hey, we did the right thing!
Such a porcelain alone would be useful, but it gets even better when we start adding hooks into this process.
For instance, a hook can be added such that new issue creation can post an entry directly to an issue tracker such as GitHub Issues. Not only can it post the issue, but when an issue is complete, it can label the ticket with the version it belongs and closes it. Notice the added benefit of this: it creates automatic changelogs! No more writing those tired HISTORY files. In fact, by using DTRT religeously, we can use a tool like VCLog to pop out prefect HISTORY files in almost any format.
To encourage proper TDD, a hook on new issue creation could automatically create a test in a preferred format and drop the developer directly into an editor with it. Thus putting TDD in our proverbial laps.
Another hook placed on merging could prevent the completion of the issue branch until all tests pass, thus helping to improve the quality of check-ins.
I have no doubt other’s might come up with a few other helpful hooks as well.
I have not endeavored to implement this, having too many other projects to work on already. But it would make a good project for another inspired soul.