# Detect merge conflicts early **URL:** \ **Category:** How To\ **Tags:** git-clone\ **Created:** [February 14, 2019, 4:01pm UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093 "2019-02-14T16:01:09Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jpalten](https://avatars.discourse-cdn.com/v4/letter/j/d26b3c/32.png) [@jpalten](https://discuss.bitrise.io/u/jpalten)\ **Post date:** [February 14, 2019, 4:01pm UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/1 "2019-02-14T16:01:09Z")
I added a script in my workflow, to make merge conflicts visible early in the development process. Perhaps this can help others too. For each commit, I’d like to know if it could cause merge conflicts to (in my case) `develop` . So at the end of my normal workflow where I run the unit tests, I check out the `develop` branch, try to merge the changed branch, and run unit tests on the result. This helps me to find merge conflicts sooner in our development process. Here is the script build step that works for me: ```auto #!/usr/bin/env bash # fail if any commands fails set -e # debug log set -x TARGET_BRANCH="develop" SOURCE_BRANCH="$BITRISE_GIT_BRANCH" git reset --hard git "checkout" "$SOURCE_BRANCH" git merge "origin/$SOURCE_BRANCH" git fetch "origin" "$TARGET_BRANCH" git reset --hard git checkout origin/$TARGET_BRANCH git merge $SOURCE_BRANCH ``` ---
**Author:** ![bitce](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/bitce/32/1639_2.png) [@bitce](https://discuss.bitrise.io/u/bitce)\ **Post date:** [February 15, 2019, 9:20am UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/2 "2019-02-15T09:20:38Z")
Thanks for sharing this here as well @jpalten! ---
**Author:** ![swcisel](https://avatars.discourse-cdn.com/v4/letter/s/73ab20/32.png) [@swcisel](https://discuss.bitrise.io/u/swcisel)\ **Post date:** [February 21, 2019, 5:55pm UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/3 "2019-02-21T17:55:19Z")
It just occurred to me that I should do the same, and here’s the answer. Thanks for saving me some time 🙂. ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [March 6, 2019, 1:45pm UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/4 "2019-03-06T13:45:45Z")
Actually Bitrise Pull Request builds do the same automatically: it clones the target (the one the PR/MR is meant to be merged into) then it git merges the source onto it. Of course this only works for Pull Requests/Merge Requests and only if you enable the pull request triggers to be built ([https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/](https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/)), but in that case it should be automatic. If that would not be the case let me know! P.S.: You can see the `git` commands performed in the `Git Clone` step’s build logs, e.g.: ```auto git "init" Initialized empty Git repository in /bitrise/go/src/github.com/bitrise-io/bitrise/.git/ git "remote" "add" "origin" "https://github.com/bitrise-io/bitrise.git" git "fetch" "origin" "master" From https://github.com/bitrise-io/bitrise * branch master -> FETCH_HEAD * [new branch] master -> origin/master git "checkout" "master" Already on 'master' Branch master set up to track remote branch master from origin. git "merge" "origin/master" Already up-to-date. commit hash: 7850cc59ebb20fee59ffca4b21b739cf561f3579 git "fetch" "origin" "godrei-patch-1" From https://github.com/bitrise-io/bitrise * branch godrei-patch-1 -> FETCH_HEAD * [new branch] godrei-patch-1 -> origin/godrei-patch-1 git "merge" "9d704732ce1cc27de14f48b16d6043572cfe86be" Updating 7850cc5..9d70473 Fast-forward README.md | 13 ------------- 1 file changed, 13 deletions(-) git "submodule" "update" "--init" "--recursive" git "checkout" "--detach" ``` ([https://github.com/bitrise-io/bitrise/pull/653](https://github.com/bitrise-io/bitrise/pull/653) 's build) ---
**Author:** ![ben.thomas](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/ben.thomas/32/4460_2.png) [@ben.thomas](https://discuss.bitrise.io/u/ben.thomas)\ **Post date:** [June 30, 2022, 5:15am UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/6 "2022-06-30T05:15:21Z")
How do I stop it trying to merge to develop if the build was triggered due to a pull request? I just want Bitrise to build the branch, and develop may have changed so the merge will fail, erroneously failing the build. ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [July 18, 2022, 5:08pm UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/7 "2022-07-18T17:08:09Z")
@ben.thomas to not to test the PR merge you can trigger the build for the `push` event and remove it from `pull_request` event > **[Triggering builds automatically](https://devcenter.bitrise.io/en/builds/starting-builds/triggering-builds-automatically.html)** > > You can configure automatic build triggers on Bitrise by specifying a trigger event and a Workflow. You can trigger builds from code pushes, pull requests or Git tags. > **[Using the Trigger Map to trigger builds](https://devcenter.bitrise.io/en/builds/starting-builds/using-the-trigger-map-to-trigger-builds.html)** > > On Bitrise, you can create triggers (or webhooks) for events such as code push or pull requests to start a build automatically. To trigger builds for code push for all branches: ```auto trigger_map: - push_branch: * workflow: primary ``` To trigger different workflows for named branches, e.g. for `main` and another workflow for every other push: ```auto trigger_map: - push_branch: main workflow: deploy - push_branch: * workflow: primary ``` If you remove the Pull Request items from the Trigger Map then no pre-merge will be performed. You can do it on the web UI as well, but in the YML I’m referring to these as pull request items in the trigger map: ```auto - pull_request_target_branch: "master" pull_request_source_branch: "develop" workflow: primary ``` **That said, in general it’s a best practice to test the pre-merge state, as that’s what the state of the code will be after you merge the PR.** ---
**Author:** ![ben.thomas](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/ben.thomas/32/4460_2.png) [@ben.thomas](https://discuss.bitrise.io/u/ben.thomas)\ **Post date:** [July 18, 2022, 10:24pm UTC](https://discuss.bitrise.io/t/detect-merge-conflicts-early/8093/8 "2022-07-18T22:24:28Z")
Thank you for the suggestions @viktorbenei