Git特性分支依赖待评审特性分支的开发实践建议咨询

Great question—this is a super common scenario in team-based Git workflows, and there are a few solid approaches to keep you moving without blocking on code review. Here are the best practices and step-by-step solutions:

Approach 1: Branch feature-#2 directly from feature-#1 (Most Straightforward) #

This is the go-to method when feature-#2 relies entirely on feature-#1’s work. Instead of waiting for feature-#1 to merge into develop, you can start building directly on top of it.

Steps: #

1. Switch to your existing feature-#1 branch:

   git checkout feature-#1
   

2. Create and switch to the new feature-#2 branch:

   git checkout -b feature-#2
   

3. Start developing feature-#2 as normal—all the code from feature-#1 will be available here.

When feature-#1 gets merged to develop: #

Once the review is done and feature-#1 is in develop, rebase feature-#2 onto the updated develop branch to keep your history clean:

# Fetch the latest changes from the remote
git fetch origin

# Switch to develop and pull the merged feature-#1
git checkout develop
git pull origin develop

# Switch back to feature-#2 and rebase onto develop
git checkout feature-#2
git rebase origin/develop

If there are conflicts during the rebase, resolve them commit-by-commit (Git will walk you through this) and continue with git rebase --continue.

Pros & Cons: #

• ✅ You can start developing immediately, no waiting.
• ✅ Keeps your feature branches aligned with the code you need.
• ⚠️ If feature-#1 gets significant changes during review, you’ll need to pull those updates into feature-#2 (using git pull origin feature-#1 or git merge feature-#1) to stay in sync, which might introduce small conflicts.

Approach 2: Cherry-Pick Critical Commits from feature-#1 (For Partial Dependencies) #

If feature-#2 only needs a specific subset of feature-#1’s changes (not the entire branch), cherry-picking those relevant commits into a new feature-#2 branch (based on develop) is a cleaner option.

Steps: #

1. First, find the commit hashes of the changes you need from feature-#1. Use git log feature-#1 to list commits, and copy the 7-character hash of the ones you need.
2. Switch to develop and create feature-#2:

   git checkout develop
   git checkout -b feature-#2
   

3. Cherry-pick the desired commits:

   git cherry-pick <commit-hash-1> <commit-hash-2>
   

   Resolve any conflicts if they arise, then finish with git cherry-pick --continue.

Pros & Cons: #

• ✅ Avoids carrying unnecessary code from feature-#1 into feature-#2.
• ✅ Your feature-#2 branch stays closer to the base develop branch.
• ⚠️ More manual work, especially if feature-#1 has many commits or gets updated during review (you’ll need to re-cherry-pick or adjust).

Best Practices to Smooth the Process #

• Communicate with your review team: Let them know that feature-#2 is blocked on feature-#1’s review—they might prioritize it to unblock your work. Even a quick heads-up can speed things up.
• Keep feature branches small: Smaller, focused PRs get reviewed faster, which reduces the likelihood of this waiting scenario in the first place.
• Rebase early and often: If you’re using Approach 1, periodically pull updates from feature-#1 into feature-#2 (e.g., git pull origin feature-#1) to minimize large conflicts later when merging to develop.
• Document dependencies: Add a note in your feature-#2 PR description (like "Depends on feature-#1: [PR link]") so reviewers and teammates are aware of the dependency.

内容的提问来源于stack exchange，提问作者9years