Here we see a graphical representation of a typical version control setup with remote repositories. Azure DevOps, GitHub, and Bitbucket Cloud are all examples of cloud Git-based remote repositories. A developer with Git installed locally uses Git commands, even if that is via a graphical interface to clone, fetch, fork or pull code from the repository to their local hard drive. They work on the code making changes and saving those changes with accompanying descriptions as commits to their local Git repo. Those commits are then pushed back to the Git structure in the remote repository where they remain until they are merged back into the main trunk through a process called a pull request. A pull request is a process of code review by other developers, preferably two or more followed by a merge operation.

Now I wanna talk about two things that are very closely related, code flow and branching strategies. It's a little bit of a chicken or egg situation, but suffice to say that they are interdependent and one impacts the other. Having said that, there are a number of best practices that should be followed no matter what strategy you adopt.

The master trunk should always be bug-free and a facsimile of what is in production. Branches, be they new features, versions, or bug fixes should have meaningful names and be related to a piece of work like new functionality, a work item, or a sprint. Commits should be frequent, relate to one code change and have an accurate and full description.

Now I want to illustrate with a simple and contrived example of why these best practices should be followed. Remember developers are people and have to read, interpret and review code changes before they are released. We want to add a customer search function to our software. First off, we need to add a branch from our known and good and stable master trunk code with a name describing what the branch is about. It's a new feature called customer search. We could just leave it at that, but in reality, the search is made up of three distinct pieces of functionality.

So we will split that into three branches off the customer search branch. This serves two purposes, firstly keeping each piece of work smaller and more manageable for testing, progress tracking and merging, and secondly if you want different people to work on the pieces simultaneously. Within each of these sub-branches we want work to be committed frequently and often, and I would say that what is illustrated would be the bare minimum. Committing after each piece of logic is completed helps with tracking changes, locating bugs and unwinding code changes if necessary. Each sub-branch is merged back to the customer search branch with a pull request where the code is reviewed.

Not to state the obvious, but reviewing a relatively small piece of code in one or a small handful of files is a relatively simple task as compared with code spread over potentially dozens of files. We've ended up with our code reviewed and successfully merged into the customer branch. This is where some of the branching strategies diverge, and I will look at why in the next section. But for simplicity sake, we can now merge our customer search branch back into the master trunk.

What if we didn't follow these best practices and we created a branch called customer update and assigned the work to a developer? That developer did the work we've just talked about and committed all of it to the update branch with the description, customer changes. Then they submitted a pull request to have their code reviewed and merged. Apart from the already mentioned issue of reviewing a larger chunk of code, where's the history of code changes? If those assigned to review the code don't have an intimate knowledge of this particular piece of work, they have little in the way of description clues to help them. As I've already said, developers are human, so reviewing and merging a relatively large amount of code will greatly increase the possibility of errors. Now, think about that one update branch spread across several developers and then have them merge their work back into the master trunk. In the real world, this scenario would be orders of magnitude bigger in scale and complexity. I really want to hammer home the importance of these simple conventions and how not using them will negate any cleverness you may adopt in your branching strategies.