.png)
Version control is crucial to the success of any software development project. For our projects, version control comes in the form of code repositories and generous use of branches.
A branch is essentially a unique set of code bundled under a unique name. To explain branches, we'll use a cooking analogy. Imagine you're preparing a big pot of soup for a dinner party. You already have a pretty basic soup done that can be served perfectly fine on its own, but you want to try something fancy this time. You decide to add some spices, but after adding everything all of a sudden, the soup doesn't taste so good anymore.
Since you used your only pot of soup, you have to start all the way from scratch again to go back to what the soup was before you added those spices. However, if you had portioned the bigger pot of soup into two smaller pots of soup, you could experiment with one pot, adding spices and ingredients, while the other pot stayed the same. After you add the spices, you decide the new soup isn't so great, so you pour it out and return to the other pot of soup.
You now have the option to serve it as is or to try again with spices now that you've learned from your previous mistake. Congratulations, you just discovered branches!
Branches allow you to take a copy of the code repository and "branch" off, hence the name. With this branch, you can add features at will without fear of affecting the metaphorical base pot of soup. If you decide you like your changes later, you can merge the branch into the main repository and thus incorporate your changes into the rest of the code.
While the use of branches doesn't inherently improve code quality, it can lend itself to practices that do improve code quality, such as code reviews and pull requests.
A code review is a general term for when a developer has his work reviewed by another developer, whether the second developer is on the same team or an external party. A pull request is a specific instance of a code review, which can be opened when a developer wants to merge their branch into another branch, or the main code repository.
On our projects, we require a new branch to be created for each new major feature, or set of features. Not only does this help us isolate bugs, it also helps us enforce our policy on pull requests. We have our development partners open pull requests for each branch merge, and another developer on the project (usually a more senior developer) will review the code in the branch before deciding whether to merge it into the rest of the repository.
If the reviewer finds issues, they can fix them and/or leave comments on the pull request to inform the developer which parts of the code need to be fixed before the branch can be merged. When both the developer and the reviewer are given responsibility for the same pull request, the quality of code tends to increase.
Running a business is hard,
Software development shouldn't be ✌️
