git-rebase
Integrate changes from one branch onto another
TLDR
Rebase the current branch on top of another specified branch
Start an interactive rebase, which allows the commits to be reordered, omitted, combined or modified
Continue a rebase that was interrupted by a merge failure, after editing conflicting files
Continue a rebase that was paused due to merge conflicts, by skipping the conflicted commit
Abort a rebase in progress (e.g. if it is interrupted by a merge conflict)
Move part of the current branch onto a new base, providing the old base to start from
Reapply the last 5 commits in-place, stopping to allow them to be reordered, omitted, combined or modified
Auto-resolve any conflicts by favoring the working branch version (theirs keyword has reversed meaning in this case)
SYNOPSIS
git rebase [options] [upstream] [branch]
PARAMETERS
upstream
The branch to rebase onto. Defaults to the configured upstream of the current branch.
branch
The branch to rebase. Defaults to the current branch.
-i, --interactive
Enter interactive mode, allowing commit editing, reordering, and squashing.
--onto newbase
Rebase onto newbase instead of the upstream.
--root
Rebase all commits reachable from branch since the beginning of its history.
--continue
Continue the rebase after resolving conflicts.
--skip
Skip the current commit and continue the rebase.
--abort
Abort the rebase operation and return to the original branch state.
--strategy strategy
Use the given merge strategy.
--committer-date-is-author-date
Use the author date of the commits instead of the committer date for rebasing.
DESCRIPTION
The git rebase command integrates changes from one branch into another. Unlike git merge, which creates a merge commit, rebase rewrites the commit history of the target branch to appear as if it branched off the source branch more recently. This results in a linear project history, which can be easier to follow. However, it's crucial to avoid rebasing commits that have already been pushed to a shared repository, as it can create inconsistencies and complicate collaboration for other developers, since rebasing changes the commit hashes. Rebasing is often used to clean up a feature branch before merging it into the main branch, ensuring a cleaner, more linear history. Interactive rebase (git rebase -i) offers fine-grained control, allowing you to edit, reorder, squash, or drop commits. A common workflow is to rebase a feature branch onto the latest commit of the main branch to incorporate recent changes and resolve any conflicts before merging. Rebase should be handled with care and awareness of its implications on shared commit histories.
CAVEATS
Rebasing public branches can lead to severe problems for collaborators. Only rebase branches you are working on locally and haven't shared with others.
WORKFLOW EXAMPLE
1. Create a feature branch: git checkout -b feature-branch.
2. Make changes and commit them.
3. Update your branch with the latest changes from main: git rebase main.
4. Resolve any conflicts.
5. Optionally, use interactive rebase: git rebase -i main to clean up the commit history.
6. Push the rebased branch. In some cases a force-push is needed: git push --force.
7. Merge the feature branch into main: git checkout main; git merge feature-branch.
INTERACTIVE REBASE
Interactive rebase (git rebase -i) opens an editor showing the commits to be rebased. Each line represents a commit and starts with a command: pick, reword, edit, squash, fixup, drop, break, label, reset and merge. These commands dictate how each commit is handled during the rebase process.