GIT FIELD GUIDE // 03
Update and publish a Git feature branch without losing remote work
Fetch remote state, rebase deliberately, and use force-with-lease only when rewritten history must be published.
Your local work must safely synchronize with a remote team repository.
BEFORE YOU START
Prerequisites and boundaries
- Commit or stash local changes before rebasing.
- Confirm the remote name and the branch that should be used as the new base.
- Coordinate with collaborators before rewriting a branch that other people may use.
OPERATIONAL REASONING
Why this sequence matters
The goal is not merely to memorize commands. Each inspection, change, and verification step reduces a different failure mode.
Fetch before comparing
Fetching updates remote-tracking references without immediately changing the current branch.
Rebase the feature, not the shared base
Replaying feature commits produces a linear review while leaving the shared main branch intact.
Lease the forced update
force-with-lease refuses to overwrite remote commits that were not part of the last fetched state.
STANDARD PROCEDURE
Update a feature branch with the latest remote main branch before opening a review.
Confirm local state, fetch remote references, move to the feature branch, rebase it, and inspect the rewritten history.
- 01
git statusGit status documentation ↗ - 02
git fetch originGit fetch documentation ↗ - 03
git switch feature/loginGit switch documentation ↗ - 04
git rebase origin/mainGit rebase documentation ↗ - 05
git log --oneline --graphGit log documentation ↗
INCIDENT RESPONSE
Publish a rebased feature branch while protecting teammates from an unsafe force push.
Fetch before rebasing, publish rewritten history with force-with-lease rather than force, then verify the local state.
- 01
git fetch originGit fetch documentation ↗ - 02
git switch feature/loginGit switch documentation ↗ - 03
git rebase origin/mainGit rebase documentation ↗ - 04
git push --force-with-lease origin feature/loginGit push documentation ↗ - 05
git statusGit status documentation ↗
COMMON FAILURE MODES
What usually goes wrong
- A plain force push silently replaced a teammate’s newer remote commits.
- The wrong branch was rebased because the current branch was not verified.
- Conflict resolution changed behavior but the result was not tested before pushing.
VERIFICATION
Evidence to collect
- git status reports no unresolved rebase or merge state.
- git log --oneline --graph shows the feature commits on the intended base.
- A final fetch confirms the remote-tracking branch matches the published result.