Git force merge
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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
asked Nov 22 '18 at 21:50
AndiAndi
42939
add a comment |
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
asked Nov 22 '18 at 21:50
AndiAndi
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:-Xoursor-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
add a comment |
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
asked Nov 22 '18 at 21:50
AndiAndi
42939
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
git github
asked Nov 22 '18 at 21:50
AndiAndi
42939
asked Nov 22 '18 at 21:50
AndiAndi
42939
asked Nov 22 '18 at 21:50
AndiAndi
42939
asked Nov 22 '18 at 21:50
AndiAndi
42939
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:-Xoursor-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
add a comment |
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:-Xoursor-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
add a comment |
1 Answer
1
active
oldest
votes
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
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
oursandtheirsis always confusing to me... Perhaps a reference to the docs of strategiesrecursive-oursandourswould 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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
oursandtheirsis always confusing to me... Perhaps a reference to the docs of strategiesrecursive-oursandourswould 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
add a comment |
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
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
oursandtheirsis always confusing to me... Perhaps a reference to the docs of strategiesrecursive-oursandourswould 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
add a comment |
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
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
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
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
answered Nov 23 '18 at 7:26
Mark AdelsbergerMark Adelsberger
22.1k11322
22.1k11322
oursandtheirsis always confusing to me... Perhaps a reference to the docs of strategiesrecursive-oursandourswould 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
add a comment |
oursandtheirsis always confusing to me... Perhaps a reference to the docs of strategiesrecursive-oursandourswould 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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:
-Xoursor-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