Master HEAD must be a merge commit message about gitversion

[andreasohlund]

You need to make sure the merge to master isn't a fast forward. Ie use the --no-ff switch

Sent from my iPhone

On 4 dec 2013, at 16:55, Scott Meyer [email protected] wrote:

I'm trying to work out the exact workflow to establish a stable version using GitFlowVersion.

When adding GitFlowVersion to an existing repository already using GitFlow, I have a master branch and a develop branch. In order to start with GitFlowVersion, I add GitFlowVersion to develop branch and commit. Then, branch to release-1.0.0 and tag the commit release-1.0.0-alpha1. This sets the AssemblyVersion to 1.0.0.0 and the ProductVersion to 1.0.0-alpha1{etc}. At this point, GitFlowVersion seems happy.

How to I properly apply the 1.0.0 version to master at this point?

From the documentation, I would think this should properly apply the 1.0.0 version on the master HEAD:

c:\repos\example (release-1.0.0) > git checkout master

c:\repos\example (master)> git merge release-1.0.0
Fast-forward...

c:\repos\example (master)>
However, when I compile, I get an error that the head of master should be a merge commit or tag. My understanding is that it is currently a merge commit.

If I then do the following (continued from above):

c:\repos\example (master)> git tag -a 1.0.0 -m "Added GitFlowVersion"
I can compile and get the 1.0.0 version I expect. Can someone help point out the holes I have here, as I assume this isn't exactly the correct workflow. Am I required to do a pull request from release-1.0.0 to master in order for GitFlowVersion to find the right version?

—
Reply to this email directly or view it on GitHub.

[scottmeyer]

Thanks for the clarification. That worked out.

[danielmarbach]

This can be closed.