Git has clearly won the source control wars. Its lightweight branching and easy merging make for a frictionless experience. But there are things that you as a developer can do with git and with your code to make it even better.
Small Files
Having files and functions that contain as few lines of code as possible is more a Clean Code principle than a Be Good At Source Control principle, however it effects your source control directly. The Single Responsibility Principle will help you enforce just that. But how can this possibly effect source control?
- Small Files. It's easier to solve a merge conflict in a small file than in a 800 line monster.
- Small Functions. If you have smaller functions, the chances of having conflicts lessen and if you have conflicts, the intent of the code should be clear and you will be able to easily solve the conflict.
- One Thing. If your classes do one thing and one thing only and only that one thing, you will find that you don't often have many hands in that code at the same time.
Small Frequent Well Named Commits
Commit small units of functionality and name these commits well. This will help you easily see what changes you made when you worked on a specific piece of code. This will also help you find bugs that were introduced in a series of commits. You won't find yourself in the situation where you need to revert a bunch of code, and in the process lose code that you have already completed.
If you find that a piece of code that you are working on is just too big to fit into a small commit, or you are not comfortable with a small commit, then make a branch.
Make Branches
Not making branches is a taboo that should die away with the likes of sourcesafe and svn. In git, branching is easy and cheap and local. You are encouraged to make many branches for the following reasons:
- You don't dirty your working code with un-tested code.
- Have something you want to try? Make a branch. If it does not work, just delete it and forget about it without any impact to existing code.
- Working on a big feature and suddenly have to change an unrelated thing? Both of those had to be their own branches so you could handle them separately.
Squash Commits
Sometimes, I make a branch to try something new or to update libraries or something. These branches usually contain many breaking commits that I do not want to litter the history with. I deal with this problem using the --squash command when merging my branch.
git merge someBranch --squash
This will merge the branch, but not commit the changes. I then commit the changes with a commit message of choice and delete the branch. Thus, the changes appears in my history as a single change. I know this might seem in conflict with Small Frequent Well Named Commits, but there are cases where this is fine (like adding a bunch of new code that is separated from existing code).
There will always be some cases where the above "rules" are not applicable or not possible to enforce, but I find that they are a good guideline for myself.
Please feel free to add to the list in the comments.
This post was first published on blog.entelect.co.za.
CodeProject
