Standard-version: What should the proper workflow be with git-flow

Created on 28 Jun 2017  路  9Comments  路  Source: conventional-changelog/standard-version

I am new to the whole conventional-"insert-anything-here" part and I really want to do things right.
I just read about git-flow, which sounds really reasonable, but when I do a release with it, it tags my release. If I run conventional-github-release or standard-version they do a git-tag as well. NPM version does as well, but I saw I can omit that tag with npm --no-git-tag-version version.

Could someone just give me a proper workflow to:

  • Start a feature branch
  • After I'm done with the feature, create the changelog and merge the feature
  • Do a feature release
    This can be easily done with git-flow and conventional-changelog, right? The version release on GitHub I can do manually, because conventional-github-releaser I think does a tag as well or something, not sure anymore.

But what if I want a major release? Git-flow will do a tag, then maybe generate changelog with conv-changelog and do a new version with npm version

If Someone would give me a proper workflow for common scenarios, that would be awesome, because I am really confused with all the different cli tools in the conventional- family.

Most helpful comment

http://digital-cult.com/releasing-js-library-github-git-flow-conventional-commits/
Take a look if you have the time. Thank you for your awesome work!

All 9 comments

I'm using gitflow now. You still release on the master branch so the workflow should be the same. EG: When you release, you merge your release/hotfix branch to master. Then run standard-version

Doesn't standard-version create a new version tag as well? Because I tried that a few hours ago and I got a major version v2.0.0 from git-flow and then standard-version I think did another one with 2.0.0 because I stated in one of my commit messages a breaking change.

Also I if I want a release on github, I think its better to do it your self, copying what was last generated in the CHANGELOG.md am I right?
I'm sorry to ask such stupid questions, but I am literally searching for a decent tutorial on these things and the closest I could find was a russian one ...

Doesn't standard-version create a new version tag as well?

It tags because it's a drop in replacement of npm-version

Also I if I want a release on github, I think its better to do it your self, copying what was last generated in the CHANGELOG.md am I right

You mentioned conventional-github-release... Just use that

I'm not really sure what you are asking for but https://danielkummer.github.io/git-flow-cheatsheet/ can help you to understand more about gitflow. In fact, this tool is very generic enough and it handles normal workflows. gitflow releases on master so it'd be exactly the same as the README without doing anything extra.

What I wanted to ask is this:
git flow release finish release-name does a git tag with the name of release-name. Then when I change back to master and do a standard-version command i get a new tag v.3.0.0 for example. Is this the way to go and just have multiple git tags created? Wont that just become messy or its normal.
https://github.com/dobromir-hristov/learn-git See what I mean.

git flow release finish release-name -n skips tagging. After that I can change to master, merge with develop (because there is a merge branch commit there), then run standard-version. I could have some hooks in git or npm to add versions in banners in my js or what not. Then I can push everything and only one tag is created. Am I right this time 馃槃

You don't have to use the tool, gitflow, in all situations. Just like when you use standard-version you don't use npm-version. I think in this scenario you shouldn't use git flow release finish release-name. The important thing here is you follow the flow of gitflow and standard-version, doesn't mean you must use everything in the tool gitflow

git flow release finish release-name -n skips tagging. After that I can change to master, merge with develop (because there is a merge branch commit there), then run standard-version. I could have some hooks in git or npm to add versions in banners in my js or what not. Then I can push everything and only one tag is created. Am I right this time 馃槃

I think you are right :)

I managed to construct my self a nice workflow. I am in the middle of writing a short post, I will post a link to it here today. Please check it out and correct me if I write something stupid 馃槅

http://digital-cult.com/releasing-js-library-github-git-flow-conventional-commits/
Take a look if you have the time. Thank you for your awesome work!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sarbbottam picture sarbbottam  路  3Comments

jefftienchow picture jefftienchow  路  5Comments

chris-dura picture chris-dura  路  4Comments

okainov picture okainov  路  3Comments

eemeli picture eemeli  路  4Comments