Yet another way Git make the review process better

As you may know from some of my posts, I am a frequent user of GitHub.  When I started using it I didn’t realize how powerful it was. However, as time goes on, Git is looking to be more and more of a manager’s tool. When I first volunteered to help manage the processing-js project I wrote a set of guidelines that incorporated the use of Lighthouse and GitHub. The basic principle was “tell people what you are working on and the status” on Lighthouse, “do your work and let others look at it” on GitHub and finally “ask people to review” on Lighthouse.  It now seems that GitHub has the ability to do all of the aforementioned items.

Pull Requests

Once you have finished a patch you can request that the owner of the repository who’s code you have forked reviews it. This is done by selecting the pull request button which opens up a discussion between you and the person who owns the repository you have a fix for. Like I mentioned this is a discussion, you and the other person can go back and forth several times before he/she is ready to pull (accept and add to their repo) your code. Git will tell you when a new note was added to the discussion or when any other actions were taken. A pull request is a fast and easy way to see all of the commits associated with the pull request without having to leave the page.

Commit Notes

Once you have committed anything to git you will get a commit url (example). This is a summary of all of the files that were changed including their specific line numbers as well as the before and after identified with a (-) and a (+) sign. This lets the person looking at your patch know exactly what you added/replaced/deleted. When a person looks at the commit with the intention of reviewing it, he/she can add comments to any line that you have edited. This is done by clicking on the line number of the file you would like to add your note to. Here is a sample commit with notes.

I think you probably know where i am going with this. If a person has a patch there is no need for them to go on lighthouse and comment on a ticket. Further, there is no need for the reviewer to comment on their patch on lighthouse. All that is needed here is Git. Git gives you the ability to ask for review, get comments on a review, fix any issues, request another review, and have your code accepted all under one discussion. I know what you are thinking, how does one replace the bug tracker in order to ensure no two people are fixing the same bug. Which brings me to another one of GitHub features, git pages.

GitHub Pages

GitHub allows you to add a custom page to your repository. This page can be whatever you want it to be. You can use it to list the functionality you have yet to implement or you can simply point it to a wiki where that list can be found. Here is a short guide on github pages.

View all of my blogs on GitHub
View all of my blogs


2 thoughts on “Yet another way Git make the review process better

  1. For the bug tracker you could use Github issues? Though I haven’t used it myself, from what I’ve read it seems well-thought and capable. However, I think you confuse Git and Github on some of the points above. AFAIK things like commit notes and pull requests are a *Github* feature, not a *Git* feature. So if you want to use Git, but can’t use Github for whatever reason, you’re out of luck for the power tools that Github provides.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s