Conventional Commits
conventionalcommits.org
Conventional Commits
1–10 of 25 posts
Re: Conventional Commits
#2> Example: Commit message with both ! and BREAKING CHANGE footer:
> refactor!: drop support for Node 6
From Wikipedia's Code Refactoring:
> In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.
So if a code change is just a refactor, then its external behavior is unchanged, therefore it is not a breaking change. These two commit labels are incompatible.
Re: Conventional Commits
#3The most interesting things about Conventional Commits are that they can be deterministically digested by a process to decide how to bump a SemVer and similarly to create a formatted CHANGELOG file.
Re: Conventional Commits
#4The most interesting things about Conventional Commits are that they can be deterministically digested by a process to decide how to bump a SemVer and similarly to create a formatted CHANGELOG file.
Re: Conventional Commits
#5> Example: Commit message with both ! and BREAKING CHANGE footer: > refactor!: drop support for Node 6 From Wikipedia's Code Refactoring: > In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. So if a code change is just a refactor, then its external behavior is unchanged, therefore it is not…
Once the decision has been made that Node 6 is no longer supported, it is then possible to refactor the code so that it uses appropriate modern idioms, such that the external behaviour is unchanged for Node 6+ but will no longer be parsable by Node 5.
In this specific case, it is both a refactor and a breaking change.
Re: Conventional Commits
#6> Example: Commit message with both ! and BREAKING CHANGE footer: > refactor!: drop support for Node 6 From Wikipedia's Code Refactoring: > In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. So if a code change is just a refactor, then its external behavior is unchanged, therefore it is not…
I think they use the angular definition which doesn't explicit forbid this
> refactor: A code change that neither fixes a bug nor adds a feature
But yeah I'm with you in saying that this particular example is not well choosen
Re: Conventional Commits
#7After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're just there to appease the tool since you can't commit (even locally!) without them.
Just stick to squash-before-merge-to-master, thanks.
Re: Conventional Commits
#8After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're ju…
Squash merge and commit linter only on master seems like the way to go here.
Then you can do whatever you want in your feature branch, and then when the feature is ready, create the squashed commit with the proper commit formatting.
Re: Conventional Commits
#9After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're ju…
The linters can probably be configured to look for the squash!/fixup! indicators in commit messages and throw a warning or something instead.
Re: Conventional Commits
#10After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're ju…
Squash merge and commit linter only on master seems like the way to go here. Then you can do whatever you want in your feature branch, and then when the feature is ready, create the squashed commit with the proper commit formatting.
squash merges to master are terrible for those that want to go looking why a certain change was introduced.
Now a larger change set is hidden behind a squash merge, and why was line 50 in foobar.py updated? Who knows, it was part of this giant merge request which no longer provides context why the developer changed line 50 in foobar.py.
Commit messages should explain why the change was made to the code. The amount of times that I go diving into a codebase only to find that the change was introduced in a larger commit that just says "fix bug" with no further information is maddening.