Git force merge





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







2















I am wondering what I am supposed to do in order to force a merge from a dev branch into my master branch? Using 'git merge dev' results in quite a number of conflicts. However, I don't want to handle them individually. Instead, I simply want to use all the files from my dev branch and merge it into master. But this "forced merge" is not as easy as I thought. Can somebody please point me into the right direction?










share|improve this question























  • What do you mean with 'forced merge'? You are getting conflicts because git is not able to sort stuff through. You can always use options for merge to tell it to take the version of a certain branch where there's a conflict: -Xours or -Xtheirs.

    – eftshift0
    Nov 22 '18 at 21:58











  • stackoverflow.com/a/10697551/1375964 can use a recursive 'use -ours' strategy. stackoverflow.com/q/17667023/1375964 -you may want to just change what master is pointing to. Proceed with caution if you share this repository

    – osowskit
    Nov 23 '18 at 3:46













  • @eftshift0 I stumbled across those options. But to be honest, I didn't fully understand which one to use in my case. I basically would like my dev branch to become my "master". That's what I meant with "force merge". So, which branch is "ours" and which branch is "theirs"?

    – Andi
    Nov 23 '18 at 7:34


















2















I am wondering what I am supposed to do in order to force a merge from a dev branch into my master branch? Using 'git merge dev' results in quite a number of conflicts. However, I don't want to handle them individually. Instead, I simply want to use all the files from my dev branch and merge it into master. But this "forced merge" is not as easy as I thought. Can somebody please point me into the right direction?










share|improve this question























  • What do you mean with 'forced merge'? You are getting conflicts because git is not able to sort stuff through. You can always use options for merge to tell it to take the version of a certain branch where there's a conflict: -Xours or -Xtheirs.

    – eftshift0
    Nov 22 '18 at 21:58











  • stackoverflow.com/a/10697551/1375964 can use a recursive 'use -ours' strategy. stackoverflow.com/q/17667023/1375964 -you may want to just change what master is pointing to. Proceed with caution if you share this repository

    – osowskit
    Nov 23 '18 at 3:46













  • @eftshift0 I stumbled across those options. But to be honest, I didn't fully understand which one to use in my case. I basically would like my dev branch to become my "master". That's what I meant with "force merge". So, which branch is "ours" and which branch is "theirs"?

    – Andi
    Nov 23 '18 at 7:34














2












2








2








I am wondering what I am supposed to do in order to force a merge from a dev branch into my master branch? Using 'git merge dev' results in quite a number of conflicts. However, I don't want to handle them individually. Instead, I simply want to use all the files from my dev branch and merge it into master. But this "forced merge" is not as easy as I thought. Can somebody please point me into the right direction?










share|improve this question














I am wondering what I am supposed to do in order to force a merge from a dev branch into my master branch? Using 'git merge dev' results in quite a number of conflicts. However, I don't want to handle them individually. Instead, I simply want to use all the files from my dev branch and merge it into master. But this "forced merge" is not as easy as I thought. Can somebody please point me into the right direction?







git github






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 22 '18 at 21:50









AndiAndi

42939




42939













  • What do you mean with 'forced merge'? You are getting conflicts because git is not able to sort stuff through. You can always use options for merge to tell it to take the version of a certain branch where there's a conflict: -Xours or -Xtheirs.

    – eftshift0
    Nov 22 '18 at 21:58











  • stackoverflow.com/a/10697551/1375964 can use a recursive 'use -ours' strategy. stackoverflow.com/q/17667023/1375964 -you may want to just change what master is pointing to. Proceed with caution if you share this repository

    – osowskit
    Nov 23 '18 at 3:46













  • @eftshift0 I stumbled across those options. But to be honest, I didn't fully understand which one to use in my case. I basically would like my dev branch to become my "master". That's what I meant with "force merge". So, which branch is "ours" and which branch is "theirs"?

    – Andi
    Nov 23 '18 at 7:34



















  • What do you mean with 'forced merge'? You are getting conflicts because git is not able to sort stuff through. You can always use options for merge to tell it to take the version of a certain branch where there's a conflict: -Xours or -Xtheirs.

    – eftshift0
    Nov 22 '18 at 21:58











  • stackoverflow.com/a/10697551/1375964 can use a recursive 'use -ours' strategy. stackoverflow.com/q/17667023/1375964 -you may want to just change what master is pointing to. Proceed with caution if you share this repository

    – osowskit
    Nov 23 '18 at 3:46













  • @eftshift0 I stumbled across those options. But to be honest, I didn't fully understand which one to use in my case. I basically would like my dev branch to become my "master". That's what I meant with "force merge". So, which branch is "ours" and which branch is "theirs"?

    – Andi
    Nov 23 '18 at 7:34

















