Complete Guide to Git Rebasing Feature Branches onto Other Feature Branches

Overview of Git Rebase Operations for Feature Branches

In distributed version control systems, Git's rebase functionality serves as a powerful branch integration tool, particularly suited for code synchronization between feature branches. When developers work concurrently on multiple feature branches, the need often arises to apply changes from one branch to another, with rebase providing cleaner historical records compared to merging.

Branch Structure Analysis and Requirement Definition

Consider the following branch topology:

a -- b -- c                  <-- Master
     \     \
      \     d -- e           <-- Branch1
       \
        f -- g               <-- Branch2

In this scenario, the developer discovers that Branch1 requires integration of changes from Branch2. The objective is to rebase Branch2's commits (f and g) after Branch1's latest commit e, forming a linear history:

a -- b -- c                  <-- Master
           \
            d -- e -- f -- g <-- Branch1

Correct Rebase Operation Steps

Based on best practices, the correct operational workflow to achieve the above objective is as follows:

First, switch to the target branch Branch2:

git checkout Branch2

Then execute the rebase operation to apply the current branch's (Branch2) changes on top of Branch1:

git rebase Branch1

This operation produces the following branch structure:

a -- b -- c                      <-- Master
           \
            d -- e               <-- Branch1
           \
            d -- e -- f' -- g'   <-- Branch2

Technical Details of Rebase Operations

The essence of Git rebase involves moving a series of commits from one base point to another. In the above operation:

The git rebase Branch1 command performs the following operations:

• Finds the common ancestor commit b between the current branch (Branch2) and the target branch (Branch1)
• Saves all commits from Branch2 after the common ancestor (f and g)
• Resets Branch2 to Branch1's latest commit e
• Reapplies the saved commits sequentially onto the new base

Since commits are reapplied on a new base, their SHA-1 hash values change, which is why they appear as f' and g' in the result.

Conflict Resolution Strategies

During the rebase process, if conflicts exist between Branch2's commits and Branch1's changes, Git pauses the rebase process and prompts the user to resolve conflicts. The conflict resolution workflow is as follows:

When Git detects a conflict:

Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Resolve all conflicts manually, then mark them as resolved using
"git add/rm <conflicted_files>", then run "git rebase --continue"
You can instead skip this commit: run "git rebase --skip"
To abort and get back to the original state: run "git rebase --abort"

Specific steps for conflict resolution:

1. Edit conflicted files and manually resolve conflict content
2. Use git add to mark conflicts as resolved: git add file.txt
3. Continue the rebase process: git rebase --continue

If encountering complex conflicts that cannot be resolved, use git rebase --abort to completely cancel the rebase operation and restore the pre-operation state.

Impact of Historical Rewriting and Considerations

Rebase operations rewrite commit history, which brings several important impacts:

Commit hash value changes: Since commits are recreated on a new base, all rebased commits receive new SHA-1 hash values.

Remote repository updates: If Branch2 has already been pushed to a remote repository, historical rewriting requires forced pushing:

git push origin Branch2 --force

Team collaboration considerations: Force pushing on shared branches may affect other developers' work, therefore:

• Communicate with team members before rebasing
• Avoid frequent historical rewriting on public branches
• Consider using --force-with-lease as a safer forced push option

Advanced Rebase Techniques

For more complex branch scenarios, use the --onto parameter for precise control:

Syntax: git rebase --onto <newbase> <upstream> <branch>

Example: If only wanting to rebase part of Branch2's commits onto Branch1:

git rebase --onto Branch1 commit-f Branch2

This command rebases all Branch2 commits starting from commit-f (excluding commit-f) onto Branch1.

Rebase vs Merge Comparison

When choosing between rebase and merge, consider the following factors:

Rebase advantages:

• Creates linear, clean commit history
• Avoids unnecessary merge commits
• Facilitates code review and issue tracking

Merge advantages:

• Preserves complete historical context
• Does not rewrite commit history
• Safer for team collaboration

General recommendation: Use rebase on personal feature branches to maintain clean history, and use merge when integrating into shared branches to preserve complete history.

Best Practices Summary

Based on practical development experience, the following rebase best practices are recommended:

1. Ensure working directory is clean before rebasing, check using git status
2. Regularly rebase from main branch to keep feature branches updated
3. Create backup branch before rebasing: git branch backup-branch
4. Use interactive rebase to organize commits: git rebase -i
5. Use forced push cautiously in team environments, prioritize collaboration-friendly workflows

By mastering these techniques and strategies, developers can effectively use Git rebase to manage code integration between feature branches while maintaining clear project historical records.