Rebase Branch Merge

Description

In the following examples, v2 is a feature development branch, and dev is the main development branch. v2 was checked out from the dev branch.

After completing development on v2, you need to merge the code into dev. You can use rebase for the merge:

# First push v2 to the remote repository
git add .
git commit -m 'xxx'
git push origin v2

# Switch to dev and pull the latest code
git checkout dev
git pull origin dev

# Switch to v2
git checkout v2
git rebase dev # Rebase all [commits] from v2 onto (apply to) dev

# Switch to dev
git checkout dev
git merge v2  # Fast-forward merge on dev (at this point (HEAD -> dev, v2) [commit] both branches point to the same commit)

# Check whether the original v2 [commit] records are at the front of the dev branch (a successful rebase places v2's commit records at the very front of the dev branch)
git log

	# If you notice a problem at this step, try using git --abort to abort the rebase. If problems persist, you can use the "undo" operation on the dev branch, then switch to the v2 branch and use the "undo" operation there as well, restoring both branches to their state before the rebase

# Test whether the project runs correctly
yarn start

git status # Check if the status is clean
git push origin dev # Push to the remote dev branch

Rebase Guidelines

When multiple people are developing and committing on the same branch, do not rebase privately during development. Only perform a rebase after everyone has completed their work.

The Nature of Rebase

The essence of a rebase operation is to discard some existing commits and create new commits that have the same content but are actually different. Therefore, a branch should not be used after a rebase operation.

Undo (Recovery)

# View the HEAD pointer change history
git reflog
# Example output (current branch is v2):
07c398f (HEAD -> v2, master) HEAD@{0}: checkout: moving from master to v2
07c398f (HEAD -> v2, master) HEAD@{1}: rebase (finish): returning to refs/heads/master
07c398f (HEAD -> v2, master) HEAD@{2}: rebase (start): checkout v2
15a97d8 HEAD@{3}: reset: moving to 15a97d8
07c398f (HEAD -> v2, master) HEAD@{4}: merge v2: Fast-forward
15a97d8 HEAD@{5}: checkout: moving from v2 to master
07c398f (HEAD -> v2, master) HEAD@{6}: rebase (finish): returning to refs/heads/v2
07c398f (HEAD -> v2, master) HEAD@{7}: rebase (pick): C
15a97d8 HEAD@{8}: rebase (start): checkout master # First rebase
d278ecd HEAD@{9}: checkout: moving from master to v2 # State before rebase
15a97d8 HEAD@{10}: commit: D

# As shown, the initial rebase operation is at HEAD@{8}. To revert to the state before the rebase, point the pointer to HEAD@{9}
git reset --hard d278ecd  # Reset the current branch's HEAD to a specified [commit], also resetting the staging area and working directory to match

# Print the log to verify whether the state has been restored
git log

Note: This operation can only revert the current branch. If other branches also need to be reverted, switch to each branch and repeat the above operation.

Rebase During Development

Background

There are two branches:

dev
*v2

v2 was checked out from dev.

The commit history is as follows:

		dev
a - b - c
		v2

During development, both branches have new commits:

				dev
a - b - c - d - e
		\ - f - g
				v2

You are currently developing on v2, and dev is also being actively developed with significant changes. You need to sync the new commits from dev into v2.

Requirement: Sync the new commits from dev into v2 without affecting the dev branch.

Steps

1. Create a new branch dev-copy based on the latest dev

   dev-copy and dev have identical commit IDs.

2. In dev-copy, execute a rebase to apply dev-copy's commits onto v2

   git rebase v2 # Rebase dev-copy's [commits] onto (apply to) v2
   

3. Delete the original v2 branch and rename dev-copy to v2

   # Currently on the dev-copy branch
   git branch -d v2 # Delete the branch
   git branch -m dev-copy v2 # Rename
   

git cherry-pick

Source: git cherry-pick Tutorial (opens new window)

Used to copy a single or several [commits] to another branch.

Basic Usage

git cherry-pick <commitHash> # Apply commitHash to the current branch

The above command applies the specified commitHash to the current branch. This creates a new commit on the current branch; of course, their hash values will be different.

The argument to git cherry-pick does not have to be a commit hash; it can also be a branch name, which means transferring the latest commit of that branch.

Transferring Multiple Commits

Cherry pick supports transferring multiple commits at once.

git cherry-pick <HashA> <HashB> # Commits A and B

The above command applies both commits A and B to the current branch. This creates two corresponding new commits on the current branch.

To transfer a series of consecutive commits, you can use the following shorthand syntax:

git cherry-pick A..B # Commits from A to B, excluding A

The above command transfers all commits from A to B. They must be placed in the correct order: commit A must be earlier than commit B, otherwise the command will fail silently.

Note: Using the above command, commit A will NOT be included in the cherry pick. To include commit A, use the following syntax:

git cherry-pick A^..B # Commits from A to B, including A