In-depth Analysis of Changing Branch Base Using Git Rebase --onto Command

Problem Scenario Analysis

In software development processes, branch management constitutes a core aspect of version control. Consider the following typical scenario: a developer creates a demonstration branch demo from the main branch master for feature demonstration, then mistakenly creates a product branch PRO from the demo branch. The initial branch structure appears as:

(commit 1) - master
                \-- (commit 2) - (commit 3) - demo
                                                \-- (commit 4) - (commit 5) - PRO

The objective is to move the base of the PRO branch from demo to master, forming the ideal structure:

(commit 1) - master
                |-- (commit 2) - (commit 3) - demo
                \-- (commit 4) - (commit 5) - PRO

Direct execution of git rebase master fails to achieve the expected outcome because this command by default reapplies all commits of the current branch relative to its immediate parent.

Core Solution: git rebase --onto

The git rebase --onto command is specifically designed to handle branch base change requirements. Its basic syntax structure is:

git rebase --onto <newBase> <oldBase> <feature/branch>

Where:

• <newBase>: Target base branch
• <oldBase>: Original base branch
• <feature/branch>: Target branch requiring movement

Specific Implementation Steps

For the described problem, execute the following operation sequence:

git checkout PRO
git rebase --onto master demo PRO

This command performs the following logical operations:

1. Identifies all commits from the fork point after demo branch up to and including PRO branch (namely commit 4 and commit 5)
2. Reapplies these commits onto the latest commit of the master branch
3. Updates the PRO branch pointer to point to the newly created commit sequence

In-depth Technical Principle Analysis

The working principle of git rebase --onto is based on topological sorting of commit graphs and patch application mechanisms. During command execution:

• Git first calculates the commit range of <oldBase>..<feature/branch>
• Applies these commits one by one in topological order onto <newBase>
• Each application may generate conflicts requiring developer intervention
• Ultimately generates a completely new commit sequence with different SHA-1 hash values

Alternative Solution Comparison

Besides git rebase --onto, other branch base change methods exist:

Solution One: Git Cherry-pick

Manually create a new branch and selectively pick commits:

git checkout -b PRO-new master
git cherry-pick <commit4-hash>
git cherry-pick <commit5-hash>

Advantages: Intuitive operation, easy to understand. Disadvantages: Inefficient with numerous commits, requires recreating code review processes.

Solution Two: Complete Branch Reconstruction

Completely rebuild branch content based on target base, suitable for simple change scenarios.

Practical Application Considerations

When using git rebase --onto, the following important factors must be considered:

• Team Collaboration Impact: Rewriting commit history affects other collaborators, ensure the branch isn't being modified by multiple people simultaneously
• Conflict Resolution: Base changes may trigger code conflicts, require prepared conflict resolution strategies
• Remote Repository Synchronization: After changes, use git push --force-with-lease to safely update remote branches
• Backup Strategy: Before important operations, recommend creating branch backups or using git reflog as recovery means

Advanced Application Scenarios

This technique can also be applied to the following complex scenarios:

• Partial Commit Migration: Achieve selective base changes by specifying precise commit ranges
• Multi-branch Reorganization: Implement complex branch structure optimization配合 other Git commands
• History Organization: Clean unnecessary branch dependencies during code repository maintenance

Conclusion

git rebase --onto provides powerful branch management capabilities, enabling developers to flexibly adjust repository structures. Mastering this tool requires deep understanding of Git's commit graph model and change replay mechanisms. In practical applications, select the most appropriate solution based on specific scenarios, and fully consider team collaboration and version history integrity requirements.