Closed emilianb closed 4 years ago
Hi @emilianb, are you using the most common GitFlow way to propagate a release? Let me try to explain myself, all documents and images of GitFlow tells us to merge release branches to develop and to master (develop <- release -> master) but, if you do that way, develop will have a commit id (because of the merge) that won't exist on master and vice-versa. In a recent project, we decided to go a little bit different. We defined that we will merge from release to master, tag the version on master, and, then, merge from master to develop (release -> master -> tag new version -> develop). In that way, we guarantee that develop will always be, at least, one commit ahead of master, while still propagate the release changes for both branches. In fact, I do prefer this way. And, we used the same logic for hotfix branches (hotfix -> master -> tag new version -> develop).
@ycamargo explained the problem and solution brilliantly. You need to merge release to master then master to develop.
The build fails when using PullRequests to merge into master from a release branch. It sees an additional commit that is used to mark the PR merge and complains that now develop branch is behind master, although running a diff on the two branches will report that there are no differences between them.