Git Branching — แตกกิ่งก้านสาขาให้เป็นระบบGit Branching — Branching Out, With a System

git branch feature-login

git checkout feature-login

# หรือแบบสั้นกว่า (สร้าง + สลับในคำสั่งเดียว)
git checkout -b feature-login

git switch feature-login
git switch -c feature-login  # สร้าง + สลับ

git branch       # ดูเฉพาะ local
git branch -a    # ดูทั้ง local + remote

git branch -d feature-login   # ลบ (ถ้า merge แล้ว)
git branch -D feature-login   # ลบบังคับ (ยังไม่ merge ก็ลบ)

git checkout main
git merge feature-login

<<<<<<< HEAD
console.log("version from main");
=======
console.log("version from feature");
>>>>>>> feature-login

# สร้าง + สลับ branch
git switch -c feature-name

# push branch ไป remote
git push -u origin feature-name

# ดึง branch จาก remote
git fetch origin
git switch feature-name

# merge กลับ main
git switch main
git merge feature-name

# ลบ branch (local + remote)
git branch -d feature-name
git push origin --delete feature-name

# ดู branch graph สวยๆ
git log --oneline --graph --all

Earlier we talked about the fundamentals of Git — what it is, why we use it, and how commits and repositories fit together. Once you can use Git, the next question arrives: if several people are working on the same project, or you want to try a new feature without breaking the main code, what do you do?

The answer is branching — growing a branch off the main line of code so you can work separately, then merging it back later.

---

What Is a Branch?

A branch in Git is simply a pointer to one commit. When we create a new branch, Git does not copy any files — it just creates a new pointer aimed at the existing commit, which makes creating a branch extremely fast and almost free in disk space.

From the example:

• main is the primary branch, holding commits A, B and C
• feature branched off C and then grew commits D and E of its own
• the two branches do not affect each other until they are merged

---

Why Branch At All?

1. Everyone can work at once

Suppose a team of three:

• the first person is building the login page
• the second is building the dashboard
• the third is fixing an urgent bug

If all three work on the same branch it turns into chaos — code collides, commits land on top of each other, and time disappears into resolving conflicts. But if each person grows their own branch, they work independently and merge back when they are done.

2. Try new things without risk

Want to attempt a big refactor? Grow a branch and experiment. If it falls apart, just delete the branch — main is untouched.

3. Review code before merging

On a real team we never merge straight into main. We open a Pull Request (PR) so someone else can review the code first, and that requires a branch.

---

The Basic Commands

Git's branch commands are simple — create, switch, list, delete, and that is all four of them. Because a branch in Git is only a pointer (no files are copied), everything is fast no matter how large the project is:

Create a New Branch

git branch feature-login

This creates a branch named feature-login, but we are still standing on the branch we started from.

Switch to Another Branch

Switching branches changes the working directory to that branch's files immediately — as if you had opened a different folder, except that Git swaps the files for you very quickly:

git checkout feature-login

# or the shorter form (create + switch in one command)
git checkout -b feature-login

In newer versions of Git (2.23+) you can use git switch instead:

git switch feature-login
git switch -c feature-login  # create + switch

List Every Branch

See which branches exist right now; the * marks the one you are on. Add -a to see the remote branches too:

git branch       # local only
git branch -a    # local + remote

Delete a Branch

A branch that has been merged should be deleted — otherwise the branch list ends up as long as a horse's tail. Use -d (safe delete — must already be merged) or -D (force delete — removes it even unmerged):

git branch -d feature-login   # delete (if already merged)
git branch -D feature-login   # force delete (even if not merged)

---

Merge — Bringing a Branch Back

When the work on a feature branch is finished, the code has to come back into main — that is a merge. Git has two ways of doing it: fast-forward (move the pointer forward — the simplest case) and a three-way merge (create a new merge commit — for when both branches have commits of their own):

git checkout main
git merge feature-login

