Answers: <p>You should made change on release branch. Master branch should not be edited directly. Then you will not have conflict and cleaner flow.</p>
  <p>Maybe creating a hot-fix branch will help with tracking hot-fixes.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-10-23T03:53:21.477Z
Answers: 2024-10-23T03:53:21.477Z
Answers: Hiếu Vũ
Body: <p>When trying to complete a pull request (PR) that merges our <em>develop</em> branch into <em>master</em> in Azure DevOps (using rebase and fast-forward), a merge conflict occurs if some commits already exist on <em>master</em>. This happens when commits have been pushed to both <em>develop</em> and <em>master</em> before the merge attempt (for example, when a hotfix is pushed directly to <em>master</em> to address a production issue).</p>
  <p>Is there a way to configure Azure DevOps to automatically skip commits that are already present on <em>master</em> during the merge process?</p>
  <p>Alternatively, would it be better to adopt a workflow where we build and publish from release branches, allowing hotfixes to be merged into the release branch instead of <em>master</em>, avoiding the need to cherry-pick commits to <em>master</em>?</p>
  <p><strong>Note:</strong> Force-pushing to the <em>master</em> branch is not an option due to compliance restrictions. Additionally, I’m part of a small backend team that frequently releases new production builds.</p>
  
Tags: <azure-devops><continuous-integration><git><branch>
Title: How to handle merge conflicts in Azure DevOps when commits exist on both develop and master branches
UserDisplayName: jazzrc
ThreadText: # How to handle merge conflicts in Azure DevOps when commits exist on both develop and master branches
  
  (Asked by: username_0 on 2024-10-21)
  
  When trying to complete a pull request (PR) that merges our *develop* branch into *master* in Azure DevOps (using rebase and fast-forward), a merge conflict occurs if some commits already exist on *master*. This happens when commits have been pushed to both *develop* and *master* before the merge attempt (for example, when a hotfix is pushed directly to *master* to address a production issue).
  
  Is there a way to configure Azure DevOps to automatically skip commits that are already present on *master* during the merge process?
  
  Alternatively, would it be better to adopt a workflow where we build and publish from release branches, allowing hotfixes to be merged into the release branch instead of *master*, avoiding the need to cherry-pick commits to *master*?
  
  **Note:** Force-pushing to the *master* branch is not an option due to compliance restrictions. Additionally, I’m part of a small backend team that frequently releases new production builds.
  
  **Tags:** azure-devops, continuous-integration, git, branch
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-10-23. Score: 0 | Accepted answer
  
  You should made change on release branch. Master branch should not be edited directly. Then you will not have conflict and cleaner flow.
  
  Maybe creating a hot-fix branch will help with tracking hot-fixes.
  
  
  ---
  
  