Branches and Merges - Practical Guide

A branch is a way to split off an independent line of development from the main code. You can add new features or fix bugs without affecting the main branch. When the work is done, you merge the branch back into main.

A merge is the operation that combines changes from another branch into the current branch.

Git Branch Concept

main ──●──●──────────────────●── (after merge)
              ↘                ↗
feature         ●──●──●──●

Development happens on a feature branch split from main, and then main receives the changes after the work is complete. This keeps unfinished code out of production.

Fast-Forward and Merge Commit

Type	Condition	Feature
Fast-forward (FF)	No new commits exist on main	History stays straight
Merge commit	New commits also exist on main	The merge itself is recorded

Merging with the CLI

Update main

Before starting work, always bring main up to date.

git checkout main
git pull origin main

Create a Branch and Work on It

git checkout -b feature/new-feature

The -b option creates a branch and switches to it. Using a prefix like feature/ makes the branch purpose easier to understand.

Work on the branch and commit:

# Edit files
git add .
git commit -m "Add new feature"

Merge into main

When the work is complete, switch back to main and merge:

git checkout main
git merge feature/new-feature

After the merge succeeds, push to the remote:

git push origin main

💡 You can delete the branch after merging because it is no longer needed: git branch -d feature/new-feature

Merging with GitHub Pull Requests

In team development, it is common to review changes through a Pull Request (PR) instead of merging directly.

1. Push the working branch to GitHub

   git push origin feature/new-feature

2. Open the repository page on GitHub and click New pull request
3. Choose main as the base and feature/new-feature as the compare branch
4. Enter a title and description for the PR
5. Click Create pull request
6. Team members review the code
7. If everything looks good, click Merge pull request

💡 PRs let other people review your changes and help prevent bugs before they land. Even if you work alone, getting used to PRs makes it easier to understand why a change was made later.

Resolving Conflicts

A conflict happens when both main and your branch change the same part of the same file. Git cannot decide automatically which version to keep, so you must resolve it manually.

When a conflict happens, the file will contain markers like these:

[main branch content]
[feature branch content]

In a real conflict, Git inserts markers such as <<<<<<< HEAD, =======, and >>>>>>> feature/new-feature.

Conflict Resolution Steps

1. Open the conflicted file in your editor
2. Find the section that includes <<<<<<<, =======, and >>>>>>>
3. Rewrite the file with the content you want to keep and remove all markers
4. Save the file
5. Stage and commit it

git add <fixed-file>
git commit

⚠️ Make sure you do not commit while the conflict markers such as <<<<<<< are still in the file.

6. Push again if needed

git push origin main

Branch Command Reference

git branch                     # Show the list of current branches
git branch feature/name        # Create a new branch (do not switch)
git checkout -b feature/name   # Create and switch to a new branch
git checkout main              # Switch to the main branch
git branch -d feature/name     # Delete a merged branch
git branch -D feature/name     # Force delete, even if not merged

FAQ

Q. Which name is correct, main or master?

Both are valid names. New GitHub repositories use main by default. Older repositories may still use master. Follow the settings used by your team or existing project.

Q. When should I delete a branch?

It is recommended to delete a branch after it has been merged. Too many unused branches make management harder. git branch -d branch-name deletes only branches that have already been merged.

Q. I am afraid of conflicts and cannot merge.

Conflicts are normal Git behavior. Take your time, check the conflicting lines in the editor, and fix them carefully. If needed, you can stop the merge and return to the original state with git merge --abort.