Git Best Practices
Git is VCS (version control system) that is found universally in the industry where Engineering Teams (developers) involves. Using Git in a small or large team since it becomes crucial to have a system of blending everyone`s code surely. It's better to make a list of best practices to follow before starting using VCS.
In this blog, I have listed simple & best rules that you can follow to make working with a VCS easier.
1. Automic Commit
Atomic commit means the smallest change in your source code that improves something or fix the bug, it`s enough to commit that thing.
Advantages of atomic commit :
- It makes it easier to track small changes.
- It makes it more convenient for other developers in the team to look at your change, making code reviews more productive.
- If any commit breaking the build, it`s easier to completely roll back.
2. Commit Message
Writing a good commit message helps the other developers to know about which ticket is done or what thing you did in that specific commit. A very good practice of writing a good commit message is to include a ticket no(if you are using a tool like Jira, or anything else), and append a few 1 to 2 lines of description like what you did in that commit.
3. Use .gitignore file
.gitignore file is very useful to ignore the files or paths that you don`t want to track into the repository. Here is attached a .gitignore file of the Android Project, just to give you a sense of files or paths that you ignore in your android project. Here is an example of the Android Studio project .gitignore file.
4. Use git stash feature
Instead of pushing the broken code and block other developers from working on their tasks, You should wait…, you should not commit broken code in the repository before leaving the office at the end of the day.
Basically, Stash command keeps your changes on the temporary shelf, that you don`t need to push to repo at the moment like you currently working on that thing, or you know the code is not functional.
git stash (To save your un-committed changes on a temporary shelf)git stash pop (To pick changes back from temporary shelf.)
5. Short Commit
It`s the best practice to commit your changes early. Early commit helps to cut the risk of conflicts b/w two concurrent changes. I prefer to commit early, just after my single change. If you do small commits, it`s easier for other developers to understand the code history.
6. Take pull before start
It`s a best practice to keep update your branch from the main branch before you start work. If you update your branch on daily basis, then there are fewer chances to resolve conflicts when you will merge your branch code back to the main branch.
7. Use Branches
Most important feature of git is its branching feature, branches contain a new copy of your code`s current state.
Here are the few cases in which you must create a new branch even an individual works on a project :
- Make a new branch for every new feature.
- Make a new branch for fixing live-build related issues.
- Make a new branch for fixing bugs.
- It also helps to keep your repository organized.
- It also helps to ready the build in case if you don`t any specific feature at that moment.
8. Use tags
A tag is a snapshot of the branch current source code. Tag is just like a branch but it doesn`t have any history. Tag is useful when you release the build and attach the tag to that commit makes it easier to roll back in case of any broken code.
To create a tag on your current branch, run this
git tag <tagname> -m "message"After creating the tag don`t forget to push the tag to the remote. For this run this command.
// if you want to push single tag
git push origin <tagname>// if you want to push all tags
git push origin --tags
// use this command to checkout to the specific tag
git checkout <tagname>
9. Merge Branches
If a team of developers works on a single project, each member should work on a separate feature branch. But after completing the feature everyone has to merge their branch code to the main branch, and might be some developers made some changes in some common files, merge branches not be done automatically when you and someone else made some changes in the same files. Human Interaction requires to merge the code, so you have to learn how to deal with git merge techniques.
git merge <branch_name>git merge --abort // to abort the merge
10. Test changes before and after
As s developer, your responsibility also includes unit test all things that were affected by your commit before and also after merge into the main branch. Unit test is extra security to test everything before giving build to QA, it also allows you to identify bugs. Being a good software developer, don`t rely on the QA team to find every bug, make a habit to test your code before commit and also after merge.
Conclusion
Git is a complex tool that takes time to learn. Using these practices can help teams collaborate successfully with Git, regardless of their level of expertise.
