Click here to Skip to main content
15,064,915 members
Articles / All Topics
Technical Blog
Posted 16 Jan 2015

Tagged as

Stats

6.5K views
2 bookmarked

Git Good

Rate me:
Please Sign up or sign in to vote.
5.00/5 (3 votes)
16 Jan 2015CPOL3 min read
Git good

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.

This article was originally posted at http://feeds.feedburner.com/sneakycode

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

SneakyPeet
Software Developer (Senior)
Unknown
I write about Domain Driven Design, Clean Code and .net

Comments and Discussions

 
GeneralMy vote of 5 Pin
PhilipOakley19-Jan-15 8:29
professionalPhilipOakley19-Jan-15 8:29 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.