loading...
Cover image for Understanding Git Branches (Illustrated)

Understanding Git Branches (Illustrated)

erikaheidi profile image Erika Heidi Updated on ・2 min read

Git Illustrated (4 Part Series)

1) Stage. Commit. Push. A Git Story (Comic) 2) Understanding Git Branches (Illustrated) 3) Pick. Squash. Drop. Rebase! (Comic) 4) A Git from the Future (Comic)

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 :)

Git Illustrated (4 Part Series)

1) Stage. Commit. Push. A Git Story (Comic) 2) Understanding Git Branches (Illustrated) 3) Pick. Squash. Drop. Rebase! (Comic) 4) A Git from the Future (Comic)

Posted on by:

erikaheidi profile

Erika Heidi

@erikaheidi

Code sorceress and machine enchantress. Passionate about writing and creating technical content for a variety of audiences.

Discussion

markdown guide
 

Wow! These illustrations are incredibly well done - both informative and gorgeous!

 
 

Great illustrations. I think illustrations on "merging" vs. "rebasing" may help teams out a lot (and explaining how to resolve merge conflicts); since the last paragraph discussed merge requests, it may be an appropriate place to continue. Thanks for doing this.

 

Hey Erika, great post! Especially your point on always using pull requests when suggesting changes in a code base!

 

Beautiful drawings!

But the post is too short, imo, and doesn't do a good job of explaining branching in git (that's what I expected the post to do based on the title).

It's more about why/when branches are used.

 

Thank you for your feedback, these are really aimed at beginners. I have added a few links for more comprehensive guides!

 

Awesome illustrations, what do you use to make them?

 

These were hand-drawn and painted with watercolors, than scanned for final touches. I can't find joy in digital arts!

 

Could you make a article on 'rebase'?

 
 

These illustrations are amazing: you have a gift! I’ll admit I came for baby Yoda 😀