npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

git-cactus

v1.4.2

Published

A opinionated tool for cutting releases

Downloads

29

Readme

🌵 git-cactus 🌵

git-cactus is a git management tool that supports the Cactus Branching Model.

Build Status: CircleCI

Installation

Prerequisites

  • Node 8+ for now
  • Working C toolchain (nodegit uses libgit2)
    • On a Mac do xcode-select --install

Procedure

$ npm install -g git-cactus

On Arch Linux, because nodegit's precompiled binary was compiled against an outdated version of libcurl, you must build it from source. See this nodegit issue for details. After running npm install -g git-cactus, change to the directory where git-cactus was installed and run BUILD_ONLY=1 npm install nodegit.

Usage

git-cactus is invoked as a git subcommand like this: git cactus (note the space!)

The tool is fairly bare bones to start with. You can only do two things:

  • Cut a release branch
  • Tag a new version

If you want help you can run git cactus without any arguments or with the help argument.

Warning: Adding a --help flag will make git try to open a man page (which doesn't yet exist).

TLDR

$ git cactus cut # cuts a release
$ git cactus tag # tags a version

Cutting a Release Branch

Cutting a release branch is used to branch code off of origin's master. Teams typically do this when they want to make a snapshot of the branch where development happens to do QA for an upcoming release. This allows collaborative development to continue while the snapshot of the code is validated for production.

Running the operation is fairly simple:

$ cd <repository>
$ git cactus cut

If the master branch's package.json version is currently v1.2.0 (last release) cutting a release branch will:

  • Run npm version minor -m 'Release v%s' on master
    • bump package.json
    • bump packge.lock
    • commit with message 'Release v1.3.0'
    • tag as v1.3.0
  • Create a new release branch for v1.3 called release-v1.3
  • Push changes to master branch
  • Push new release branch release-v1.3
  • Push tag v1.3.0

If you don't use origin as the name of your upstream remote you can specify another:

git cactus cut --upstream my-upstream

Don't worry about working state! Git cactus will clone the repository you run the command in to a temporary directory (/tmp/xxx/) and run the necessary operations there (including cleanup).

This opinionated but necessary to avoid common errors and frustrations:

  • [Source of Error] Depending on an engineer's local master branch state
  • [Source of Frust] Cutting a release branch interrupts flow by requiring clean git state

Tagging a Version

Tagging a version is typically done when you want to apply a hotfix to the current release.

To make a hotfix for v1.3.0:

  • Decide where fix needs to go:
    • If the fix applies to current code: make commit on master
    • If the fix applies only to release being patched: do not commit fix to master (doesn't apply)
  • Switch to release branch needing the hotfix
    git checkout release-v1.3 # lets make hotfix for v1.3
    git pull <upstream> release-v1.3
  • Get the code for the fix onto the branch:
    • If the fix was made to master: git cherry-pick <fix sha>
    • If the fix only applies to this release git apply <fix sha>
  • Tag the version (v1.3.1)
    git cactus tag

Tagging a release version will:

  • Running npm version patch -m 'Release v%s'
    • bump package.json
    • bump packge.lock
    • commit with message 'Release v1.3.1'
    • tag as v1.3.1
  • Pushing the update release branch release-v1.3
  • Pushing tag v1.3.1