Introduction

Keeping a feature branch up to date with master is mostly about choosing one integration style and using it consistently. The two normal choices are merge and rebase. Both bring the latest master changes into your branch, but they produce different histories and different collaboration risks.

Start by Updating Local References

Before synchronizing your branch, refresh your remote-tracking information.

git fetch origin

That updates origin/master without changing your current branch. After that, switch to the branch you want to update.

git switch my-feature

If your repository uses main instead of master, substitute that name throughout. The workflow is the same.

Merge master Into Your Branch

The safest and most direct approach is to merge the latest master into your feature branch.

git fetch origin
git switch my-feature
git merge origin/master

This creates a merge commit when necessary and preserves the exact branch history. It is a good default when:

• the branch is shared with other developers
• you want to avoid rewriting commit history
• clarity about integration points matters more than a perfectly linear log

If Git reports conflicts, resolve them in the files, stage the resolutions, and then complete the merge.

git add conflicted-file.txt
git commit

That leaves a visible record that your branch was synchronized with master at that point.

Rebase Your Branch Onto master

If you prefer a linear history, rebase is often the better choice.

git fetch origin
git switch my-feature
git rebase origin/master

Rebase takes the commits that exist on my-feature but not on origin/master and reapplies them on top of the updated base. The result is a history that looks as though your branch work started from the latest master all along.

This is a good fit when:

• the branch is private or you control everyone using it
• you want a cleaner history before opening or updating a pull request
• your team prefers linear commit graphs

The tradeoff is that rebase rewrites commit history. If other people already pulled the old version of the branch, rebasing it creates coordination work.

Know When to Use Merge Versus Rebase

A practical rule is simple:

• merge shared branches
• rebase local or not-yet-shared branches

This is not a law of Git, but it prevents a lot of avoidable confusion. Teams get into trouble when they rebase branches that multiple people are already building on, then force-push without coordination.

If you do rebase a remote branch, you generally need to push with lease protection.

git push --force-with-lease origin my-feature

That is safer than plain --force because it refuses to overwrite remote changes you did not expect.

Keep Synchronization Frequent

Waiting until a branch is weeks behind master makes conflicts harder and integration risk larger. Short, regular syncs are easier to review and easier to resolve.

A lightweight rhythm is:

1. fetch regularly
2. integrate master into the feature branch every time the base branch changes materially
3. run tests after each sync

The tests matter. A conflict-free merge or rebase only proves the files combined syntactically. It does not prove the branch still behaves correctly.

Avoid Updating the Wrong Direction

A common mistake is merging the feature branch into master locally when the goal was only to update the feature branch. If your goal is “bring the latest base branch into my work,” make sure my-feature is checked out before you run merge or rebase.

A quick git status before the operation is cheap insurance.

git status

Common Pitfalls

• Rebasing a branch that other developers have already based work on, then force-pushing unexpectedly.
• Merging in the wrong direction because the wrong branch was checked out.
• Forgetting to git fetch first and integrating stale remote information.
• Treating a clean merge or rebase as proof that the updated branch is safe without rerunning tests.
• Switching between merge and rebase randomly so the branch history becomes hard to understand.

Summary

• To keep a branch updated with master, first git fetch origin and then merge or rebase.
• Merge is safer for shared branches because it does not rewrite history.
• Rebase creates a cleaner linear history but should be used carefully on published branches.
• Frequent synchronization reduces painful conflicts later.
• Always verify the current branch and rerun tests after integrating master.