Git has become very popular tool in software industry as a version control system whether you are working on small or personal project or a big project with mulitple team members. Over the years, I have learned few things while using Git which I wanted to share.
- Keep external or third party libraries in a separate Pull Request (PR) because mostly, such type of libraries are reviewed and tested separately. Even if someone from team wants to review it, it is in separate Pull Request. If such PR is mixed with other feature or bug fix, it is very time consuming to review code related to that specific bug or feature in such big PR. To the least, we can keep libraries in separate commit and feature or bug fix in a separate commit so that code review is easier.
- Don’t leave commented code in a commit or PR just for the sake of reusing it later. You can always look at Git history and retrieve that code later and use it.
- Every commit that you do, should leave project in a state where it can be compiled without error so that if in future, we want to checkout that commit and run project, it should not throw compilation error.
- How often you should commit and what should be size of the commit, it is very debatable topic. I usually prefer to commit when I have completed a chunk of work or function. For example, if I am working on a login screen feature, once I have completed UI, I will do a commit. Some prefer to have frequent and short commits. However, if I am working on a new feature, I try to avoid this to keep Git history clean. Jason Mccreary discusses when you should make a commit in this post.
- Wheter you are working solo on a project or in a team, it is important to have persistent naming convention for branches because if you are not following any rule, it will lead to confusion and complicates code maintenance. It is as important as writing good code. In one of the companies I worked with, we made sure that branching naming convention should be same across all the projects, so that if some developer joins from other team, it would be easier for him/her to follow. There are multiple conventions to name a branch
<authorname> <branch type> <branch name>
and these 3 can be separated by underscore or dash or back slash. I prefer with backslash since I find it less confusing.
asifnoor_feature_login-ui
asifnoor/feature/login-ui
asifnoor/bug/3443 where 3443 is issue tracker defect id.
6. It is very helpful to add meaningful commit messages with a little more context around the change. Think of commit message like writing an email, it should have subject, body and a reference number of the issue that you are handling. Here’s a model Git commit message suggested by Tim Pope
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
If you use an issue tracker, add a reference(s) to them at the bottom,
like so:
Resolves: #1237. What should be size of Pull Request (PR)? According to study of a Cisco Systems programming team, a review of 200–400 LOC over 60 to 90 minutes should yield 70–90% defect discovery, that means a good PR should not exceed in 250 lines of change (number of added + deleted lines) so that it is easier for reviewer to review code.
Let me know what do you think of these practices or what practices you follow while using Git in your project.
P.S This is my post on Medium that I have been thinking for quite some time.
