Git 101: Branching for Beginners

If you read my article “Git 101: Version Control for Absolute Beginners,” you may already be used to using Git for your own projects. Now, imagine you’re working on a project with a team of people, with multiple developers making commits to one repository–how do you avoid overwriting someone else’s code, or making changes that conflict with another person’s work?! The answer is branches!

Git branches are like separate paths or versions of your project’s code that allow you and your teammates to write code without interfering with each other’s work. It’s similar to having multiple copies of your project where each person can make changes independently.

Repositories start with a “main” branch, sometimes called the “master” branch. This branch should always represent the most stable, working, complete version of your project. It contains the version of the code that has been tested and is reliable. Usually, no one on the team will be allowed to make changes to the main branch directly–there will be a code review process where any potential changes must be signed off on by one or two other team members before new work can be committed to the main branch. That’s not what this article is about, though….

Let’s say that you’re assigned to implement a new feature for a project. Instead of working directly on the main branch and making commits there, you’ll want to create a new branch specifically for your work on the feature. This new branch splits off from the main branch, copying the code from the main branch to your new branch. When you make commits to the new branch, it’s a different version of the code than what is on the main branch–like your own personal parallel universe, where you can make changes without affecting the main branch or the work of your teammates.

Once you’re done working on your feature, how do you get the code from your branch back to the main branch? You’ll perform what is called a ‘merge’, taking the changes you made in your branch and combining them with the code in the main branch. Git will ‘diff’, or compare, the code in your branch and the code in the main branch, and apply any changes you have made that are different from the existing main branch code, so that your new feature becomes part of the stable codebase. (Again, in a professional environment, there will usually be a review process in place that you’ll need to pass before your feature code is merged into the main branch.)

The great thing about branches is that you can have tons and tons of them! Everyone on your team can create their own branches to work on, and when they’re ready, they can merge their work into the main branch.

Git keeps track of the changes made in each branch, and allows you to switch between branches easily. It also provides tools for resolving ‘merge conflicts’–issues that may come up then merging two branches together. When you experience a merge conflict, it means that Git has found a place in the code where both branches have made changes, and it needs you to decide which version of the code to keep.

Using Branches

Create a new branch: to create a new branch, open a terminal and navigate to your project’s git repository. Then, use the ‘git branch’ command to create a new branch, replacing with the name you want to use for your branch:

git branch <branch-name>

Switch to your new branch: The ‘git branch’ command creates a new branch, but doesn’t switch over it. Use the ‘git checkout’ command to switch to your new branch, which will set your new branch to the active branch that you are working on:

git checkout <branch-name>

Do work: Now that you’re on your new branch, you can start making changes to the code. Your branch is like your own personal copy of the codebase, so you can add, change, and delete code and files as needed.

As you’re working, commit your changes on a regular basis to make sure you don’t lose any work. Any commits you make on your new branch will only be saved on that branch, and will not affect the main branch.

Push your changes: Once you’ve committed your changes, you might want to push your branch to a remote repository like GitHub or BitBucket. You’ll need to use the branch name to push your branch to the remote repository:

git push <repository-name> <branch-name>

Merge changes: When you’re done working on your branch and want to merge your changes into the main branch, switch to the main branch using the ‘git checkout’ command. Then, once you’re on the main branch, use the ‘git merge’ command to merge your branch into the main branch:

git checkout main
git merge <branch-name>

This ‘git merge’ command compares the changes from your branch and the main branch, and then applies your changes to the main branch. Git will attempt to automatically merge the changes, but if there are conflicts, you’ll get an error message, and git will go into a ‘merge state’. You’ll need to resolve the merge manually before being able to complete the merge–which I’ll go into detail on in a later article!

Conclusion

Git branches are an important thing to familiarize yourself with, because they are commonly used by professional developers to manage shared work! Using branches allows teams to work on different features without interfering with the stable version of the codebase, and allows developers to make changes and experiment independently. The flexibility and control that git offers make it an essential part of any development team’s workflow, allowing for easy and efficient collaboration