What do you mean with 'forced merge'? You are getting conflicts because git is not able to sort stuff through. You can always use options for merge to tell it to take the version of a certain branch where there's a conflict: -Xours or -Xtheirs.

– eftshift0
Nov 22 '18 at 21:58





What do you mean with 'forced merge'? You are getting conflicts because git is not able to sort stuff through. You can always use options for merge to tell it to take the version of a certain branch where there's a conflict: -Xours or -Xtheirs.

– eftshift0
Nov 22 '18 at 21:58













stackoverflow.com/a/10697551/1375964 can use a recursive 'use -ours' strategy. stackoverflow.com/q/17667023/1375964 -you may want to just change what master is pointing to. Proceed with caution if you share this repository

– osowskit
Nov 23 '18 at 3:46







stackoverflow.com/a/10697551/1375964 can use a recursive 'use -ours' strategy. stackoverflow.com/q/17667023/1375964 -you may want to just change what master is pointing to. Proceed with caution if you share this repository

– osowskit
Nov 23 '18 at 3:46















@eftshift0 I stumbled across those options. But to be honest, I didn't fully understand which one to use in my case. I basically would like my dev branch to become my "master". That's what I meant with "force merge". So, which branch is "ours" and which branch is "theirs"?

– Andi
Nov 23 '18 at 7:34





@eftshift0 I stumbled across those options. But to be honest, I didn't fully understand which one to use in my case. I basically would like my dev branch to become my "master". That's what I meant with "force merge". So, which branch is "ours" and which branch is "theirs"?

– Andi
Nov 23 '18 at 7:34












1 Answer
1






active

oldest

votes


















3















I simply want to use all the files from my dev branch




If you mean you want to use all the files from your dev branch - i.e. any changes made on the master branch since the branches diverged should be undone - then there are a couple of ways.



merge -s ours



You could



git checkout dev
git merge -s ours master
git checkout master
git merge dev


This is a bit round-about, because there is no "theirs" strategy. (There is a "theirs" strategy option for the default merge strategy, but it would still try to apply changes from master as long as they don't conflict with changes from dev; if what you want is to just keep the dev versions, that won't work.) So you use the ours strategy to create a merge commit between master and dev with the dev versions of all files, then fast-forward master onto that merge.



That means the order of parents will be reversed on the merge commit, which is something you usually wouldn't notice, but it could matter in some cases (like if you use --first-parent on logs or something).



commit-tree



If the order of parents matter, you could resort the plumbing command commit-tree



git checkout master
git merge $(git commit-tree dev -p master -p dev -m "merging dev over master")


history rewrite



The potential down-side to the above methods is that they produce a merge commit that may not be intuitive, in that its result ignores the changes from one side of the merge (whereas a merge is expected to combine the changes from both sides). Because your merge would conflict under the normal strategy, it's not as big a problem as it could be, but still some people would categorize it as an "evil merge". If you want to avoid that, the other option is to rewrite history.



That has a down side as well, particularly if you use this repo to collaborate with other developers. You can read about the problem (and generally how to solve it) in the git rebase docs under "recovering from upstream rebase". (While the docs refer to the problem as "upstream rebase", it really applies to any history rewrite of a shared branch.)



If you decide that a history rewrite makes sense, then the simplest thing is just to move the master branch so that it points to the same commit as dev.



git checkout dev
git branch -f master





share|improve this answer
























  • ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

    – Christoph
    Nov 23 '18 at 11:44











  • @Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

    – Andi
    Nov 23 '18 at 12:22












Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438353%2fgit-force-merge%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3















