nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sourcetree gitflow - finish release merge process

scottsue

Hi,

I currently have a release branch that I want to finish that needs to be merged into both master and develop.

As per Vincent's blog (http://nvie.com/posts/a-successful-git-branching-model), version numbers are assigned upon creation of the release branch. If we were to follow this, our release version metadata gets updated in the release branch as the number is assigned. Upon finishing the release, because the release metadata was changed on the release branch, these changes are merged back into my develop branch, causing potential merge conflicts.

Is there somehow I can get around this? Currently this requires me to perform an extra step to revert the merged metadata changes in my develop branch after the merge. If these were normal changes, this is exactly what I would expect to happen.

Thanks,

Scott

Accepted answers

stevestreeting

I'm not clear on why the merge back into develop causes conflicts - in git-flow you create release branches from the latest develop branch by default, then you'd update your version metadata in the release branch, and then when you complete the release it'll merge into master and develop. Unless something was changed in develop which also affected the version metadata (which I wouldn't expect since you usually only change this during a release) there should be no conflicts.

Are you actually experiencing conflicts, or are you speculating that there might be some? If you follow the git-flow process for releases and only update your release metadata in a release branch then there should be no conflicts because you won't have updated this information in parallel.

All comments

stevestreeting

scottsue

Ok cool. Good to see that I'm on the right track

A bit of both as I'm new to this whole process. I think this is more of a question about how version numbers are handled. After reading up on git-flow and confirmed by you, version numbers are only updated upon creation of the release branch, for example 1.2.0. This lead me to assume that there shouldn't be a version number assigned on the develop branch at all, so setting it to something like DEVELOP-HEAD. However, I then am speculating that if I change the version metadata on the release branch. These will be merged back into the develop branch when I finish the release.

The problem I have then is that the 1.2.0 version number is in my develop branch. However, technically my develop branch doesn't necessarily reflect 1.20 exactly, as it is actually 1.2.0 + futher code changes.

The version metadata is quite important to us as we build jars using this, I want to be able to distinguish jars built from the develop branch as opposed to jars built from the release branch. If both branches have the same version number this could become problematic

stevestreeting

Yeah, if you changed the release number on the develop branch to differentiate it from the stable releases, then you would get a conflict when you finished the release. How you deal with that depends on your test / deployment workflow - if it's explicit and you have separate test/debug/deploy routes then you could incoporate a step in test/debug which tweaks the version number when you build the binary/jar, so not polluting the source location but it will show up in the final running version.

If that's not feasible, then you could just accept the conflicts will happen when you finish the release, and resolve them - often this isn't that difficult even when it does happen, especially if your version metadata is contained in files distinct from any source.

scottsue

Thanks Steve for the clarification

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sourcetree