Introduction

Keeping a feature branch updated with changes from master or main reduces painful integration surprises later. The two standard approaches are merge and rebase, and both are valid when used intentionally. The important part is understanding history effects, conflict workflow, branch sharing rules, and what your team expects to see in pull requests.

Start with a Clean Local State

Before integrating upstream changes, confirm your working tree is clean.

git status

If you have local modifications, commit or stash them first. Integration commands with uncommitted edits increase conflict complexity and can hide mistakes.

Fetch latest remote references before any merge or rebase:

git fetch origin

Use origin/main or origin/master depending on your repository default branch name.

Method 1: Merge Upstream into Feature Branch

Merging preserves branch history and creates a merge commit when needed.

git checkout feature/login-improvements
git merge origin/main

If there are conflicts, Git pauses and marks files. Resolve conflicts, stage fixes, then continue by committing the merge.

git add path/to/file
git commit

Merge is often preferred in teams that value explicit integration points and avoid history rewriting.

Method 2: Rebase Feature Branch onto Upstream

Rebase reapplies feature commits on top of the latest upstream commit, producing a linear history.

git checkout feature/login-improvements
git rebase origin/main

When conflicts occur, resolve them and continue:

git add path/to/file
git rebase --continue

Abort if needed:

git rebase --abort

Rebase keeps history clean but rewrites commit hashes, so avoid rebasing commits already shared unless your team is comfortable with that workflow.

Merge vs Rebase in Practice

Choose based on collaboration context.

Use merge when:

• Multiple developers are already pushing to the branch.
• You want explicit merge commits for traceability.
• Team policy avoids rewritten public history.

Use rebase when:

• You want a linear story before opening a pull request.
• Branch is mainly private or only you are editing it.
• Team policy allows force push with safeguards.

After rebasing a pushed branch, force push safely:

git push --force-with-lease

Prefer --force-with-lease over raw force to avoid overwriting teammates unexpectedly.

One practical guideline is to rebase before review and merge after review only if the branch is actively shared. That keeps personal branch history clean without forcing history rewrites onto collaborators who are already building on top of the same branch.

Resolve Conflicts with Intention

Do not blindly choose one side in conflicts. Understand whether upstream introduced behavior changes your feature depends on.

Helpful conflict flow:

1. Open conflict file and read both sections.
2. Reconstruct the intended behavior, not only syntax correctness.
3. Run tests relevant to affected code.
4. Check git diff before finalizing.

If you see conflict markers across many files, pause and make sure you rebased or merged onto the expected upstream branch.

Keep Branches Updated Regularly

Large integration intervals create large conflict sets. A simple habit is syncing feature branches daily or before every substantial push.

git fetch origin
git rebase origin/main

Frequent small integrations are easier to review and safer to fix than one large catch up right before release.

Verify Before Pushing

After merge or rebase:

• Run tests.
• Run linters.
• Inspect commit graph quickly.

git log --oneline --graph --decorate -20

This confirms your branch points where you expect and avoids pushing confusing history.

If your repository now uses git switch, that is fine too. The branch update strategy does not change; only the checkout command syntax does.

Common Pitfalls

• Rebasing shared branches without team agreement.
• Forgetting to fetch before integrating and using stale upstream refs.
• Resolving conflicts mechanically without validating behavior.
• Force pushing with --force instead of --force-with-lease.
• Waiting too long to sync and creating large avoidable conflict sets.

Summary

• Keep feature branches current using merge or rebase based on team policy.
• Merge preserves explicit integration history.
• Rebase creates linear history but rewrites commit hashes.
• Fetch first, resolve conflicts deliberately, and verify with tests.
• Integrate frequently to reduce conflict volume and risk.