Everyone will tell you to learn git, but I'll try to show you instead of telling. I believe that slightly advanced techniques such as branching don't really make sense unless they are introduced with context and examples.

In this post, I'm going to explain how I used git branching when contributing to Microsoft Sharepoint web app, and also give some examples on how branching is used in school/personal projects. Finally, we'll touch on how branching is used in contributing to open source software (OSS).

Contributing to Microsoft's Codebase

Starting off with my experience as an intern at Microsoft, I'll give a little context about the codebase I worked on. It is a huge monorepo (meaning multiple projects are contained in a single repository) of about 50 GB's of code. Nearly tens of deployments are made to the main branch every day and hundreds of engineers are contributing to it simultaneously. I was lucky enough to be one of those and here is how my workflow looked like.

I would get the latest version from the main branch, and then branch out to work on a piece of code with a command like.

git checkout -b my-branch

This command switches to a new branch named my-branch. There are new commits introduced to main after I branch out, but they're not to be worried about, we'll resolve them when I'm ready to merge my branch back to main.

At this point, it's important to think about what you'll work on in this branch. Here are some advice I got from my team:

• Introduce your changes as self contained and small pieces:

This means that the code changes you introduce in this branch should focus on one small purpose. (eg. UI of the news card.) In terms of length they should be small. While this is very subjective, ideally if a senior engineer is able to review it in 10-15 minutes that should be fine.

• It's fine if your changes are not invoked by production code:

Some features require a lot of changes that are dependent on each other to fully function, thus it's ok to introduce incremental changes in your branch and not invoke them yet. So they are basically in the codebase but nothing is calling them, they just sit there. At first this seemed like a bad practice for me, but it is not harmful and it turns out to be pretty common because this is the only possible way to introduce small changes.

While working on my-branch, you can (and should) push regularly and never worry about messing up the main branch. Once you are ready to merge back to main, you are asking the main branch to accept (or pull) your changes by opening a Pull Request (PR). For my internship, when I opened a PR a couple of things would happen:

1. Automated tests are run, making sure that the changes you introduce are not breaking any existing functionality.
2. Other members in your team (possibly more senior engineers or peers) will take a look at the changes you've made and comment on your work.
3. The version control system might present you some merge conflicts if another colleague changed the same lines of the code as you and merged to main before you. There is nothing to worry about, these are usually easily resolved.

Once tests are passed, and your teammates have given you green light, you are safely (or at least the safest way we know of) merging your changes to main!

School & Personal Projects

Let's explore some use cases of branching where there is a small number contributors or just a single contributor to a project. Personal and school projects are good examples of these.

1. The first and obvious advantage is that you prevent pushing breaking changes to the main branch and not blocking your teammates from continuing development. So whenever someone pulls main to their local there is a high possibility that it will be a working version, trading off the latest (but possibly buggy) version. Especially if your repo is configured to have continuous deployment (CD), pushing breaking changes to main will take your application down, which is the nightmare.

2. Some changes or features might not behave like how you envisioned them to be. Introducing them in a branch, testing and seeing how they actually work in your application before merging to main will give you better flexibility to control your product. You might also want to delay the release of a feature which you can do easily with branching.

3. When your application grows bigger and there is a production version that real life customers are using, you will need different environments for development and staging. In these cases, you might want to keep seperate branches for staging and dev so that your team can work on these while keeping the main version unchanged. An advantage with this approach is that if there is a hotfix to be made, it can be easily applied since the production version is always kept in main and other branches can rebase with main to get the hotfix and keep their staging and dev changes.

While it may seem like a hassle at first, branching is actually helping instead of complicating the process.

Open Source Software

Open source software is a great example of why we can't let everyone just push to main: it would be disastrous to update the source code without an approval mechanism. In many open source contributions, you are not directly allowed to push to a branch in that repo. You are first required to fork (or copy to your account) the repo to your account and then introduce your changes and then open a Pull Request from the version hosted in your account plus the changes, to the main branch of the original repo, which might look like this.

PR from my-username/project:my-branch to organisation/project:main

I hope these use cases across different project settings will help you have a better understanding of branching and why it's so important. Don't forget to git checkout my-other-posts, see ya 👋 .