Answers: <p>I'd set up my CI system to do this on every commit to <code>master</code>, that is, after the release branch merges.</p>
  
  <p>The first very straightforward reason for this is that the commit to <code>master</code> gets tagged with the release, and you want the thing you ultimately publish to match exactly the version of the source code at the tag.  While there shouldn't be any merge surprises if git flow is run perfectly, it's still better to publish the content of a tag and not the commit immediately before a merge.</p>
  
  <p>The second reason is that it is a very simple rule that can be automated.  If you do any amount of final testing on the release branch, you need to make a manual decision as to whether or not you can release or not; your CI system (probably) can't make that decision just based on the presence of a release branch.  On the other hand, since every commit to <code>master</code> is merging in a release (or hotfix) branch that you've fully validated, the commit itself is a signal that you're ready to release.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-16T15:01:15.153Z
Answers: Thanks David, that makes sense. I haven't got a deployment step in my worflow yet, but when I get round to doig that, would I be right to assume that the deploy should also be inline with the publish done after the release is 'finished' from 'master' as you say.
Answers: Plastikfan
Answers: CC BY-SA 4.0
Answers: 2019-12-15T06:55:47.370Z
Answers: 2019-12-15T06:55:47.370Z
Answers: David Maze
Body: <p>I'm using the following resources as a guide to git flow:</p>
  
  <ul>
  <li><a href="https://danielkummer.github.io/git-flow-cheatsheet/" rel="nofollow noreferrer">git-flow cheatsheet</a></li>
  <li><a href="https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/git-flow" rel="nofollow noreferrer">git-flow</a></li>
  <li><a href="https://jeffkreeftmeijer.com/git-flow/" rel="nofollow noreferrer">Using git-flow to automate your git branching workflow</a></li>
  </ul>
  
  <p>However, none of them explicitly mention at what point you perform the npm publish from. Do you do this after you have bumped the version number but before you finish the release? This would mean the publish is coming from the release branch. Or do you finish the release then perform the publish from the master branch?</p>
  
  <p>Thanks.</p>
  
Tags: <git><release-management><release><npm>
Title: When to "npm publish" when using git flow
UserDisplayName: Plastikfan
ThreadText: # When to "npm publish" when using git flow
  
  (Asked by: username_0 on 2019-12-11)
  
  I'm using the following resources as a guide to git flow:
  
  * [git-flow cheatsheet](https://danielkummer.github.io/git-flow-cheatsheet/)
  * [git-flow](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/git-flow)
  * [Using git-flow to automate your git branching workflow](https://jeffkreeftmeijer.com/git-flow/)
  
  However, none of them explicitly mention at what point you perform the npm publish from. Do you do this after you have bumped the version number but before you finish the release? This would mean the publish is coming from the release branch. Or do you finish the release then perform the publish from the master branch?
  
  Thanks.
  
  **Tags:** git, release-management, release, npm
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-12-15. Score: 4 | Accepted answer
  
  I'd set up my CI system to do this on every commit to `master`, that is, after the release branch merges.
  
  The first very straightforward reason for this is that the commit to `master` gets tagged with the release, and you want the thing you ultimately publish to match exactly the version of the source code at the tag. While there shouldn't be any merge surprises if git flow is run perfectly, it's still better to publish the content of a tag and not the commit immediately before a merge.
  
  The second reason is that it is a very simple rule that can be automated. If you do any amount of final testing on the release branch, you need to make a manual decision as to whether or not you can release or not; your CI system (probably) can't make that decision just based on the presence of a release branch. On the other hand, since every commit to `master` is merging in a release (or hotfix) branch that you've fully validated, the commit itself is a signal that you're ready to release.
  
  > **Comments:**
  > **username_0**: Thanks username_1, that makes sense. I haven't got a deployment step in my worflow yet, but when I get round to doig that, would I be right to assume that the deploy should also be inline with the publish done after the release is 'finished' from 'master' as you say.  
  
  ---
  
  