Phase 5: Advanced & Professional Skills

Branching strategies: trunk-based, GitFlow & feature branches

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you and your friends are building a super cool, giant LEGO castle together. It’s a huge project, and you all want to add different things at the same time: one person wants to build a tall tower, another a secret dungeon, and someone else a sturdy drawbridge. Now, if everyone just grabs pieces and starts building directly onto the same main castle, it could get really messy! Someone might accidentally knock over a wall, or a new part might not fit, breaking the whole castle before it's even finished. That's why we need smart ways to organize our building.

One popular way is like using separate playmats for your individual projects. This is called using "feature branches." When you want to add a new tower, you get your own playmat and build your tower there. Your friend builds their drawbridge on their own playmat. You each work on your part in your own space, making sure it’s perfect and stable without worrying about what anyone else is doing. Once your tower is completely finished, looks great, and everyone agrees it's ready, you carefully attach it to the main castle. This keeps the main castle strong and playable all the time, because new parts only get added once they're totally ready and checked.

Another super-fast way to build is called "Trunk-Based Development." Think of it like this: the main castle is always the 'trunk' or main part, and it should always be ready to play with. Instead of building a whole big tower on a separate mat, you focus on adding very small, tiny pieces directly to the main castle, many times a day. Maybe you add just one new window, then a tiny flag, then a small bush. You build these little things quickly, making sure each small piece fits perfectly, and immediately add it to the main castle. Sometimes, if a piece isn't quite finished, you might put a tiny "do not disturb" sign on it (these are called feature flags) so people can still play with the rest of the castle without bumping into the unfinished part.

These building strategies help everyone work together smoothly. They mean you and your friends can add amazing new things to your castle very often, without ever accidentally breaking the main structure. So, when you’re building big projects with a team, you’ll learn how to choose the best way to add your pieces, making sure everything comes together perfectly!

When multiple developers work on a project, efficiently managing code changes is crucial. Git branching strategies provide structured ways to handle this, ensuring stability while allowing new features to be built. The most fundamental approach, often used by default, involves Feature Branches. Here, for every new feature, bug fix, or improvement, you create a dedicated branch (e.g., git checkout -b my-new-feature). You work on this branch in isolation, make your commits, and once complete and reviewed, merge it back into the main development branch (usually main or develop). This keeps your work separate from the main codebase until it's ready, preventing accidental breakage.

Moving towards more frequent integration, Trunk-Based Development (TBD) emphasizes keeping the main branch (the 'trunk') always deployable. Teams using TBD commit directly to main or merge very short-lived feature branches into main multiple times a day. The key is to integrate code frequently, ideally after small, isolated changes, and often use 'feature flags' to hide unfinished features from users. This strategy significantly speeds up continuous integration and delivery (CI/CD) and reduces complex merge conflicts, making it popular for agile teams and rapid frontend deployments.

On the more structured end, GitFlow is a defined branching model suitable for projects with scheduled release cycles. It uses two main long-lived branches: main (for production-ready code) and develop (for integrating new features). Features are built on feature branches off develop, and when a release is prepared, a release branch is created from develop. Urgent fixes to main are handled via hotfix branches. While GitFlow offers clear separation and control, its complexity and overhead can be significant, especially for smaller teams or projects favoring continuous deployment. Understanding these strategies helps you choose the best fit for your team and project goals.

Key Takeaways

  • Feature branches isolate new work, keeping the main codebase stable until changes are ready.
  • Trunk-Based Development promotes frequent, small merges to the main branch for faster integration and CI/CD.
  • GitFlow is a structured model with dedicated branches for features, releases, and hotfixes, suitable for projects with defined release cycles.
  • The choice of strategy depends on team size, project complexity, and desired release cadence.

Code Example

bash
# Create a new feature branch from main
git checkout main
git pull origin main
git checkout -b feat/add-dark-mode

# Make your changes and commit
# (e.g., add CSS for dark mode, update JavaScript toggle)
git add .
git commit -m "feat: Implement dark mode toggle"

# Push your feature branch to the remote repository
git push origin feat/add-dark-mode

# (After code review and merging via a Pull Request)
# Switch back to main and delete the local feature branch
git checkout main
git branch -d feat/add-dark-mode
# Delete the remote feature branch
# git push origin --delete feat/add-dark-mode

How this code works

This code illustrates a standard "feature branching" workflow, where development for a new feature, like adding dark mode, happens in isolation from the main codebase. The process starts by making sure the local main branch is current, fetching any updates from the shared remote repository using git checkout main followed by git pull origin main. This initial sync is a critical step, ensuring new work begins from the latest approved version and helps avoid potential conflicts down the line. A dedicated new branch for the feature, named feat/add-dark-mode, is then created and immediately switched to using the git checkout -b command, a convenient shortcut that combines creation and switching into one action.

Once on the new feat/add-dark-mode branch, changes for the feature are implemented, staged with git add ., and saved into the branch's history using git commit -m. The branch's progress is then shared with the remote repository via git push origin feat/add-dark-mode, making it visible to teammates for collaboration and code review. A subtle but important detail for beginners is the cleanup process. After the feature is integrated into main (typically through a Pull Request), the feature branch is first deleted locally with git branch -d feat/add-dark-mode after switching back to main using git checkout main. The remote copy of the branch, however, requires a separate git push origin --delete command to be removed, as deleting a local branch does not automatically remove its remote counterpart.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control.

Back to Frontend Developer Roadmap