基于Azure DevOps CI/CD，如何通过GitHub实现分支部分合并？

Hey there! Let's walk through exactly what you need to do to get only Feature A into your master (production) branch—this is a super common scenario, so you’re in good shape.

First, the core idea here: since both Feature A and B are already in your development branch, we can’t just merge the whole development into master (thanks to B’s issues). Instead, we need to isolate Feature A’s code and move it alone to master. There are two reliable ways to do this, depending on your comfort level with Git commands.

Method 1: Use git cherry-pick (Fast & Direct) #

This method lets you copy specific commits (those belonging to Feature A) directly into your master branch.

• Step 1: Sync your local repo with remote
  Make sure you have all the latest code from all branches first:

  git fetch origin
  

• Step 2: Switch to master and pull latest changes
  Get your local master branch up to date with the remote version:

  git checkout master
  git pull origin master
  

• Step 3: Find Feature A’s commit IDs
  Since your commits are linked to Azure Boards work items, you can go to the Feature A work item in Azure Boards and look at its linked commits. Alternatively, check GitHub’s commit history for the development branch to find all commits tied to Feature A.
• Step 4: Cherry-pick the commits to master
  If Feature A only has one commit, run:

  git cherry-pick <feature-a-commit-id>
  

  If there are multiple commits, run them in the same order they were originally made:

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

  Heads up: If you hit a merge conflict, resolve it in your code editor, then run git cherry-pick --continue to finish. If you want to abort the cherry-pick entirely, use git cherry-pick --abort.

• Step 5: Push the updated master branch
  Send your changes to the remote repo:

  git push origin master
  

• Step 6: Let the pipeline do its work
  Since every commit triggers CI, your Azure DevOps pipeline will automatically kick off for master and deploy Feature A to production. Also, because your commits are linked to Azure Boards work items, the work item’s status should update automatically (if your pipeline is configured for this).

Method 2: Create a New Release Branch for Feature A (Safer for Teams) #

If you’re nervous about cherry-pick conflicts, or want to do a code review before merging to production, this method works great:

• Step 1: Create a new branch from master
  Start with a clean slate based on the latest production code:

  git fetch origin
  git checkout master
  git pull origin master
  git checkout -b release-feature-a
  

• Step 2: Merge Feature A’s code into this new branch
  If the original feature/a branch still exists (before it was merged to development), just merge that branch:

  git merge origin/feature/a
  

  If the original branch is gone, merge the specific range of commits from development that belong to Feature A:

  git merge <first-feature-a-commit-id>..<last-feature-a-commit-id>
  

• Step 3: Resolve conflicts (if any) and push the branch
  Fix any merge issues, then push the new branch to GitHub:

  git push origin release-feature-a
  

• Step 4: Open a Pull Request (PR) to master
  Go to your GitHub repo, open a PR from release-feature-a to master. This lets your team review the code if needed, then approve and merge it.
• Step 5: Deploy to production
  Once the PR is merged, master updates, triggers your CI/CD pipeline, and deploys Feature A to production. Your linked Azure Boards work items will update their status too.

Quick Post-Step Notes #

• Fixing Feature B: Have your developer fix the issues in Feature B in their feature branch, then merge it back to development once it’s tested. When it’s ready, you can either cherry-pick it to master or merge the whole development branch (if no other problematic code is present).
• CI Pipeline Checks: Make sure your pipelines are configured to only deploy development to your dev environment and master to production—this prevents accidental deployments from other branches.
• Work Item Tracking: Keep an eye on your Azure Boards work items for Feature A; once the production deployment completes, the work item should show as "Deployed" (depending on your pipeline’s work item integration settings).

内容的提问来源于stack exchange，提问作者Prashant Kumar