-
Notifications
You must be signed in to change notification settings - Fork 2
git Best Practices
This work is a expanded adaptation of the content from the developers of Tower - a GUI based version controlling system built on Git. You can find it here. If you want to avoid the hassle of learning the command line commands, you may want to consider using a GUI based system. I will not recommend anyone to completely ignore the command line commands, but if you are that person who is intimidated by that scary black window you can safely switch to a GUI based engine.
In this article we will look at some of the Best Practices we can follow as we collaborate using git. If you haven't already read how to collaborate on git, I encourage you to do so before you continue.
A commit is a message to yourself and other collaborators that you have finished working on something and you believe that it is ready. You might be tempted to commit incomplete work (eg: signing off at the end of day and you haven't completed the current task), but abstain from doing so. I recommend you breaking the problem into small, but logical and semantical chunks and then work on it. It will also help as small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and ability to stage only parts of a file, Git makes it easy to create very granular commits.
Tip: You can create a separate branch for each issues, so that commits can be more meaningful.
Having said that, you shouldn't wait for a large section to complete before making a commit. As I mentioned above, complete your task in small chunks and commit after each chunk is completed. This will help you keep your related changes together, moreover it allows you to share your code more often with your colleagues. This tip will come very handy if you ever have to work on a project with rapid changes as it will help you avoid merge conflicts.
In a collaboration task, communication between the collaborates keep them walk towards achieving the shared objectives. Your commit messages are one of the important way of communicating with other collaborations. Always use the first line (less than 50 words) to Summarize the purpose behind the change. Then leave a blank line and add more specific and detailed messages. It is also import to write good commit messages. We all know that done or completed or edited main.py etc. are not good commit messages. You can write good commit messages if you try to answer the following questions in your commit messages:
- Why are you making this change (purpose)?
- How does this differ from other implementations (Why)?
Other Tips to improve your commit messages: adapted from Chris Beams' article
- Write your message in imperative mood in the summary line
- Wrap the body text at 72 characters
- Capitalize the subject line
Obviously, you'd say. Still we are tempted to "think" that my code works out of the box. While it is difficult for a coder to test the code thoroughly you must make sure that your it is completed and has no side effects. Keep the big picture in mind as you test your code.
Note: Always take step back before committing and think what impact your code make on the program as a whole and what other collaborators are doing.
One of the most powerful feature of git is it's ability to maintain and manage codes in multiple branches. You should take maximum advantage of Branching in your development workflows. Be it for a future release or adding a new feature or to fix a bug or even to try a new idea. Remember, branches are the perfect tool to help you avoid mixing up different lines of development.
While Git is an exceptionally powerful tool, it is also a flexible tool. Developers across the world use Git in different workflows. Some may prefer [topic branches|Collaboration-Workflow#topic-branches], others long-running branches. Some like to [merge, others prefer rebase|https://www.atlassian.com/git/tutorials/merging-vs-rebasing]. There are mainly two factors influence your choice of the workflow. 1) Your project's development philosophy for overall development and deployment 2) You and your teammates' personal preference. However you may choose, make sure that your team is agreeing to the workflow and everybody sticks to it.
It is important that you orient your team in following your project's workflow. When you have a new member in your team who is used to a different workflow, he can unintentionally create potential problems by choosing to work on his own style.
Hope this article gives you some ideas on the best practices.