I simply want to use all the files from my dev branch




If you mean you want to use all the files from your dev branch - i.e. any changes made on the master branch since the branches diverged should be undone - then there are a couple of ways.



merge -s ours



You could



git checkout dev
git merge -s ours master
git checkout master
git merge dev


This is a bit round-about, because there is no "theirs" strategy. (There is a "theirs" strategy option for the default merge strategy, but it would still try to apply changes from master as long as they don't conflict with changes from dev; if what you want is to just keep the dev versions, that won't work.) So you use the ours strategy to create a merge commit between master and dev with the dev versions of all files, then fast-forward master onto that merge.



That means the order of parents will be reversed on the merge commit, which is something you usually wouldn't notice, but it could matter in some cases (like if you use --first-parent on logs or something).



commit-tree



If the order of parents matter, you could resort the plumbing command commit-tree



git checkout master
git merge $(git commit-tree dev -p master -p dev -m "merging dev over master")


history rewrite



The potential down-side to the above methods is that they produce a merge commit that may not be intuitive, in that its result ignores the changes from one side of the merge (whereas a merge is expected to combine the changes from both sides). Because your merge would conflict under the normal strategy, it's not as big a problem as it could be, but still some people would categorize it as an "evil merge". If you want to avoid that, the other option is to rewrite history.



That has a down side as well, particularly if you use this repo to collaborate with other developers. You can read about the problem (and generally how to solve it) in the git rebase docs under "recovering from upstream rebase". (While the docs refer to the problem as "upstream rebase", it really applies to any history rewrite of a shared branch.)



If you decide that a history rewrite makes sense, then the simplest thing is just to move the master branch so that it points to the same commit as dev.



git checkout dev
git branch -f master





share|improve this answer
























  • ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

    – Christoph
    Nov 23 '18 at 11:44











  • @Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

    – Andi
    Nov 23 '18 at 12:22
















3















I simply want to use all the files from my dev branch




If you mean you want to use all the files from your dev branch - i.e. any changes made on the master branch since the branches diverged should be undone - then there are a couple of ways.



merge -s ours



You could



git checkout dev
git merge -s ours master
git checkout master
git merge dev


This is a bit round-about, because there is no "theirs" strategy. (There is a "theirs" strategy option for the default merge strategy, but it would still try to apply changes from master as long as they don't conflict with changes from dev; if what you want is to just keep the dev versions, that won't work.) So you use the ours strategy to create a merge commit between master and dev with the dev versions of all files, then fast-forward master onto that merge.



That means the order of parents will be reversed on the merge commit, which is something you usually wouldn't notice, but it could matter in some cases (like if you use --first-parent on logs or something).



commit-tree



If the order of parents matter, you could resort the plumbing command commit-tree



git checkout master
git merge $(git commit-tree dev -p master -p dev -m "merging dev over master")


history rewrite



The potential down-side to the above methods is that they produce a merge commit that may not be intuitive, in that its result ignores the changes from one side of the merge (whereas a merge is expected to combine the changes from both sides). Because your merge would conflict under the normal strategy, it's not as big a problem as it could be, but still some people would categorize it as an "evil merge". If you want to avoid that, the other option is to rewrite history.



That has a down side as well, particularly if you use this repo to collaborate with other developers. You can read about the problem (and generally how to solve it) in the git rebase docs under "recovering from upstream rebase". (While the docs refer to the problem as "upstream rebase", it really applies to any history rewrite of a shared branch.)



If you decide that a history rewrite makes sense, then the simplest thing is just to move the master branch so that it points to the same commit as dev.



git checkout dev
git branch -f master





share|improve this answer
























  • ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

    – Christoph
    Nov 23 '18 at 11:44











  • @Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

    – Andi
    Nov 23 '18 at 12:22














3












3








3








I simply want to use all the files from my dev branch




If you mean you want to use all the files from your dev branch - i.e. any changes made on the master branch since the branches diverged should be undone - then there are a couple of ways.



merge -s ours



You could



git checkout dev
git merge -s ours master
git checkout master
git merge dev