Fast-Forward Merge

If main has gained no new commits since the branch was created, Git simply moves the pointer forward. That is called a fast-forward:

Three-Way Merge

If main has picked up new commits as well, Git creates a merge commit to join the two branches:

Here M is the merge commit that brings the two branches together.

---

Merge Conflict — When Code Collides

Conflicts are normal — do not be afraid of them! One happens when both branches changed the same line of the same file: Git does not know which version to keep, so it asks us to choose. How to avoid them: merge often, and never let a branch drift away from main for too long. And when one does turn up, it is easy to fix:

<<<<<<< HEAD
console.log("version from main");
=======
console.log("version from feature");
>>>>>>> feature-login

How to fix it:

1. open the conflicted file
2. decide which side of the code to keep (or combine both)
3. remove the <<<<<<<, ======= and >>>>>>> markers
4. git add, then git commit

---

Popular Branching Strategies

A branching strategy is the team's "rules" for how branches get used — there is no single right formula. Choose by team size, release frequency and risk tolerance. Most teams use one of these three:

1. Git Flow

The most structured of the three, with several kinds of branch (main, develop, feature, release, hotfix). It suits projects with a clear release cycle — mobile apps that have to be submitted to an app store, for instance — but it is too complex for a small team or a web app that deploys every day:

Branch	Role
main	the code currently deployed to production
develop	the branch that collects finished features
feature/*	a branch per feature
release/*	preparing a release (testing + bug fixes)
hotfix/*	urgent fixes to production

2. GitHub Flow

Far simpler than Git Flow — just main plus feature branches. Finish the work → open a PR → review → merge → deploy automatically. It suits teams that deploy often through CI/CD, and it is the strategy most teams should start with:

1. branch off main
2. work and commit
3. open a Pull Request
4. review and approve
5. merge into main
6. deploy

3. Trunk-Based Development

Simplest of all: everyone commits straight into main, but uses feature flags to turn features on and off instead. It suits highly experienced teams with strong CI/CD behind them.

---

Comparing the Branching Strategies

The strengths and weaknesses of each strategy side by side — pick the one that fits the team; none of them is wrong. A small team that deploys often picks GitHub Flow, a large team with a release cycle picks Git Flow, a strong team with solid CI/CD picks trunk-based:

	Git Flow	GitHub Flow	Trunk-Based
Complexity	High	Low	Very low
Best for	Long release cycles	Frequent deploys	Deploying every commit
Number of branches	Many (5+ kinds)	Few (main + feature)	Almost none
Drawback	Too complex for a small team	Poor fit for releases that need planning	Demands very good CI/CD

---

The Commands You Use Most — A Summary

The Git branch commands that come up most often — and it is fine not to memorise them, as long as you know what exists. Type git branch --help when you need it, or reach for a GUI tool such as VS Code, GitKraken or SourceTree:

# create + switch branch
git switch -c feature-name

# push the branch to the remote
git push -u origin feature-name

# fetch a branch from the remote
git fetch origin
git switch feature-name

# merge back into main
git switch main
git merge feature-name

# delete the branch (local + remote)
git branch -d feature-name
git push origin --delete feature-name

# see a nice branch graph
git log --oneline --graph --all

---

Summary

Git branching is a fundamental skill every developer has to master — whether you work alone or on a team of a hundred. Branches let people work at the same time without colliding, let you try new things without risk, and let code be reviewed before it is merged. Choose the branching strategy that fits your team, and the CI/CD pipeline will take care of the rest:

• a branch = a pointer to a commit → fast to create, cheap in space
• use branches to work in parallel, experiment, and review code
• merging brings a branch back → you may hit a conflict if the same file was changed
• choose a branching strategy to match your team size and deployment cycle
• merge often = fewer conflicts → a better life

In the next post we turn to rebase — another way of combining branches that leaves a cleaner commit history, but comes with some very important caveats! 🐕