git-rebase

Integrate changes from one branch onto another

TLDR

Rebase the current branch on top of another specified branch

$ git rebase [new_base_branch]

Start an interactive rebase, which allows the commits to be reordered, omitted, combined or modified

$ git rebase [[-i|--interactive]] [target_base_branch_or_commit_hash]

Continue a rebase that was interrupted by a merge failure, after editing conflicting files

$ git rebase --continue

Continue a rebase that was paused due to merge conflicts, by skipping the conflicted commit

$ git rebase --skip

Abort a rebase in progress (e.g. if it is interrupted by a merge conflict)

$ git rebase --abort

Move part of the current branch onto a new base, providing the old base to start from

$ git rebase --onto [new_base] [old_base]

Reapply the last 5 commits in-place, stopping to allow them to be reordered, omitted, combined or modified

$ git rebase [[-i|--interactive]] [HEAD~5]

Auto-resolve any conflicts by favoring the working branch version (theirs keyword has reversed meaning in this case)

$ git rebase [[-X|--strategy-option]] theirs [branch_name]

SYNOPSIS

git rebase [options] [upstream] [branch]

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.