多项目并行开发时Git工作流优化方案问询

Hey there! Let's tackle this problem head-on—your current dev+master setup is causing headaches when you need to ship only one out of multiple QA-ready features, and cherry-picking is error-prone. The per-project dev branches you tried don't fix the parallel QA issue either, so here's a streamlined, practical workflow that fits your scenario perfectly:

Feature Branch Workflow + Lightweight Release Branches #

This approach keeps your work isolated at the feature level (instead of project or monolithic dev branch), letting you test multiple features in parallel and ship only the ones that are ready—no messy cherry-picks required.

How It Works #

1. Core Branch Foundation

   • Keep master as your production-ready branch (matches deployed or soon-to-be-deployed code, just like your current setup).
   • Ditch the single dev branch—instead, every feature (or small, testable chunk of a project) gets its own isolated branch.

2. Isolated Feature Development

   • For every new feature (regardless of which project it belongs to), create a branch directly from master:

     git checkout -b feature/projectA-user-registration master
     

   • Develop, commit, and push this branch as you work. No need to merge into a shared dev branch yet—this keeps your work separate from other in-progress features.

3. Parallel QA Testing

   • When a feature is ready for QA, deploy this specific feature branch to your QA environment. Since each feature is in its own branch, you can test multiple features at the same time without them interfering with each other.
   • Fix any QA feedback directly on the feature branch—all changes stay isolated until you're ready to ship.

4. Safe, Selective Deployment

   • When a feature passes QA, you have two options depending on your needs:
     • Ship a single feature: Merge the feature branch directly into master (no cherry-picking!):

       git checkout master
       git pull origin master
       git merge --no-ff feature/projectA-user-registration
       # The --no-ff flag preserves the feature's commit history for easier debugging
       git push origin master
       

     • Ship multiple features together: If you want to bundle several QA-passed features into one release, create a temporary release branch from master, merge all ready features into it, do a final smoke test, then merge to master:

       # Create a release branch
       git checkout -b release/v1.2.3 master
       # Merge all ready features
       git merge feature/projectA-user-registration
       git merge feature/projectB-payment-gateway
       # Add any final tweaks (like version number updates)
       git commit -m "Bump version to v1.2.3"
       # Merge to production
       git checkout master
       git merge release/v1.2.3
       git push origin master
       # Clean up the release branch
       git branch -d release/v1.2.3
       git push origin --delete release/v1.2.3
       

5. Clean Up

   • Once a feature is merged to master, delete the feature branch locally and remotely to keep your repo tidy:

     git branch -d feature/projectA-user-registration
     git push origin --delete feature/projectA-user-registration
     

Why This Beats Your Previous Approaches #

• No more cherry-pick chaos: Merging entire feature branches preserves complete commit history and automatically handles conflicts, reducing the risk of missing changes.
• True parallel QA: Each feature is tested in isolation, so you don't have to wait for one feature to pass QA before testing another.
• Flexible deployment: Ship individual features or bundle them—you're not locked into deploying everything in the shared dev branch.
• Simpler than per-project dev branches: Instead of managing a dev branch for every project, you only manage branches for individual features, which is more scalable and avoids mixing multiple features within a single project branch.

Pro Tips for Your Small Team #

• Keep feature branches small: Each branch should represent one testable feature or fix—this makes QA faster and merges smoother.
• Sync feature branches regularly: Pull the latest changes from master into your feature branch every few days to avoid massive merge conflicts later:

  git checkout feature/projectA-user-registration
  git pull origin master
  git push origin feature/projectA-user-registration
  

• Use pull requests (PRs): Even in a small team, PRs let you do quick code reviews, link QA test results, and document why changes are being merged—this keeps everyone on the same page.

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