Improved support for GitFlow like workflows: Differences between Branches

jgitver / jgitver-maven-plugin

maven core extension to automatically define versions using jgitver & git tags

https://jgitver.github.io/

Other

159 stars 41 forks source link

Improved support for GitFlow like workflows: Differences between Branches #16

Closed jschneider closed 8 years ago

jschneider commented 8 years ago

I am using GitFlow which is really, really great.

Development occurs in "develop". "master" always contains the latest, released version.

Example workflow can be seen in https://github.com/jschneider/jgitver-playing-ground

The version number calculation could be done like that: in "master":

When a "real" git tag is set, use a release version (non snapshot)
Ignore lightweight tags even on the same commit

in "develop":

Always use a snapshot version
if there is a tag at the current commit, increase the version number and convert to snapshot.

GitFlow

McFoggy commented 8 years ago

marked as duplicate ; will have to be covered by jgitver/jgitver#15

McFoggy commented 8 years ago

have a look at "branch_policy" branch, I started to introduce a branch policy mechanism that should cover most of your needs. I'll add IT tests & documentation. You can also refer to the corresponding unit tests in jgitver: this one especially.

mawl commented 8 years ago

We are using git-flow in some projects in our company.

In git-flow, when I finish a release, the release branch is merged into master and tagged on the master branch:

I would have expected that the new development version on the develop branch then would be 2.0.1-SNAPSHOT but it's still 0.0.0-develop-SNAPSHOT.

jschneider commented 8 years ago

why did you not merge the tagged commit back into develop? That should solve your issue in this case.

As you can see, the tagged commit is not a parent of the current develop HEAD

McFoggy commented 8 years ago

@mawl I agree with @jschneider, in your case if you merge back your tagged commit, you should have what you expect.

But I agree that we should perhaps plan/describe new schemes/behavior in order to support different workflows than the default ones. Iin this area some help would be much appreciated in order to document the expected behaviors. The top would be some junit tests in a jgitver branch that could serve as documentation/discussion. Some draw.io graphs could do the trick also.

McFoggy commented 8 years ago

in order to fully support other workflows dedicated issues could be opened.