Git分支策略咨询：合并时共享分支更新引发重复合并问题

Hey there, let's walk through your questions step by step—this is a super common pain point for active development teams, so you're not alone here.

First: Is re-merging due to upstream changes industry standard? #

Absolutely. When you're working in a team where multiple people are pushing to a shared branch (like your UAT branch), it's normal for your local copy of the shared branch to fall behind while you're resolving conflicts or testing your changes. This doesn't mean your process is broken—it's just a side effect of collaborative, frequent development.

Second: Is your developer-specific _dev branch causing the hassle? #

Nope, not at all. Your strategy of having individual _dev branches (e.g., john_dev) makes total sense for isolating changes to QA for independent testing—this is a valid and widely used pattern for teams that need granular control over what gets tested when. The friction you're seeing comes from the timing of your merges, not the branch structure itself.

Common Industry Solutions to Reduce This Pain #

Here are practical steps teams use to minimize repeated merge conflicts and streamline the process:

• Sync your _dev branch with UAT constantly
  Instead of only merging UAT into your _dev branch when you're ready to push changes, do it multiple times a day (e.g., every morning, after lunch, or before starting a new task). Smaller, more frequent syncs mean fewer changes to reconcile at once, making conflicts faster to fix and less likely to snowball.

• Use Pull Requests (PRs) with automated checks
  Ditch the local merge-and-push workflow for PRs. Most Git platforms let you open a PR from your _dev branch to UAT, and offer tools to:

  • Automatically merge the latest UAT changes into your PR branch to catch conflicts early
  • Run CI/CD builds and tests on the merged code before it hits UAT
  • Let teammates review your changes and collaborate on conflict resolution visually
    This way, you don't have to worry about local UAT being out of date when you're ready to merge—the platform handles syncing for you.

• Consider rebasing instead of merging (for personal branches)
  If your _dev branch is only used by you (no one else is pushing to it), you can rebase your commits on top of the latest UAT instead of merging. This creates a cleaner, linear commit history and can make conflict resolution feel more incremental. The commands would look like:

  git checkout john_dev
  git fetch origin uat
  git rebase origin/uat
  # Resolve any conflicts, then continue the rebase with git rebase --continue
  git push --force-with-lease origin john_dev
  

  Note: Only do this if your _dev branch is private to you—rebasing rewrites history, which can cause issues if others are relying on your branch.

• Temporary branch locks (for critical merges)
  In rare cases (like a scheduled UAT release), you can temporarily lock the UAT branch to prevent new commits while you finish merging your changes. This is a last resort, though—use it sparingly, as it can slow down the rest of the team.

Final Takeaway #

Repeated merges due to upstream changes are totally normal for busy teams. Your individual _dev branch strategy is solid for your QA isolation needs—focus on syncing more frequently and leveraging PR tools to make the merge process smoother, and you'll see a big reduction in the time you spend resolving conflicts.

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