Introduction

Keeping feature branches updated from master avoids late merge conflicts and keeps integration risk low. The two main update strategies are merge and rebase, each with different history behavior. A good team workflow picks one strategy for each branch type and applies it consistently.

Fetch First, Then Update

Always fetch remote state before updating local branches.

git fetch origin

This makes sure you are integrating latest remote master, not stale local data.

Check where you are:

git branch --show-current
git status

Commit or stash local changes before branch update operations.

Method 1: Merge master Into Feature Branch

Merge keeps branch history explicit and creates a merge commit when needed.

git checkout feature/my-work
git fetch origin
git merge origin/master

Pros:

• preserves exact historical branching context
• safer for shared feature branches

Cons:

• can create many merge commits
• history can become noisy in long-lived branches

Use merge when multiple developers collaborate on the same branch and history rewrite is undesirable.

Method 2: Rebase Feature Branch Onto master

Rebase replays your commits on top of latest master, producing linear history.

git checkout feature/my-work
git fetch origin
git rebase origin/master

Pros:

• cleaner linear commit history
• easier review and bisect in many teams

Cons:

• rewrites commit hashes
• unsafe on already-shared public branch unless team coordinates

If rebasing a branch already pushed remotely, you typically need force-with-lease:

git push --force-with-lease

Use force-with-lease, not plain force, to reduce accidental overwrite risk.

Conflict Handling During Update

Whether merging or rebasing, conflicts are normal in active repositories.

Conflict workflow for rebase:

1# after conflict
2git status
3# edit files and resolve markers
4git add <resolved-files>
5git rebase --continue

Abort if needed:

git rebase --abort

For merge conflicts, replace rebase --continue with commit after resolution.

Good practice is resolving conflicts in small frequent updates rather than one large end-of-sprint update.

Updating Many Branches Efficiently

If you maintain several branches, avoid automatic bulk operations without review. Instead:

• update active branches first
• skip archived branches
• verify CI after each update

A manual but consistent rhythm prevents accidental conflict propagation and hidden broken states.

Team Policy Recommendations

Define branch policy in repository docs:

• whether feature branches should rebase or merge
• when force-with-lease is allowed
• how often branches should sync from master
• required tests before pushing updated branch

Clear policy reduces tool-level arguments and keeps history predictable.

master Versus main

Many repositories now use main as default branch. If your repo uses main, substitute origin/main in all commands.

Verify default branch:

git remote show origin

Do not assume branch naming conventions across repos.

Recovery Tips

If update goes wrong:

• use reflog to recover pre-rebase state

git reflog

• create safety tag before risky history rewrite

git tag backup-before-rebase

These small safeguards reduce panic during complicated conflict sessions.

Common Pitfalls

• Merging stale local master instead of fetched remote branch.
• Rebasing shared branches without team coordination.
• Using plain force push after rebase and overwriting teammates’ commits.
• Letting branches drift too long and facing large conflict bursts.
• Mixing merge and rebase randomly without repository policy.

Summary

• Sync feature branches from latest remote master regularly.
• Use merge for shared-history safety and rebase for linear history.
• Handle conflicts incrementally and verify CI after updates.
• Apply force-with-lease carefully after public rebases.
• Standardize team policy so branch updates are predictable and low-risk.