I put this together on Saturday to help me work a little faster on large features.
When I'm working on a new feature for any significant amount of time, I tend to make lots of "WIP" commits that I know I'll later squash together before merging. This makes that process a bit faster.
`naenae` is very similar to the effect of `squashing` with `-m` (such that the commit message isn't pre-populated with dozens of "WIP" messages), except it does the counting reliably for you, and lets you use [commitizen](https://commitizen.github.io/cz-cli/) without much thought.
This probably isn’t as useful for less-public projects (where it’s common to make smaller, in-progress commits and leave them as-is), but a lot of open source projects prefer to merge in pull requests with only one commit. This allows them to both generate succinct and useful changelogs and more accurately show contribution stats. For those kinds of projects, I find myself spending a lot of time counting and squashing, so this alleviates that a bit.
This might also be a good option for users with [little-to-no familiarity with Git](https://xkcd.com/1597/).
Usually when I need to make a WIP commit it is when I need to switch to master to fix or change something else. When I'm done in master I'll switch back and just do a `git reset --soft HEAD` or I'll just do a git stash.
2 comments
[ 3.4 ms ] story [ 12.8 ms ] threadWhen I'm working on a new feature for any significant amount of time, I tend to make lots of "WIP" commits that I know I'll later squash together before merging. This makes that process a bit faster.
`naenae` is very similar to the effect of `squashing` with `-m` (such that the commit message isn't pre-populated with dozens of "WIP" messages), except it does the counting reliably for you, and lets you use [commitizen](https://commitizen.github.io/cz-cli/) without much thought.
This probably isn’t as useful for less-public projects (where it’s common to make smaller, in-progress commits and leave them as-is), but a lot of open source projects prefer to merge in pull requests with only one commit. This allows them to both generate succinct and useful changelogs and more accurately show contribution stats. For those kinds of projects, I find myself spending a lot of time counting and squashing, so this alleviates that a bit.
This might also be a good option for users with [little-to-no familiarity with Git](https://xkcd.com/1597/).