Git best practices - TeamCrown/First-project GitHub Wiki
Git Best Practices
Git provides a tremendous amount of freedom and little guidance, so teams often have to define their own best practices. This document defines some of the best practices that we should use to efficiently use git. We highly recommend using Git CLI, since it is consistent across platforms.
Commit Related Changes
In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. Do you know what S from SOLID stands for? Yeah, Single Responsibility Principle. You can apply this principle for commits, not only to the code. You should commit the least amount of lines that make sense together.
A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other team members to understand the changes and roll them back if something went wrong.
Don’t Commit Half-Done Work
You should only commit code when it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s “Stash” feature instead.
git stash temporarily shelves (or stashes) changes you've made to your working copy so you can work on something else, and then come back and re-apply them later on. Stashing is handy if you need to quickly switch context and work on something else, but you're mid-way through a code change and aren't quite ready to commit.
Test Before You Commit
Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.
Write Good Commit Messages
Always provide clear and understandable information in your commit message. Start by writing a short summary of your changes, leave a blank line and then follow it up with a detailed description of the change. You don’t want your commit history to end up looking like the one below.
Use Branches
Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, experiments, ideas…
Git Branching lets you create and manage an organized workflow within your repo. Team members can be assigned various Git branches allowing them to work concurrently but in an isolated manner. Always give a purpose and a meaningful name to your git branch so others know what exactly you are working on. Git has made it simple to compare code between two branches, which can ignite healthy discussions, improve codebase quality, and spread the knowledge among developers. This easily paves the way for code reviews and insights into the code that the developer might gain from.
Agree on a Workflow
Git lets you pick from a lot of different workflows: long-running branches, topic branches, merge or rebase, git-flow… Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates’ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.
Rebase your working branch frequently.
It’s crucial always to keep your branch rebase with the latest code. Writing new code upon obsolete one is useless. It is as meaningless as fixing a bug that may already be fixed. You should rebase your working branch frequently to prevent bugs, rework, and the tedious job of resolving conflicts with the upstream branch.
Delete old local branches
Check all your old local branches right now: git branch. If you’re like me, you might have over 10 stale branches that have either been merged into master already or are just sitting around taking up space. Time to delete this baggage. But only if you’re absolutely sure you don’t need them anymore. Use git branch -d to delete a particular branch.
Don’t leave Pull requests out for too long
An open “pull” request can create conflicts sooner or later. Don’t leave them unattended for more than 2 days. Always review the code and if it is ok to deploy, merge the pull request. This will not only fasten the shipping process but also avoid code conflicts.
Squash your commits
Having lesser commits in your history makes it easier to monitor and track where you went wrong. If you want to keep a clean commit history, this one’s for you. Squash and merge all your commits into one when the pull request is merged.
Version Control is not a Backup System
Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically – you shouldn’t just cram in files.
If anyone finds other helpful practices, please feel free to edit this page to add in your suggestion. Thanks.
References:
RayGun - 5 Must Use Git Practices