it-wiki:git:conventional_commits
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende Überarbeitung | |||
it-wiki:git:conventional_commits [2023/01/05 23:52] – marko | it-wiki:git:conventional_commits [2023/01/05 23:59] (aktuell) – alte Version wiederhergestellt (2023/01/06 00:51) marko | ||
---|---|---|---|
Zeile 5: | Zeile 5: | ||
But, before talking about how to automatically create our changelogs I have to introduce you to the [[https:// | But, before talking about how to automatically create our changelogs I have to introduce you to the [[https:// | ||
- | or if you use the short version from your terminal: | ||
- | git commit -a -m"< | ||
- | |||
- | Every commit has a type that falls into a predefined category, the specific categories are: | ||
- | |||
- | feat: introduces a new feature to the codebase (this correlates with a MINORin SemVer es: 2.0.0 -> 2.1.0). | ||
- | fix: a bugfix in your codebase (this correlates with a PATCH in semVer es: 2.0.0 -> 2.0.1). | ||
- | BREAKING CHANGE: is a total change of your code, this is also can be used with a previous tag like BREAKING CHANGE: feat: < | ||
- | docs: a change in the README or documentation | ||
- | refactor: a change in production code focused on upgrade code readability and style | ||
- | |||
- | The scope specifies what you have changed, preferably in a single word. | ||
- | The description is a one line that specifies what the change is. | ||
- | |||
- | In Jobtome we also use other types for the every-day usage like chore:, test: , optimization: | ||
- | \\ | ||
\\ | \\ | ||
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages. | The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages. | ||
Zeile 28: | Zeile 12: | ||
{{ : | {{ : | ||
+ | |||
+ | or if you use the short version from your terminal: | ||
+ | '' | ||
+ | |||
+ | Every commit has a **type** that falls into a predefined category, the specific categories are: | ||
+ | |||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | The scope specifies what you have changed, preferably in a single word. | ||
+ | The description is a one line that specifies what the change is. | ||
+ | |||
+ | In [[https:// |
it-wiki/git/conventional_commits.1672962739.txt.gz · Zuletzt geändert: von marko