On what branch (commit) should I tag the version

[jbennink]

I am new to git and minver and was working with a "feature" branch and had tested this new featur it was fine, so I tagged the commit with a version, and then proceed to merge that feature branch to main. I ahd to pull main because other changes from our team, and then merged the feature branch to main.
I noticed that main did not should my version tag. The merge created new commit id's for my commits and since tags are set on commitid's main did not pick up the versio number I set (on the feature branch).

As I said we are still new to git as well, and from what I have read I could have also done: pull main to update, then goto my feature branch and rebase from main to pick up the cnages and replay my commits (but that would again result in new commit id's so wI guess then I would have also lost the tag I had already set.

My question is mainly:

1. (outside of minver scope) Is either of these merge workflows the better, or is there another way
2. At what time would I set the version tag, and on what commit.

Regarding 2 I was wondering (we don't have CI/CD it's a windows .exe that is use on customer computers) so we currently build new "release versions" on a dev machine. Would you set thet tag after merging to main, then set the tag on main, do a build/publish in main and use those artefacts to generate the production release?
I guess with a CI/CD pipeline you woould merge to main, then create the tag and de pipeline would pick up the tag and create a release version for you.

It's more of a discussion question, not sure whether that is appropriate here.. Feedback welcome :-)

[adamralph]

The answer to question 1 is contextual. It really depends on the needs of your team.

The answer to question 2 is simpler: tag the commit you want to release.

[jbennink]

But regarding 2: OK I know I asking for it but in our world of anything goes I would deploy from the feature branch and have to tag a commit there. But when that commit is merged back I first have to pull main, and if I rebase my commits change I kloos the tag to a commit somewhere limbo and that version number will never show up in main. So I would think the better way to do is publish and version tag always from the same branch to make sure you have a complete simple list of all tags.
And that is not what we do now but I'm also trying to get some feedback that I can use to get the team to be more clean about checkins and commits and publishes :-)
But I get that it always depends... and I know you can't teach me git or development rules but still I ask :-O

P.S. I also thought this discussion would be picked up by others besides the repo owner so I was not expecting you to answer this.

Thanks for answering by the way. I love this library and hope we can adopt it fast.

Since we have multiple executables in 1 repo I am adopting the prefix method to distinguish different version numbers for the differnete .exe and webapps that we produce.

[adamralph]

So I would think the better way to do is publish and version tag always from the same branch to make sure you have a complete simple list of all tags.

Yes. Don't release from a commit that is going to go away, e.g. one that is going to be rebased. Release from a commit which is going to exist as long as the released version is in production/supported. E.g. master/main or some release branch.

P.S. I also thought this discussion would be picked up by others besides the repo owner so I was not expecting you to answer this.

No worries, but thanks for calling that out. 🙂

Thanks for answering by the way. I love this library and hope we can adopt it fast.

👍 I'm glad you find it useful.

Since we have multiple executables in 1 repo I am adopting the prefix method to distinguish different version numbers for the differnete .exe and webapps that we produce.

👍 sounds good.