We use Bitbucket to host a large monolithic front-end application that is gradually being split to individual packages using lerna. Historically we have our main develop branch to merge all recent release branches into. However, release history is not linear because of the individual packages architecture, so we might have:
| - other-app/release/10.0 - latest
/
/
| | some-app/release/12.0
| /
| /
|\/
|/\
| \
| | - some-app/release/11.0
| |
| |
|\ /
| \
|/ \
| |- other-app/release/9.0 released
| |
| /
| /
|/
| - develop
(I'm not very good at charts).
So what if, say, we want to fix something in some-app/release/11.0 before it's released and have it auto-merged into some-app/release/12.0 but not other-app/release/* and develop?
Hi! If you fix something in some-app/release/11.0 it won't be auto-merged into other-app/release/ because it doesn't follow the naming convention. In order to use automatic branch merging, Bitbucket Server has to be able to determine the ordering of branches, and relies on semantic versioning of branch names. For more information, please check Automatic branch merging.
Let us know if you have any questions!
Best regards,
Ana
The question is: is Bitbucket capable of tracking multiple configurations (some-app/release/, other-app/release/) that should not interfere with each other in a single repository or it can only have one per repo?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.