Is It a Best/Recommended Practice to Use Branching with Version Control Systems?

Problem scenario
You are debating on using branching with your repositories or using trunk-based development (with virtually no other branches). Is it a best practice to develop on the mainline (with branching infrequently if ever)?

Maybe. It is not clear.

In Support of the "Yes" / You Should Use Branches
In practice many companies use Git Flow or other branches in their Git repositories.

Perforce is a very well-respected code versioning product. Its website says that a best practice for branching is to "protect your mainline." It says "…all commits have to be high quality." (See its source article for context.)

This qualifier "high quality" is a safe bet. But if all commits are of a "high quality", it is doubtful the your code would end up being merged to the mainline (or trunk) frequently. Moreover the existence of a best practice for branching strategies in an article that says "[u]se our version control branching best practices…" suggests branching can be a best practice. To learn more about Perforce's best practices for version control, see this posting.

This website says deciding on a branching policy is a best practice; therefore we interpret it as saying using branches is a best practice. Another source recommends using branching (for learning) is this website.

In Support of the "No" / You Should Not Use Branches
The book Continuous Delivery recommends developing on the mainline or trunk-based development. The DevOps Handbook also recommends not having branches in a code repository.

For an in-depth article on branching strategies and trunk-based development (that tends to shun branches), see this posting.

Leave a comment

Your email address will not be published. Required fields are marked *