-
-
Notifications
You must be signed in to change notification settings - Fork 296
-
newbie to commitizen. I chose all the default values when I tried to install commitzen via homebrew.
2 questions:
- when to use build vs ci?
- i commited .cz.toml and this is the commit message using commitizen
ci(.cz.toml): use conventional commits by way of commitizen
i chose ci
but not sure if I am doing this correctly
Beta Was this translation helpful? Give feedback.
All reactions
I have decided the following:
- am i adding dependency or udpating or removing dependency? if so, then the verb is "add", "update", "remove" respectively
- the type will depend if the dependency changes behavior detected by the user. if so then it's a feat or fix. if it doesn't, then it's a refactor/build/ci depending on the dependency scope
Thank you. I needed this discussion to help me think.
Replies: 1 comment 7 replies
-
I think it's fine. What you have to keep in mind is that ci is ignored by commitizen. When you want a version to be bumped most of the time you have to use fix
or feat
.
And remember the commit message usually ends up in the changelog, so you want to write something meaningful for the reader
Beta Was this translation helpful? Give feedback.
All reactions
-
What I mean is if I were to add dependency or simply update the dependency
What type do I choose (feat,fix,refactor,etc)?
Esp since commitizen default list of choices does not contain "chore"
Beta Was this translation helpful? Give feedback.
All reactions
-
First, you don't need to use cz commit
, you can just do git commit -am "chore: add new dependency", but it will be ignored by the
bump`.
For choosing a type, is up to you, there are 2 philosophies:
- Bump always: this means you'd use something like
fix
andfeat
all the time. When you install a new dependency it could be a dependency that fixes something. This is just simpler to think about: new commits -> new bump - Bump sometimes: some dependencies may introduce fixes, or security updates, others might be just dev dependencies, so it's not necessary. In this case, you choose to ignore some changes, because they don't require a bump, but at the risk of making a mistake of pushing something that should've been a bump. I've had this a lot of times, specially with dependabot, which pushes a
build
for dependencies, and then people ask me if I can release the version manually, because they need either that new dep, or because the constrain in dependencies is a problem for them
Beta Was this translation helpful? Give feedback.
All reactions
-
I agree that I don't always have to use cz commit
But I like how cz makes it clear with a menu for me to choose
So as much as I can, I like to keep within the menu
That's my motivation for this discussion thread
Beta Was this translation helpful? Give feedback.
All reactions
-
I have decided the following:
- am i adding dependency or udpating or removing dependency? if so, then the verb is "add", "update", "remove" respectively
- the type will depend if the dependency changes behavior detected by the user. if so then it's a feat or fix. if it doesn't, then it's a refactor/build/ci depending on the dependency scope
Thank you. I needed this discussion to help me think.
Beta Was this translation helpful? Give feedback.
All reactions
-
No problem, also don't be too rigid, if with time this doesn't work for you, evaluate again, and create new guidelines.
Good luck!
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1