Workflow when using versioneer with GitHub repositories

I’ve been investigating use of versioneer for our projects at work, but I think I have run into an issue that maybe someone can provide some insight on.

We use GitHub for our projects, and we use a branch named dev as an integration branch for our development. Developers branch from dev for bug and feature work, and merge back into it once their work is completed.

Here’s a rough sketch of that (o represents a commit):

tags                    v1.2.0  v1.2.1
                            |    |
master    ------------------o----o-----
                           /     /
                          /     /
dev       o--------------o-----o-------
           \            / \   /
feature 1   o----o-o-o-o   \ /
bug fix 1                   o 

When we want to make a release, we create a pull request from dev into master. Usually we use the standard “Merge pull request” (as opposed to the “Squash and merge” or “Rebase and merge” options on GitHub).

The “Merge pull request” uses git’s --no-ff option, meaning that a commit merge is created on master for each release.

We tag the merge commit on master to indicate that that is the release commit.

The problem I have with versioneer is that when I have checked out dev (say in the scenario sketched above), it doesn’t find any tags at all and it reports version numbers such as 0+untagged.40.g79cbd06 (based on the setup.cfg of course).

From experimentation, I can see that if I merge directly into master without --no-ff option it seems to work as intended. My guess is that it is because there is a common commit in the history of master and dev branches. However, GitHub actually prevents such common commits.

So my questions are:

• Is this the expected behaviour for versioneer?
• If it is expected behaviour, how can we use versioneer with GitHub? Am I doing something wrong?
• Is there a recommended change management plan/branching strategy that works with versioneer and GitHub?

Thanks in advance.

[altendky]

Isn’t this a simplified (no release branch) version of nvie/gitflow#49? If you don’t merge the tagged master commit back into dev then new dev commits won’t be descendants of the latest tag. It seems to me quite proper that tools wouldn’t look at ‘cousins’ for tags to identify the current commit.

[danieljacobs1]

Maybe you are now fast-forward merging and your master branch head just now points at the same commit as dev?

Yes, that’s what we did, but things have moved on since then for us.