Branches - Parallel Lines of Development
Branches help you to manage parallel work by multiple users
Imagine your project as a river flowing steadily toward its final destination. A branch in Git is like digging a new channel alongside that river—allowing you to explore a different path or try out an idea without disturbing the main flow. By creating a branch, you tell Git, “I’d like to work on this feature or experiment over here, independently of what everyone else is doing on the main path.” Each branch carries its own series of commits, so you can develop a new feature, fix a bug, or simply experiment, all while keeping the main branch clean and stable.
To create a new branch, you use the git branch command followed by the name you choose for this separate line of work. For example, if you decide to add a dark‐mode theme to your website, you might run git branch dark-mode. This command registers a new branch in Git’s history, but it doesn’t yet move your files over to that branch. Think of it as putting a flag in the riverbank marking the entrance to your new channel.
Switching into your new branch is just as simple, and it’s when you actually begin working in that parallel channel. Older Git tutorials often recommend git checkout dark-mode, which tells Git to update your working folder so it matches the most recent commit on the dark-mode branch. Newer versions of Git introduce git switch dark-mode for the same purpose, which many find more intuitive. Once you’ve switched, any files you edit, add, or commit belong to the dark-mode branch only. Your work on “main” remains untouched until you decide to merge.
If you’d like to both create and switch to a branch in a single step, you can combine these actions: git checkout -b dark-mode or git switch -c dark-mode will both set up the branch and move you into it at once. When you’re done experimenting or have finished your feature, you can switch back to the main branch with git switch main (or git checkout main), and later merge your dark-mode work back into the main river of development. Branches thus give you the freedom to explore, build, and test without fear that you’ll break anything—because your main line of work flows on, safely isolated from each new idea.
When and Why to Use Multiple Branches
As you begin to rely on Git for your projects, you’ll quickly discover that branches are not just a convenient tool—they’re an essential way to keep your work organized, safe, and flexible. Imagine you’re working on a big class project and realize you’d like to try out a new layout for the webpage without risking the version you’ve already polished. By creating a separate branch, you have a private sandbox where you can build and experiment freely. If the new layout succeeds, you merge it back into the main branch; if it doesn’t work out, you simply abandon or delete the experimental branch, leaving the main project untouched and stable.
Branches are also invaluable in team settings. Suppose your lab group is dividing tasks: one student focuses on implementing a new data‐visualization feature while another student fixes formatting issues. Each person can work in their own branch—and even push those branches to the remote repository—so that their changes don’t interfere with each other’s work. When both tasks are complete, you merge each feature branch back into the main branch in a controlled way, so you can review, test, and resolve any conflicts before everything comes together. This parallel workflow prevents confusion, reduces errors, and makes it easy to see who contributed what.
Even when you’re working alone, you might keep branches for different purposes: one for ongoing work, one for stable “releases” of your project, and one for quick bug fixes. By isolating each line of development, you not only protect your main version from accidental breakage but also establish a clear history: you can see exactly when a feature was added, when a bug was fixed, and when a release was made. Ultimately, multiple branches turn your Git repository into a map of your project’s evolution, giving you the freedom to explore, collaborate, and maintain high quality without ever losing track of where you started or how you got here.
Merging Branches
When you’ve finished work on a feature or an experiment in its own branch and you’re happy with the results, it’s time to bring those changes back into your main line of development. This process is called a merge, and it tells Git to integrate the commits from one branch into another. Imagine two paths converging into a single road: merging takes all the new work you did on the side path and folds it into the main trail, preserving the history of both.
To merge, you first switch to the branch you want to update—often this is the main branch—by running git switch main. Once you’re on that branch, you type git merge dark-mode (or whatever your feature branch is called). Git then examines the series of commits on both branches, finds the most recent common ancestor commit (the last point where the branches diverged), and applies each new commit from your feature branch in order. If no one else has changed the same lines of the same files in the meantime, the merge happens automatically and you’ll see a short message confirming that the branches have been combined.
Sometimes the merge can be very simple, happening as a fast-forward: when no new commits exist on main since you created the feature branch, Git simply moves main’s pointer forward to where your feature branch is. In that case, there’s no need to weave together divergent histories—Git just updates the branch name. Other times, you’ll end up with a three-way merge, where Git needs to reconcile changes made independently on both branches. In either scenario, Git handles the mechanics for you, creating a new merge commit that has two parent commits: one pointing to the tip of the branch you merged in, and one pointing to the previous tip of your current branch.
After a successful merge, your main branch will include all the work from your feature branch alongside any other commits that were already there. You can then push these combined commits to the remote repository so everyone else sees the updated history. Merging not only unifies separate lines of work into a coherent whole but also preserves a clear record of when and how features were integrated—an invaluable guide for understanding your project’s evolution over time.
Merge Conflicts and How to Resolve Them
Every once in a while, when you try to merge one branch into another, Git will pause and let you know there’s a merge conflict. A conflict happens when Git cannot automatically reconcile changes because two branches modified the same part of the same file in different ways. For example, imagine you and a classmate both edit the sentence “Welcome to our project” in README.md—you change it to “Welcome to our Git adventure,” while they change it to “Welcome to our collaboration.” When Git tries to merge, it can’t decide which version you want, so it raises a conflict to ask you to choose.
When a conflict occurs, Git will stop the merge process and mark the conflicting file in your working directory. If you open that file, you’ll see special markers showing exactly where the conflict lies. It looks something like this:
The text between <<<<<<< HEAD and ======= shows what’s in your current branch (often the main branch), and the text between ======= and >>>>>>> feature-branch shows what’s in the branch you’re merging. Your job now is to edit this file to pick one of the versions, combine them into a new sentence, or write something completely different that makes sense. Once you’re happy with the result, you remove the conflict markers (<<<<<<<, =======, and >>>>>>>) so the file looks as you intend it to.
After you’ve fixed all conflicts in a file, you stage it with git add filename. Staging tells Git, “I’ve resolved the conflicts here—please include this updated file in the merge.” When all conflicted files are staged, you complete the merge by committing: running git commit will create the merge commit that ties everything together. Git will automatically generate a commit message like “Merge branch ‘feature-branch’” and include a note that conflicts were resolved.
In more complex projects, you might face conflicts in several files at once. The same process applies: open each marked file, decide how best to combine the changes, remove the markers, stage the file, and then commit. Some text editors and specialized merge tools offer a visual interface for resolving conflicts, showing you both versions side by side and letting you click to choose or edit parts. These tools can make conflict resolution feel less error-prone, especially when the changes are substantial.
While conflicts can seem intimidating at first, they are simply Git’s way of ensuring you consciously decide how to integrate overlapping work. By carefully reviewing each conflict, you maintain control over your project’s content and history. With practice, you’ll learn to resolve conflicts quickly and confidently, turning these occasional pauses into an opportunity to review and strengthen your code or documentation before moving forward.
Last updated