Git Branching Explained: Base, Topic, and Parent Branches

In this post, we'll take a deep dive into core Git branching concepts, showcasing why they are absolutely indispensable for stress-free software development.

Let's jump right in by first identifying and distinguishing the key branch types, so you can clearly understand their role and value for any development team:

1. Base Branches
2. Topic Branches
3. Parent Branches

1. The Foundation: Base Branches

Imagine your project's main development path as the sturdy trunk of a tree, or the main highway in a bustling city. In Git, this is what we call a base branch.

A base branch is a long-lived, stable branch that represents the primary line of development for your project. You'll most commonly encounter branches named main (the modern default, replacing the older master) or develop. Think of it as the source of truth – the code that is either currently deployed to production, or is always in a deployable state.

You can have multiple base branches: a typical example is a development branch where work is done and then at some point merged into main, representing your production state that can be deployed.

The base branch serves as your project's unwavering foundation. It provides a consistent and reliable reference point for everyone on the team, ensuring that there's always a known good version of the code. This stability is crucial, as you don't want experimental or unfinished features breaking what's already working.

As the main line of work lives in your base branches, they serve as essential reference points for many functionalities that determine whether work has been integrated and whether it is safe to delete a topic branch. When using commands like git branch --merged <BRANCH> or git branch --no-merged <BRANCH>, it is important to run these for every base branch to gain an overview of which branches have been merged upstream and which have not.

In an upcoming version of Tower, this information will be used to automatically identify branches that have been merged.

2. Feature Focus: Topic Branches

Now, let's say you're building a new feature, such as a user authentication system, or maybe fixing a tricky bug. You definitely don't want to mess with the stable base branch while you're experimenting!

This is where topic branches come into play.

A topic branch is a short-lived branch that you create to work on a specific feature, bug fix, or experiment. When you type something like git checkout -b new-auth-feature main, you're essentially saying, "Hey Git, create a new branch called new-auth-feature based on the current state of main, and then switch me over to it!"

The lifecycle of a topic branch is straightforward: you create it, do your work, test it, and once it's complete and reviewed, you merge it back into your base branch. After the merge, the topic branch is typically deleted, keeping your repository tidy.

Topic branches allow you to work on your changes in a completely isolated environment, which is clearly the main advantage of working this way. If your new feature introduces unexpected bugs or doesn't pan out as planned, it's contained within the topic branch. You can fix it there or simply discard the branch without ever affecting the stable main branch.

Topic branches also provide a sensible way to collaborate. Multiple developers can work on different features simultaneously, creating their own topic branches so they don't step on each other's toes. This approach also has its advantages when it's time to review the code before merging, often through creating pull requests. Your teammates can review your changes, offer feedback, and approve them before they become part of the main codebase.

As a bonus, this approach contributes to a clean project history, as your base branch maintains a clear, understandable, and linear history of integrated features rather than a jumbled mess of individual commits.

3. The Lineage: Parent Branches

Every branch has a history, and part of that history is its parent branch. Simply put, the parent branch is the branch from which another branch was created. It's the immediate ancestor, defining the starting point and initial state of the new branch.

Most often, when you create a topic branch like feature/shopping-cart, its parent branch will be your base branch, main or develop. The new feature/shopping-cart branch inherits all the commits and files that were present in main at the moment it was created.

This relationship determines which changes will be exclusive to your topic branch compared to its parent branch. With Tower 14 for Mac, the parent branch is selected by default when using the "Compare" view, allowing you to see only the unique commits introduced by this feature branch.

If you have multiple base branches, a base branch can also have another base branch as a parent. Consider our example from above (in the "Base Branches" section): your develop’s branch parent would be main, as work ultimately always flows upwards to your main branch. The other way around, if main would receive changes from e.g. hotfix branches, develop would need those changes from main in order to stay in sync.

Tower 14 makes it easy to stay uptodate with the new "Update Branch" action.

The parent branch is usually the branch that your topic branch will be merged back into, unless you are using stacked branches (see below). In that case, the stacked branch will ultimately be merged back into the trunk branch after all stacked parents have been merged.

The Stacked Branches Workflow

While a new branch typically sprouts directly from your base branch, sometimes your work is so extensive, or involves multiple interdependent logical changes, that it benefits from a more layered approach.

This is where stacked branches, also known as "stacked pull requests", come into play.

These are a series of dependent topic branches. Instead of each new branch directly diverging from the base, they form a chain of dependencies.

It looks something like this:

In this scenario:

• refactor-payment-gateway's parent is main.
• implement-stripe-integration's parent is refactor-payment-gateway.
• add-subscription-plans's parent is implement-stripe-integration.

Each branch in the stack represents a distinct, logically isolated chunk of work, but they are built upon, and thus dependent on, the changes introduced in the "parent" branch below them in the stack.

Stacked Branches: Pros and Cons

Let's start with the good: Stacked Branches are a great solution when you're working on large features that can be overwhelming to review. By breaking them into a stack, each pull request (PR) for a branch in the stack is smaller and easier to understand, speeding up code reviews.

This allows for faster, uninterrupted development since you don't have to wait for the first part of a large feature to be reviewed and merged before starting work on related parts. This also enables you to ship parts of a larger feature incrementally, delivering value sooner.

Stacked branches can present some challenges, most notably the need for frequent rebasing to keep them up to date with the base branch. For this reason, additional tools are often recommended.

Good news — Tower not only supports Stacked Branches but can do the restacking automatically for you! This was introduced in Tower 12 for Mac and Tower 8 for Windows.

Specialized tools like Graphite can simplify the management of stacked pull requests. Tower is the only Git client with Graphite support, allowing for Stacked PR management without the need of using the Graphite CLI or the browser.

You can learn all about this integration in the 5-minute video below:

Best Practices for Branching

To maximize the benefits of branching, we would like to share some advice with you, along with some helpful Tower tips!

• Keep Topic Branches small: Focus each topic branch on a single, logical change. Smaller branches are easier to review and manage.

• Descriptive naming is recommended: Make an effort to use meaningful names for your branches, such as feature/user-profile-edits, bugfix/login-form-validation, or hotfix/critical-api-issue.

• Merge or Rebase frequently: Regularly update your topic branch with the latest changes from its parent (usually the base branch) to minimize complex merge conflicts later on.

With Tower, merging is as simply as dragging and dropping!

Keeping topic branches up to date has become even easier with the release of Tower 14 for Mac. By setting up parent/child relationships, Tower will notify you whenever your branch needs updating; When this occurs, you can simply click the "Update Branch" action instead of manually merging or rebasing branches.

• Always use pull requests for code review and integration: This ensures a thorough review process before changes hit the base branch.

With Tower, you can create a pull request by simply dragging and dropping the desired branch onto the "Pull Requests" workspace view.

And if you are an adopter of the Stacked Branches workflow, remember to always restack to keep your branches in sync by restacking often.

• Delete branches after merging: Once a topic branch is merged into your base branch, delete it from your local and remote repositories to keep things clean.

In Tower's "Branches Review" view, you can filter by "Fully Merged" to pinpoint the branches that can be removed without hesitation.

Final Words

By embracing the foundational stability of your Base Branch, the focused isolation of Topic Branches, and the logical structure provided by Parent Branches (even in complex stacked scenarios), you are setting yourself and your team up for safe experimentation, parallel feature development, and clear code reviews.

Follow these guidelines and our branching best practices to enjoy a development workflow that is more efficient, less stressful, and ultimately more productive.

For more Git tips and tricks, don't forget to sign up for our newsletter below and follow Tower on Twitter / X and LinkedIn! ✌️