Best Practices For Branching

Now that you understand the power of branches in Git, it is pretty clear to see not only how they are useful, but also how they may be complicated and easy to trip yourself up over. To get the most out of branching, developers tend to follow these best practices to keep things organized, sidestep error-prone areas of the process, and to manage their projects from a deployment point of view.

Only Keep Working, Production Code in the Main/Master Branch

By doing this, developers can guarantee they have a copy of the codebase that is 100% functional and able to be shipped to clients/users/customers. More than that, this provides a branch where there is known, tested, bug-free code for other branches to be based off of, so that new features being developed do not have irrelevant issues from other work-in-progress code. Some projects go as far as to assign roles to users in the repository, such that only special leaders in the project can approve merge requests into Main/Master, even though everybody is allowed to submit them.

Organize Branches by Feature

This makes logical sense as coding different features, probably independent and having no inter-related code, does not require users to work on the same branch. It also provides a good way to organize what is being worked on within the project. Finally, branches are a great way to keep experimental, possibly broken code that won't be used within the revision control system when being developed, and potentially to be revisited, without affecting the functionality of the main copy of the codebase.

Merge Requests are Code Review Opportunities

Especially when following the above practices, merge requests become times when everyone on a project can view all of the commits and revisions for a particular, complete feature, before deciding to integrate it. This holistic view allows for evaluation of the end result better than doing code reviews commit-by-commit. Then, when merging into Main/Master, the code being merged represents a working piece of specific functionality, approved and tested by the team, with any issues ironed out through the built in issue tracking and commenting/discussion features that developers can use to communicate.

Do Not Merge With Uncommitted Changes

Doing so may lead to a mess of code that is impossible to untangle, and even the abort command may corrupt the uncommitted changes you have. The Git documentation itself warns against doing this (https://git-scm.com/docs/git-merge).