Git Best Practices
Commit Related Changes
- A commit should be a wrapper for related changes.
Example: fixing two different bugs should produce two separate commits.
Commit Often
- Committing often keeps your commits small. Small commits make it easer for other team members to understand the changes and roll them back if some thing went wrong. Moreover, avoid merge conflicts, which is common when you commit few large code changes rarely.
Don’t Commit Half-Done Work
- Commit code when it is complete. This does mean you have to wait until you completed large features before committing.
- Develop the habit of splitting larger feature’s implementation into smaller logical chunks and remember to commit early and often
- if you have incomplete feature at the end of the day, do not tempted to commit consider using Git’s ” Stash” feature instead.
Test Before you Commit
- Test your work thoroughly to make sure it really is completed and has no side effects, as far as you can tell.
- Do not push/share your code without testing.
Write Good Commit Messages
- Good message contains a short summary of your changes ( Maximum of 50 character)
- And separate the body of your message by including a blank line.
- The body of your message should answer questions like, what was the motivation of the change and How does it differ from the previous implementation
Frequently backup your VCS
- Setup a schedule backup to an external tape drive or remote Disaster Recovery(DR) server because your central Git server might fail too.
Use Branches
- Never develop on master, always develop on branch for new features bug fixes, experiments, ideas etc.
- branching is one of Git’s most powerful features. Quick and easy branching is a central requirement starting from day one
Agree on a Workflow
- Agree on one workflow and strictly follow it
- Git lets you pick from a lot of different workflows and use then responsibly.