Understanding Git Branches (Illustrated)

Understanding Git Branches (Illustrated)

Posted 3 years ago in

In a previous post, we talked about the process of submitting changes to a remote Git repository. We've seen that this process is done in three steps: 1) stage. 2) commit. 3) push.

In a small project with a solo contributor, it's not uncommon that these changes are pushed directly into master. But when multiple developers need to work in the same Git repository, it is important to define a process that leverages parallel collaboration. That's when branches become essential.

Git Tree Illustration

Not all trees are the same, but they all start small. In a typical Git repository, code grows as a tree. Features are implemented in development branches that are eventually merged into a master branch.

Whenever working on a team, whether if it's in an open source project or a corporate setting, it's always a good practice to create a new branch (usually based on master) and start from there.

Once you're finished with your changes, you can then push your branch to the remote repository and create a new pull request. A pull request is a formal request for merging your branch into master.

Pull Request Mando and Baby Yoda

Although it is possible to push and merge a branch directly into "master", creating a pull request is usually the way to go when suggesting changes in a codebase.

Opening a pull request creates an opportunity for code review and actionable feedback; that's why it became a standard procedure for collaborating in most open source projects.

For a more in-depth understanding of Git branches, please check these docs or have a look at this quick reference guide.

Any Git topic you'd like to understand better? Leave your suggestion for my next comic in the comments :)