<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>

CC BY-SA 4.0
2024-10-23T03:53:21.477Z
2024-10-23T03:53:21.477Z
Hiếu Vũ
<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>

<azure-devops><continuous-integration><git><branch>
How to handle merge conflicts in Azure DevOps when commits exist on both develop and master branches
jazzrc
# 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.


---

