2021-07-30
1710
#node
Indermohan Singh
61102
Jul 30, 2021 ⋅ 6 min read

Automatically generate and release a changelog using Node.js

Indermohan Singh JavaScript developer interested in Angular, RxJS, and Ionic framework.

Recent posts:

Justin Kitagawa Leader Spotlight

Leader Spotlight: Riding the rocket ship of scale, with Justin Kitagawa

We sit down with Justin Kitagawa to learn more about his leadership style and approach for handling the complexities that come with scaling fast.

Jessica Srinivas
Mar 29, 2024 ⋅ 8 min read
Nx Adoption Guide: Overview, Examples, And Alternatives

Nx adoption guide: Overview, examples, and alternatives

Let’s explore Nx features, use cases, alternatives, and more to help you assess whether it’s the right tool for your needs.

Andrew Evans
Mar 28, 2024 ⋅ 9 min read
Understanding Security In React Native Applications

Understanding security in React Native applications

Explore the various security threats facing React Native mobile applications and how to mitigate them.

Wisdom Ekpotu
Mar 27, 2024 ⋅ 10 min read
Warp Adoption Guide: Overview, Examples, And Alternatives

warp adoption guide: Overview, examples, and alternatives

The warp web framework for Rust offers many enticing features. Let’s see when and why you should consider using warp in your projects.

Ukeje Goodness
Mar 26, 2024 ⋅ 8 min read
View all posts

4 Replies to "Automatically generate and release a changelog using Node.js"

  1. Often our team will make commits on each feature or developer branch, sometimes these may be work in progress changes. Such as committing work at the end of the day even though it isn’t feature complete or other various reasons. How does this workflow fit in with partially feature complete commits? It doesn’t make sense to follow this for every commit when all that matters to us is the squashed commit for release. Can this workflow only be applied to named branches? Would love to see and edit or follow-up on this related area.

    1. Thanks Ash. That’s a good question.

      1. You can always use a commit message which has the conventional commit structure but doesn’t have details. E.g: “type: WIP”. Here type can be feat, fix, chore and so on.

      2. Before you merge the feature branch then you clean the commit messages and merge.
      3. From there on, it’s like mentioned in the article.

      I hope it helps. I’d be interested in writing a follow up article.

      Thanks.

Leave a Reply