the-generalist.com

  • Increase font size
  • Default font size
  • Decrease font size
joomla templates, wordpress themes, drupal, datalife engine, graphics, seo,
Home

Compartmentalize Version Control Check Ins

E-mail Print PDF

Use your version control server to your advantage. If you check in your code once a day, you really just have a daily backup of your code. I prefer to check in my code each time I finish a task. This way merging is less dangerous, it's easier to see how I completed a specific task, and the history of my files is more easily navigated. Checking in less frequently diminishes the benefits of using version control. I'm going to define a compartmentalized check in as a check in that relates to a specific task completed. Preferably, these tasks range from a few minutes to a day's worth of work in scope. If you frequently see your tasks as larger than this, you might want to try breaking them up into smaller tasks for the purposes of checking in your files.

The more changes to a file, the uglier merges will be. Consider the likelihood that two people are fixing different bugs in the same file at some point during a project. Small changes are more likely to be in different places in the code. When you have to merge, there will be less conflict if any to sort out. If multiple people have been working in the same file for days, it's much more likely that they've been changing code in the same functions. Merges can get ugly fast in this case. A complicated merge can wipeout fixes without anyone knowing the fix was undone.

When you compartmentalize your check in to a specific task, you can easily check a file to see what you did to accomplish that task. Just as importantly (or maybe more so), your teammates and lead will be able to see what you did. This works the other way also. If a teammate broke your replace function when they upgraded the search function, you want to be able to see what they did in that specific change. You don't want to see every change they made all week all merged together. Again, accomplish a task, check in the task, and comment the check in descriptively.

It's easier to navigate a file history when changes are small and well commented. Let's say you're trying to find a new bug in your search function. Looking back at your version history for the affected class, which do you prefer?

Occasional Check In (Bob)

Compartmentalized Check In (Fred)

Checked in April 22nd. Fixed some bugs.

Fixed a drawing problem with the people selector.

Asdf

Fixed an issue with reload() being called too often. 

Checked in April 27th. Made some speed improvements.

Added the ability to search by date.

Checked in May 2nd. Don't remember what I did.

Added the widget count interface. Merged with whatever Bob did last week.

 

Refixed the "reload() called to often" problem (lost it during merge).

 

Commented the drawing code.

 

Added copy\paste functionality.

Looking at that list, it will be easier to find the source of your bug using the list on the right. You don't really have much useful information on the left. Not only that, but the list on the right will have has less code changes per check in so you'll have less to search through when comparing between version. Give yourself and your teammates a hand, check in frequently and comment you check ins well.

Some days I'll check in code every five to ten minutes. At each check in I make sure to put an accurate comment describing what I did. This way I can look back at a history of my changes and see what specifically I did to fix an issue or add a feature, and can track my changes easily. If you've integrated your version control to your IDE nicely, there is little time spent or disadvantage to checking in frequently. Get in the habit of making frequent, well documented check ins.

 

Add comment


Security code
Refresh

Main Menu