This note aims to clarify our team's approach to using git rebase
for integrating changes from the main
branch into feature branches. The goal is to maintain a clean, linear commit history.
-
Local Feature Branches: Always use
git rebase
to bring your local feature branches up-to-date with the latest changes frommain
.git fetch origin git rebase origin/main
-
Before Pushing: Prior to pushing your local changes to the remote repository, rebase your feature branch onto
main
.git fetch origin git rebase origin/main
-
Conflict Resolution: If conflicts arise during the rebase, resolve the conflicts for each commit.
-
Force Push with Care: After a successful rebase, a force push will be necessary. Use the
--force-with-lease
option to ensure you don't overwrite others' work.git push origin <your-feature-branch> --force-with-lease
-
Never Rebase Public Branches: Rebasing rewrites history. Never use it on branches that multiple people are working on. Stick to using
git merge
for public or team branches. -
Avoid Blindly Force Pushing: Always use
--force-with-lease
instead of--force
to ensure you don't accidentally overwrite someone else's changes. -
Communicate: Before and after you rebase, communicate with your team. Make sure no one is about to push to the same branch, and let them know when it's safe to push again.
-
Double-Check: Before initiating a rebase, always make sure you have the latest version of the
main
branch. -
Backup: Before doing a rebase, it’s a good practice to create a backup of your current branch.
git branch backup-my-feature-branch
- Simplified and linear history.
- Easier to identify and understand changes.
Given the innovative and collaborative environment at XO, maintaining a clean and linear history can be particularly beneficial. It will facilitate a more efficient code review process and make it easier to understand the evolution of complex projects.