3 ms·

Show HN: Git commit template 7.0 with recommendations and new trailers

7 points by jph 5y ago

nivertech 5y ago
Is there a similar template, but for conventional commits[1]? [1] https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ EDIT: We reject the git commit message style of projects such as Angular, Commitizen defaults, etc. - Because these use a leading tag that is sometimes a word, sometimes an abbreviation, sometimes a plural noun, etc. - Examples are using "feat" for feature, "docs" for document, "perf" for performance improvement, etc. - Instead we use "Add" for adding a feature, "Document" for documenting help, "Optimize" for performance improvement, etc. - Active verbs are easier to skim, and easier to use for people from other cultures who may be less-comfortable using English. and We reject using a ticket id number in the summary line. - Instead, we use fully-qualified URLs in the commit message body. - This is because many of our projects use multiple tracking systems, and multiple ways of launching a URL. - We want URL tracking to be easy to use by a wide range of systems, scripts, and teams. I disagree with the first point. The second point makes sense if you use multiple issue trackers, but doesn't make sense if you're standardized on Github Issues. https://github.com/joelparkerhenderson/git-commit-message#reject-these-formats https://github.com/joelparkerhenderson/git-commit-message#re...
- jph 5y ago
  Good question thank you. Yes anyone can create their own template, exactly the way they want. A git template is simply a plain text file with a tiny smattering of special syntax such as for the git trailers. > The second point makes sense if you use multiple issue trackers, but doesn't make sense if you're standardized on Github Issues. It turns out it still makes sense to use full URLs, for example if you care about automating workflows, because popular parsers are able to scan for URLs and link them. For example, popular parsers are able to scan "https://github.com/foo/bar/issues/123 https://github.com/foo/bar/issues/123" as a URL then automatically link to its destination. For contrast, popular parsers are not preconfigured to scan "#123" as a GitHub issue tracker id, nor automatically link to its destination. If you try reading commit messages with URLs versus issue ids in a variety of editors, you'll likely see the effect as the URLs do automatic linking. We like this convenience. Of course YMMV and do what's right for you and your project.

7 points by jph 5y ago

Is there a similar template, but for conventional commits[1]? [1] https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ EDIT: We reject the git commit message style of projects such as Angular, Commitizen defaults, etc. - Because these use a leading tag that is sometimes a word, sometimes an abbreviation, sometimes a plural noun, etc. - Examples are using "feat" for feature, "docs" for document, "perf" for performance improvement, etc. - Instead we use "Add" for adding a feature, "Document" for documenting help, "Optimize" for performance improvement, etc. - Active verbs are easier to skim, and easier to use for people from other cultures who may be less-comfortable using English. and We reject using a ticket id number in the summary line. - Instead, we use fully-qualified URLs in the commit message body. - This is because many of our projects use multiple tracking systems, and multiple ways of launching a URL. - We want URL tracking to be easy to use by a wide range of systems, scripts, and teams. I disagree with the first point. The second point makes sense if you use multiple issue trackers, but doesn't make sense if you're standardized on Github Issues. https://github.com/joelparkerhenderson/git-commit-message#reject-these-formats https://github.com/joelparkerhenderson/git-commit-message#re...

jph 5y ago
Good question thank you. Yes anyone can create their own template, exactly the way they want. A git template is simply a plain text file with a tiny smattering of special syntax such as for the git trailers. > The second point makes sense if you use multiple issue trackers, but doesn't make sense if you're standardized on Github Issues. It turns out it still makes sense to use full URLs, for example if you care about automating workflows, because popular parsers are able to scan for URLs and link them. For example, popular parsers are able to scan "https://github.com/foo/bar/issues/123 https://github.com/foo/bar/issues/123" as a URL then automatically link to its destination. For contrast, popular parsers are not preconfigured to scan "#123" as a GitHub issue tracker id, nor automatically link to its destination. If you try reading commit messages with URLs versus issue ids in a variety of editors, you'll likely see the effect as the URLs do automatic linking. We like this convenience. Of course YMMV and do what's right for you and your project.