how to merge release changes into master using pull requests
up vote
0
down vote
favorite
We got following setup for our pull requests. We have one main branch which is the master. For features we create Feature Branches and for bugs we create Bug fix branches which means we branch from the the master or release version in which it needs to be fixed in. Each pull request gets created for the branch it was created from which is easy and straight forward. But now I struggle a little with bug fixes.
In the case of a bug fix the PR is created for the release branch and is merged. So good so far but now the bug is fixed in the release. That's where my problem starts. How do I get the bugfix into the master now without merging it manually?
- Is it possible to use any pull request mechanism?
- What happens in case of conflicts?
- Can apply a automated fix to solve this issue?
git process pull-request
add a comment |
up vote
0
down vote
favorite
We got following setup for our pull requests. We have one main branch which is the master. For features we create Feature Branches and for bugs we create Bug fix branches which means we branch from the the master or release version in which it needs to be fixed in. Each pull request gets created for the branch it was created from which is easy and straight forward. But now I struggle a little with bug fixes.
In the case of a bug fix the PR is created for the release branch and is merged. So good so far but now the bug is fixed in the release. That's where my problem starts. How do I get the bugfix into the master now without merging it manually?
- Is it possible to use any pull request mechanism?
- What happens in case of conflicts?
- Can apply a automated fix to solve this issue?
git process pull-request
You mention amaster
branch in the first paragraph, and arelease
branch in the second. Can you explain how these branches are related ?
– LeGEC
Nov 9 at 8:13
In our setup it's not possible to merge stuff to the master or release branch without a pull request. In case of a bug fix we merge the change into the release branch but how do we get the changes into the master branch afterwards?
– Philipp
Nov 9 at 12:52
Ok. How different aremaster
andrelease
? Isrelease
always behindmaster
?master
behindrelease
? What gets merged intomaster
andrelease
? Maybe draw a sketch of your branches in your question ?
– LeGEC
Nov 9 at 20:56
GolezTrol explained it very well in his comment. You might wanna read that.
– Philipp
Nov 12 at 7:06
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
We got following setup for our pull requests. We have one main branch which is the master. For features we create Feature Branches and for bugs we create Bug fix branches which means we branch from the the master or release version in which it needs to be fixed in. Each pull request gets created for the branch it was created from which is easy and straight forward. But now I struggle a little with bug fixes.
In the case of a bug fix the PR is created for the release branch and is merged. So good so far but now the bug is fixed in the release. That's where my problem starts. How do I get the bugfix into the master now without merging it manually?
- Is it possible to use any pull request mechanism?
- What happens in case of conflicts?
- Can apply a automated fix to solve this issue?
git process pull-request
We got following setup for our pull requests. We have one main branch which is the master. For features we create Feature Branches and for bugs we create Bug fix branches which means we branch from the the master or release version in which it needs to be fixed in. Each pull request gets created for the branch it was created from which is easy and straight forward. But now I struggle a little with bug fixes.
In the case of a bug fix the PR is created for the release branch and is merged. So good so far but now the bug is fixed in the release. That's where my problem starts. How do I get the bugfix into the master now without merging it manually?
- Is it possible to use any pull request mechanism?
- What happens in case of conflicts?
- Can apply a automated fix to solve this issue?
git process pull-request
git process pull-request
asked Nov 9 at 7:38
Philipp
32
32
You mention amaster
branch in the first paragraph, and arelease
branch in the second. Can you explain how these branches are related ?
– LeGEC
Nov 9 at 8:13
In our setup it's not possible to merge stuff to the master or release branch without a pull request. In case of a bug fix we merge the change into the release branch but how do we get the changes into the master branch afterwards?
– Philipp
Nov 9 at 12:52
Ok. How different aremaster
andrelease
? Isrelease
always behindmaster
?master
behindrelease
? What gets merged intomaster
andrelease
? Maybe draw a sketch of your branches in your question ?
– LeGEC
Nov 9 at 20:56
GolezTrol explained it very well in his comment. You might wanna read that.
– Philipp
Nov 12 at 7:06
add a comment |
You mention amaster
branch in the first paragraph, and arelease
branch in the second. Can you explain how these branches are related ?
– LeGEC
Nov 9 at 8:13
In our setup it's not possible to merge stuff to the master or release branch without a pull request. In case of a bug fix we merge the change into the release branch but how do we get the changes into the master branch afterwards?
– Philipp
Nov 9 at 12:52
Ok. How different aremaster
andrelease
? Isrelease
always behindmaster
?master
behindrelease
? What gets merged intomaster
andrelease
? Maybe draw a sketch of your branches in your question ?
– LeGEC
Nov 9 at 20:56
GolezTrol explained it very well in his comment. You might wanna read that.
– Philipp
Nov 12 at 7:06
You mention a
master
branch in the first paragraph, and a release
branch in the second. Can you explain how these branches are related ?– LeGEC
Nov 9 at 8:13
You mention a
master
branch in the first paragraph, and a release
branch in the second. Can you explain how these branches are related ?– LeGEC
Nov 9 at 8:13
In our setup it's not possible to merge stuff to the master or release branch without a pull request. In case of a bug fix we merge the change into the release branch but how do we get the changes into the master branch afterwards?
– Philipp
Nov 9 at 12:52
In our setup it's not possible to merge stuff to the master or release branch without a pull request. In case of a bug fix we merge the change into the release branch but how do we get the changes into the master branch afterwards?
– Philipp
Nov 9 at 12:52
Ok. How different are
master
and release
? Is release
always behind master
? master
behind release
? What gets merged into master
and release
? Maybe draw a sketch of your branches in your question ?– LeGEC
Nov 9 at 20:56
Ok. How different are
master
and release
? Is release
always behind master
? master
behind release
? What gets merged into master
and release
? Maybe draw a sketch of your branches in your question ?– LeGEC
Nov 9 at 20:56
GolezTrol explained it very well in his comment. You might wanna read that.
– Philipp
Nov 12 at 7:06
GolezTrol explained it very well in his comment. You might wanna read that.
– Philipp
Nov 12 at 7:06
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
Sounds like you want to keep the release branches separate. In that case you need to make the same (or similar) fix in master too.
To do that in a nice-ish way, you can make a new bug branch of master, and cherry pick the commits from the release branch. That will basically give you a copy of those commits in the other branch.
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
|
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
Sounds like you want to keep the release branches separate. In that case you need to make the same (or similar) fix in master too.
To do that in a nice-ish way, you can make a new bug branch of master, and cherry pick the commits from the release branch. That will basically give you a copy of those commits in the other branch.
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
|
show 1 more comment
up vote
0
down vote
accepted
Sounds like you want to keep the release branches separate. In that case you need to make the same (or similar) fix in master too.
To do that in a nice-ish way, you can make a new bug branch of master, and cherry pick the commits from the release branch. That will basically give you a copy of those commits in the other branch.
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
|
show 1 more comment
up vote
0
down vote
accepted
up vote
0
down vote
accepted
Sounds like you want to keep the release branches separate. In that case you need to make the same (or similar) fix in master too.
To do that in a nice-ish way, you can make a new bug branch of master, and cherry pick the commits from the release branch. That will basically give you a copy of those commits in the other branch.
Sounds like you want to keep the release branches separate. In that case you need to make the same (or similar) fix in master too.
To do that in a nice-ish way, you can make a new bug branch of master, and cherry pick the commits from the release branch. That will basically give you a copy of those commits in the other branch.
answered Nov 9 at 7:58
GolezTrol
97.5k9130173
97.5k9130173
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
|
show 1 more comment
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't want to keep them separate. It's more a permission issue. Nobody can merge into the release or master branch without a pull request. I could overrule that but so I need to do all the merges which I want to avoid
– Philipp
Nov 9 at 12:50
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
I don't understand how your branching model works. I thought that master is the 'ongoing' work branch, in which features are merged (using PR). At some point you label something to be release, and for that you have a release branch, which can get bug fixes. I imagined you want to keep the release branches separate from master, so a release will always stand on its own, with the additional fixes/patches you do for it. In that case, you need to make the change in two places, and my remark about cherry picking applies.
– GolezTrol
Nov 9 at 13:49
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
Alternatively, you can just create a pull request from release to master, to get the fix into master as well, but that is likely to fail because the release branch is behind master. You can't update it either, because then you would pull all the new additions into a previous release. I think what you could do is make a separate branch (like 'Release1.3_to_master'), make sure it's up to date with master, pull in the changes from Release, resolve any merge conflicts, and make a PR from that branch to master.
– GolezTrol
Nov 9 at 15:35
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
This should work but it quite complicated. Are there any tools which automate this process?
– Philipp
Nov 12 at 7:06
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
For solving merge conflicts, no. But the steps themselves can be scripted.
– GolezTrol
Nov 12 at 7:50
|
show 1 more 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f53221552%2fhow-to-merge-release-changes-into-master-using-pull-requests%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
You mention a
master
branch in the first paragraph, and arelease
branch in the second. Can you explain how these branches are related ?– LeGEC
Nov 9 at 8:13
In our setup it's not possible to merge stuff to the master or release branch without a pull request. In case of a bug fix we merge the change into the release branch but how do we get the changes into the master branch afterwards?
– Philipp
Nov 9 at 12:52
Ok. How different are
master
andrelease
? Isrelease
always behindmaster
?master
behindrelease
? What gets merged intomaster
andrelease
? Maybe draw a sketch of your branches in your question ?– LeGEC
Nov 9 at 20:56
GolezTrol explained it very well in his comment. You might wanna read that.
– Philipp
Nov 12 at 7:06