Constant conflicts when using mergerequests and releasenotes in git
up vote
1
down vote
favorite
We record our release notes during development in an .md document. This document contains explanations on features, migration notes and more. When merging feature branches, we often have the problem that conflicts arise within this file, even though usually only content is added.
In particular, it is very annoying that after each completed mergerequest, the already running mergerequests can no longer be merged automatically, since conflicts now occur again in the release notes.
We have considered different solution options. However, we would like to avoid either outsourcing the release notes to a separate repo or creating a separate file for each feature, which then has to be merged at release.
Since we are certainly not the only ones who have this problem, we hope that we can get some valuable tips on how to avoid manual merging of the release notes.
I made a sketch of the problem. Green changes can be merged automatically, while red changes need human attention.
Edit in response to the comment by Lasse Vågsæther Karlsen:
In fact, our release notes do look like this:
# Release 5.23.23
## Highlights
### Feature0
A simple explaination in few words targeting non-tec-reader
### Feature1
Another simple explaination in few words targeting non-tec-reader
## New Features
### Feature0
A more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
### Feature1
Another more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
## API Changes
### Deprecation of Method `Service#foo`
Feature0 intoduces a better API. `Service#foo` is deprecated as of now and will be removed in a future version
### New Method `QualityService#bar`
This Method replaces `Service#foo` and is way better because of some reason.
As you can see, each feature is mentioned in multiple sections. We already thought about building our own tooling to merge multiple well-formatted files into one document during release - but before putting any effort into this we wanted to be sure there is no better solution.
git git-merge merge-conflict-resolution
asked Nov 5 at 7:05
samjaf
594516
add a comment |
up vote
1
down vote
favorite
We record our release notes during development in an .md document. This document contains explanations on features, migration notes and more. When merging feature branches, we often have the problem that conflicts arise within this file, even though usually only content is added.
In particular, it is very annoying that after each completed mergerequest, the already running mergerequests can no longer be merged automatically, since conflicts now occur again in the release notes.
We have considered different solution options. However, we would like to avoid either outsourcing the release notes to a separate repo or creating a separate file for each feature, which then has to be merged at release.
Since we are certainly not the only ones who have this problem, we hope that we can get some valuable tips on how to avoid manual merging of the release notes.
I made a sketch of the problem. Green changes can be merged automatically, while red changes need human attention.
Edit in response to the comment by Lasse Vågsæther Karlsen:
In fact, our release notes do look like this:
# Release 5.23.23
## Highlights
### Feature0
A simple explaination in few words targeting non-tec-reader
### Feature1
Another simple explaination in few words targeting non-tec-reader
## New Features
### Feature0
A more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
### Feature1
Another more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
## API Changes
### Deprecation of Method `Service#foo`
Feature0 intoduces a better API. `Service#foo` is deprecated as of now and will be removed in a future version
### New Method `QualityService#bar`
This Method replaces `Service#foo` and is way better because of some reason.
As you can see, each feature is mentioned in multiple sections. We already thought about building our own tooling to merge multiple well-formatted files into one document during release - but before putting any effort into this we wanted to be sure there is no better solution.
git git-merge merge-conflict-resolution
asked Nov 5 at 7:05
samjaf
594516
Actually, it is more common that people find a way to split up files that everybody has to edit all the time or find a completely different solution to this. Why can't this file be built using your project management tool instead?
– Lasse Vågsæther Karlsen
Nov 5 at 7:27
1
Or have you considered just letting everybody write their release notes into separate files, and then use a small tool/script to concatenate them into one big file for release?
– Lasse Vågsæther Karlsen
Nov 5 at 7:39
Usually answer is a custom merge driver, but I'm not sure how to make it work at a github/gitlab/bitbucket server
– max630
Nov 5 at 14:52
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
We record our release notes during development in an .md document. This document contains explanations on features, migration notes and more. When merging feature branches, we often have the problem that conflicts arise within this file, even though usually only content is added.
In particular, it is very annoying that after each completed mergerequest, the already running mergerequests can no longer be merged automatically, since conflicts now occur again in the release notes.
We have considered different solution options. However, we would like to avoid either outsourcing the release notes to a separate repo or creating a separate file for each feature, which then has to be merged at release.
Since we are certainly not the only ones who have this problem, we hope that we can get some valuable tips on how to avoid manual merging of the release notes.
I made a sketch of the problem. Green changes can be merged automatically, while red changes need human attention.
Edit in response to the comment by Lasse Vågsæther Karlsen:
In fact, our release notes do look like this:
# Release 5.23.23
## Highlights
### Feature0
A simple explaination in few words targeting non-tec-reader
### Feature1
Another simple explaination in few words targeting non-tec-reader
## New Features
### Feature0
A more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
### Feature1
Another more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
## API Changes
### Deprecation of Method `Service#foo`
Feature0 intoduces a better API. `Service#foo` is deprecated as of now and will be removed in a future version
### New Method `QualityService#bar`
This Method replaces `Service#foo` and is way better because of some reason.
As you can see, each feature is mentioned in multiple sections. We already thought about building our own tooling to merge multiple well-formatted files into one document during release - but before putting any effort into this we wanted to be sure there is no better solution.
git git-merge merge-conflict-resolution
asked Nov 5 at 7:05
samjaf
594516
We record our release notes during development in an .md document. This document contains explanations on features, migration notes and more. When merging feature branches, we often have the problem that conflicts arise within this file, even though usually only content is added.
In particular, it is very annoying that after each completed mergerequest, the already running mergerequests can no longer be merged automatically, since conflicts now occur again in the release notes.
We have considered different solution options. However, we would like to avoid either outsourcing the release notes to a separate repo or creating a separate file for each feature, which then has to be merged at release.
Since we are certainly not the only ones who have this problem, we hope that we can get some valuable tips on how to avoid manual merging of the release notes.
I made a sketch of the problem. Green changes can be merged automatically, while red changes need human attention.
Edit in response to the comment by Lasse Vågsæther Karlsen:
In fact, our release notes do look like this:
# Release 5.23.23
## Highlights
### Feature0
A simple explaination in few words targeting non-tec-reader
### Feature1
Another simple explaination in few words targeting non-tec-reader
## New Features
### Feature0
A more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
### Feature1
Another more detailed explaination targeting other developers. We explain how to use the feature with a small snippet.
## API Changes
### Deprecation of Method `Service#foo`
Feature0 intoduces a better API. `Service#foo` is deprecated as of now and will be removed in a future version
### New Method `QualityService#bar`
This Method replaces `Service#foo` and is way better because of some reason.
As you can see, each feature is mentioned in multiple sections. We already thought about building our own tooling to merge multiple well-formatted files into one document during release - but before putting any effort into this we wanted to be sure there is no better solution.
git git-merge merge-conflict-resolution
git git-merge merge-conflict-resolution
asked Nov 5 at 7:05
samjaf
594516
asked Nov 5 at 7:05
samjaf
594516
edited Nov 5 at 7:42
asked Nov 5 at 7:05
samjaf
594516
asked Nov 5 at 7:05
samjaf
594516
asked Nov 5 at 7:05
samjaf
594516
594516
Actually, it is more common that people find a way to split up files that everybody has to edit all the time or find a completely different solution to this. Why can't this file be built using your project management tool instead?
– Lasse Vågsæther Karlsen
Nov 5 at 7:27
1
Or have you considered just letting everybody write their release notes into separate files, and then use a small tool/script to concatenate them into one big file for release?
– Lasse Vågsæther Karlsen
Nov 5 at 7:39
Usually answer is a custom merge driver, but I'm not sure how to make it work at a github/gitlab/bitbucket server
– max630
Nov 5 at 14:52
add a comment |
Actually, it is more common that people find a way to split up files that everybody has to edit all the time or find a completely different solution to this. Why can't this file be built using your project management tool instead?
– Lasse Vågsæther Karlsen
Nov 5 at 7:27
1
Or have you considered just letting everybody write their release notes into separate files, and then use a small tool/script to concatenate them into one big file for release?
– Lasse Vågsæther Karlsen
Nov 5 at 7:39
Usually answer is a custom merge driver, but I'm not sure how to make it work at a github/gitlab/bitbucket server
– max630
Nov 5 at 14:52
Actually, it is more common that people find a way to split up files that everybody has to edit all the time or find a completely different solution to this. Why can't this file be built using your project management tool instead?
– Lasse Vågsæther Karlsen
Nov 5 at 7:27
Actually, it is more common that people find a way to split up files that everybody has to edit all the time or find a completely different solution to this. Why can't this file be built using your project management tool instead?
– Lasse Vågsæther Karlsen
Nov 5 at 7:27
1
1
Or have you considered just letting everybody write their release notes into separate files, and then use a small tool/script to concatenate them into one big file for release?
– Lasse Vågsæther Karlsen
Nov 5 at 7:39
Or have you considered just letting everybody write their release notes into separate files, and then use a small tool/script to concatenate them into one big file for release?
– Lasse Vågsæther Karlsen
Nov 5 at 7:39
Usually answer is a custom merge driver, but I'm not sure how to make it work at a github/gitlab/bitbucket server
– max630
Nov 5 at 14:52
Usually answer is a custom merge driver, but I'm not sure how to make it work at a github/gitlab/bitbucket server
– max630
Nov 5 at 14:52
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53149757%2fconstant-conflicts-when-using-mergerequests-and-releasenotes-in-git%23new-answer', 'question_page');
}
);
Post as a guest
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
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
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
Actually, it is more common that people find a way to split up files that everybody has to edit all the time or find a completely different solution to this. Why can't this file be built using your project management tool instead?
– Lasse Vågsæther Karlsen
Nov 5 at 7:27
1
Or have you considered just letting everybody write their release notes into separate files, and then use a small tool/script to concatenate them into one big file for release?
– Lasse Vågsæther Karlsen
Nov 5 at 7:39
Usually answer is a custom merge driver, but I'm not sure how to make it work at a github/gitlab/bitbucket server
– max630
Nov 5 at 14:52