Mastering Git Branching: From Development to Production with Merge & Rebase

1. Normal Development Process

A typical version passes through dev, test, UAT, and master stages; each stage pulls a branch from master and pushes to its corresponding branch, keeping pre‑release and production code consistent while test may differ due to parallel version work.

2. Parallel Development of Multiple Versions

When several versions are developed simultaneously, branch management becomes more complex because each version has different release timelines.

With few backend developers (2‑3), a branch can be named service_20230130 and all developers work on it, merging local changes into dev; conflicts are manageable.

With more developers (5‑8), branches are named service_AB_20230130 (service + initials + date) so each developer works in their own branch, reducing interference during local testing; careful conflict resolution is required when merging to remote.

When many versions (4‑5 per month) exist, each new version’s local development branch merges code from the previously released remote branch, progressing sequentially.

3. Git Merge

The git merge command integrates the latest code from one branch into an older branch, synchronizing versions. Typically, developers merge master into a feature branch, creating a new commit only when conflicts arise.

Effectively, git pull equals git fetch plus git merge: fetch the latest remote branch and merge it into the current branch.

Teams favor merge for its simplicity and straightforwardness.

4. Git Rebase

Rebase, a personal favorite, “rewrites” history by moving a feature branch to start after the latest master commits.

The diagram shows rebase extending the feature branch onto the tip of master .

In multi‑developer scenarios, if others commit to master after you created a feature branch, git rebase places your commits after those new master commits, whereas merge would create a single merge commit.

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

⚠️ Do not rebase public branches, as it rewrites shared history and can confuse collaborators.

5. Summary

High code quality and disciplined version management are crucial; missing code before release can be dangerous. This guide aims to raise awareness of proper branch merging and encourage fewer bugs, continuous learning, and progress.