This is a bit round-about, because there is no "theirs" strategy. (There is a "theirs" strategy option for the default merge strategy, but it would still try to apply changes from master as long as they don't conflict with changes from dev; if what you want is to just keep the dev versions, that won't work.) So you use the ours strategy to create a merge commit between master and dev with the dev versions of all files, then fast-forward master onto that merge.



That means the order of parents will be reversed on the merge commit, which is something you usually wouldn't notice, but it could matter in some cases (like if you use --first-parent on logs or something).



commit-tree



If the order of parents matter, you could resort the plumbing command commit-tree



git checkout master
git merge $(git commit-tree dev -p master -p dev -m "merging dev over master")


history rewrite



The potential down-side to the above methods is that they produce a merge commit that may not be intuitive, in that its result ignores the changes from one side of the merge (whereas a merge is expected to combine the changes from both sides). Because your merge would conflict under the normal strategy, it's not as big a problem as it could be, but still some people would categorize it as an "evil merge". If you want to avoid that, the other option is to rewrite history.



That has a down side as well, particularly if you use this repo to collaborate with other developers. You can read about the problem (and generally how to solve it) in the git rebase docs under "recovering from upstream rebase". (While the docs refer to the problem as "upstream rebase", it really applies to any history rewrite of a shared branch.)



If you decide that a history rewrite makes sense, then the simplest thing is just to move the master branch so that it points to the same commit as dev.



git checkout dev
git branch -f master





share|improve this answer














I simply want to use all the files from my dev branch




If you mean you want to use all the files from your dev branch - i.e. any changes made on the master branch since the branches diverged should be undone - then there are a couple of ways.



merge -s ours



You could



git checkout dev
git merge -s ours master
git checkout master
git merge dev


This is a bit round-about, because there is no "theirs" strategy. (There is a "theirs" strategy option for the default merge strategy, but it would still try to apply changes from master as long as they don't conflict with changes from dev; if what you want is to just keep the dev versions, that won't work.) So you use the ours strategy to create a merge commit between master and dev with the dev versions of all files, then fast-forward master onto that merge.



That means the order of parents will be reversed on the merge commit, which is something you usually wouldn't notice, but it could matter in some cases (like if you use --first-parent on logs or something).



commit-tree



If the order of parents matter, you could resort the plumbing command commit-tree



git checkout master
git merge $(git commit-tree dev -p master -p dev -m "merging dev over master")


history rewrite



The potential down-side to the above methods is that they produce a merge commit that may not be intuitive, in that its result ignores the changes from one side of the merge (whereas a merge is expected to combine the changes from both sides). Because your merge would conflict under the normal strategy, it's not as big a problem as it could be, but still some people would categorize it as an "evil merge". If you want to avoid that, the other option is to rewrite history.



That has a down side as well, particularly if you use this repo to collaborate with other developers. You can read about the problem (and generally how to solve it) in the git rebase docs under "recovering from upstream rebase". (While the docs refer to the problem as "upstream rebase", it really applies to any history rewrite of a shared branch.)



If you decide that a history rewrite makes sense, then the simplest thing is just to move the master branch so that it points to the same commit as dev.



git checkout dev
git branch -f master






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 23 '18 at 7:26









Mark AdelsbergerMark Adelsberger

22.1k11322




22.1k11322













  • ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

    – Christoph
    Nov 23 '18 at 11:44











  • @Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

    – Andi
    Nov 23 '18 at 12:22



















  • ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

    – Christoph
    Nov 23 '18 at 11:44











  • @Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

    – Andi
    Nov 23 '18 at 12:22

















ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

– Christoph
Nov 23 '18 at 11:44





ours and theirs is always confusing to me... Perhaps a reference to the docs of strategies recursive-ours and ours would help.

– Christoph
Nov 23 '18 at 11:44













@Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

– Andi
Nov 23 '18 at 12:22





@Mark Adelsberger Thanks for the great write-up. The 'merge -s ours' way did the trick for me.

– Andi
Nov 23 '18 at 12:22




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438353%2fgit-force-merge%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Can I use Tabulator js library in my java Spring + Thymeleaf project?

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents