Mastering Git: Effective Branch Management for Multi‑Version Development

Git is essential for daily code version management, with branches such as production, pre‑release, test, and development. The typical flow is dev → test → pre‑release → production, but many versions and multiple developers make remote and local branch management critical.

1. Normal Development Process

A standard version passes through dev, test, uat, and master. Each stage pulls a branch from master and pushes to the corresponding branch for release, keeping pre‑release and production code consistent while test may differ due to parallel development.

2. Parallel Multi‑Version Development

When several versions are developed simultaneously, branch management becomes more complex because each version has a different release schedule, affecting test and uat timing.

Typical scenarios:

With few backend developers (2‑3), create a branch from master named service_YYYYMMDD. All developers work on this branch, merge local changes into dev, and resolve conflicts as they arise.

With more developers (5‑8), name branches service_initials_YYYYMMDD so each person works in their own branch, preventing interference during local testing. Merging into remote branches requires careful conflict resolution and testing based on release priority.

When many versions (4‑5 per month) exist, sequentially merge the earlier released remote branch into the next version’s local development branch.

3. Git merge

The git merge command combines the latest code from one branch into an older branch, synchronizing versions.

Typical workflow: merge master into a feature branch. A new commit is created only when conflicts occur. git pull is equivalent to git fetch followed by git merge, fetching the latest remote branch and then merging it.

Developers favor this command for its simplicity and directness.

4. Git rebase

Many prefer git rebase, which “rebases” a branch onto another.

Rebase moves the feature branch to the tip of master.

If others have committed to master, rebase places your commits after those, while merge would combine all commits into a single new commit; this highlights the key difference.

When the local feature branch and remote master share the same history, rebase keeps the commit log clear and linear.

⚠️ Do not use rebase on public branches, as it pollutes shared history and can cause others to pull unexpected commits.

5. Summary

High code quality and proper version management are both essential. Missing code before release is risky; this article aims to raise awareness about careful branch merging. Wishing everyone a bug‑free new year, continuous learning, and steady progress.