21 Jun 2012 sjanes71   » (Journeyer)

Applying “Inbox Zero” to your GIT Workflow

Just as you shouldn’t let your e-mail’s inbox overwhelm you, you shouldn’t let the changes to your source code overwhelm you.  There’s nothing “proven” about Inbox Zero except that for many people, it makes their life easier.  Inbox Zero is a term coined by Merlin Mann in a talk he gave to Google in Oct 02007 with articles. In short, you do everything you can to keep the e-mail empty while maximizing the usefulness of the information there (capturing actions and reference and deleting everything else.)  In this respect, Inbox Zero is an input management system.

We already know as software developers that we “should” track the changes to our software, if for anything to enable the detection of faults as we introduce them.  If you let the changes accumulate for too long, you’ll certainly do a sinful “commit-all” to the repository, leaving yourself a giant matted hairball of change you’ll have to deal with for the rest of the life of the project (if you ever deal with it.)  Applying Inbox Zero here is a backward-looking view of what-has-been-done, your “output management system.” You’re describing it, so you can remember what you did later and communicate to others what you did, and enabling you to reproduce systems of a prior state for bug-fixes or enhancements.  There are a whole lot of ways to “do it” depending on how you work alone, with others, and with your repository.

How To “Just Do It.”

  1. Run git gui in your repository.
  2. Mash F5 to refresh the status of your files.
  3. Choose some changed files and examine their differences—write a description of those changes.
  4. Add and commit.
  5. Repeat until there are no more changed files.

How To Do It… Alone.

Even if you’re not working with anyone, you should be tracking your own code for your own sanity’s sake.

  1. Run git gui in your repository.
  2. Mash F5 to refresh the status of your files and unit tests.
  3. Choose some changed files and examine their differences—write a description of those changes to code or tests.
  4. Add and commit.
  5. Repeat until there are no more changed files.

How To Do It, With Others.

If you’re working with others and you have a “clean repository” rule, you’ll have to add the first step here to your workflow:

  1. Run your unit tests, if they’re all passing, continue to the next step.
  2. Update your repository from the master. [Everyone's team workflow is going to be different so your actions here may differ.]  Run your tests again, if they pass, go on to the next step.
  3. Run git gui in your repository.
  4. Mash F5 to refresh the status of your files.
  5. Choose some changed files and examine their differences—write a description of those changes.
  6. Add and commit.
  7. Repeat until there are no more changed files to commit.
  8. Start your next task.

Some organizations may designate different branches as clean or testing, the idea is that only clean passing code goes into clean branches and “work in progress” code goes into the testing branches. In either case, keeping the backlog of work-done but not yet described will go a long way to help you understand the slow hard slog of code as you or your team refines it.


Syndicated 2012-06-21 16:08:21 from sj4̄nz

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!