7 ms·
I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, depe
by navinsylvester 7y ago
I use the following convention to start the subject of commit(posted by someone in a similar HN thread):
Add = Create a capability e.g. feature, test, dependency.
Cut = Remove a capability e.g. feature, test, dependency.
Fix = Fix an issue e.g. bug, typo, accident, misstatement.
Bump = Increase the version of something e.g. dependency.
Make = Change the build process, or tooling, or infra.
Start = Begin doing something; e.g. create a feature flag.
Stop = End doing something; e.g. remove a feature flag.
Refactor = A code change that MUST be just a refactoring.
Reformat = Refactor of formatting, e.g. omit whitespace.
Optimize = Refactor of performance, e.g. speed up code.
Document = Refactor of documentation, e.g. help files.
- ShteiLoups 7y agoYes. As is convention, commit messages should be a one line header, then and empty line an a body (if necessary). The whole thing should be width limited to 80 or 100 characters. And the subject line should complete the sentence "If this commit is applied, it will...". It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.
- deividy 7y ago"It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.", are you seriously?
- wool_gather 7y agoCan you elaborate on your surprise or objection? It may not be obvious to onlookers what you're reacting to.
- deividy 7y agowell, I think if you start with this kind of bureaucracy, you're doing it wrong. It's not funny. Also, if your app is down, clients calling and you need to fix it fast. If I need to remember this rules to fix this, people will kill me, or I will kill myself :p
- ShteiLoups 7y agoAfter a few days practicing this, it becomes second nature, and doesn't hold you up at all. Commit histories also become much quicker to parse through, especially with "log --oneline". I notice no hindrance on my speed because I write good commit messages, and always value them when I one back to them.
- zbentley 7y agoSeems like they are. Also seems like a solid practice that far too many people ignore.
- nonconvergent 7y agoor you can say something equivalent yet unambiguous A good commit message isn't about convention, and no convention makes a commit message good. When I review a commit, I need only the information I won't get from the diff that I need to understand the context and the behavior. My brainpower is a limited resource and extra noise in my signal is extra work. I'm totally here for `ISSUE_123456 fixes defect` and `wip` are insufficient, but I'm not writing a code blog post in there.
- lugg 7y agoAt my work we almost encourage the blog post in there idea. It's not a hard and fast rule and it's ok to ignore it when it makes sense. But we also don't mind if your commit message takes longer to write than the code took to change and debug. A lot of context is assumed in commits, and almost all of it is temporal. Capturing as much of that as possible pays off down the line. Commit in the article is a good example where the context explains much more than the change. (On the flip side, the pay off has an expiry date so I'm not extremely fussed when people lax, but it's still good to check in basic assumptions whith your code)
- deividy 7y agoI fix about 2~4 issues by day, 20~40 commits by day. If I do write a blog post for every commit my productivity will down by 70% at least.
- ShteiLoups 7y agoWell that's the argument about immediate productivity and good documentation.
- nitely 7y agoIf you follow GP's convention then yes, and it's not a bad convention.
- tom_mellior 7y ago> And the subject line should complete the sentence "If this commit is applied, it will...". I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!
- ticmasta 7y agoLike many of the pedantic things we like to argue about, I think teams/projects should choose consistency over prescription.
- reilly3000 7y agoConsistency is just prescription by precedence
- bch 7y agoI think that’s opposing incorrect things, in this case. I think the spirit of The Law should be clear and kept alive. Whether to “[If applied, this commit will] <commit msg here>” or “[This commit]<verb> <work description>” is a tiny matter of difference when the point is clear, straightforward, complete commit msgs of logically discreet-and-coherent commits. Both the above formats would fit the bill, and I think I’d be thrilled if my biggest issue w code commits amongst my team were only these two slightly different formats.
- dhimes 7y agoIs the "subject line" the same as the "header" in this schema?
- ShteiLoups 7y agoYeah, first line, w/e
- pricci 7y agoI also use something like this. A variation of Angular's commit convention[1]. There are tools like commitizen[2] that can help new adopters to build commit messages. [1]: https://gist.github.com/stephenparish/9941e89d80e2bc58a153 https://gist.github.com/stephenparish/9941e89d80e2bc58a153 [2]: https://github.com/commitizen/cz-cli https://github.com/commitizen/cz-cli
- wh-uws 7y agoIf someone made enforcing this convention a git hook I would use it in a heartbeat. I.e. Love using husky to enforce code conventions through linters... Only issue is it would be hard to completely enforce in code and obviously require some review but still nice
- groestl 7y agoI like the convention, but I challenge the idea that optimization can be just a refactoring.
- blaisio 7y agoYes! I thought this was a great idea. The other thing I do is add a "MODULE:" prefix to my commit message. It makes them way more readable. Lots of other people do this too; you can see this in Redis, Linux, and Go codebases, for example. So your message might look like "router: add support for path vars". Much easier to read than "Add support for path vars to router"
- lugg 7y agoWanted to mention this. I don't stick to it as a rule but if it's clearly grouped in some way it gives people in the wider org a high level fyi about the area of code you're messing with. Makes it easy to jump over the commit when bisecting for regressions or hastily looking for the buggy commit to revert.
- webscalist 7y agoEvery commit message must start with JIRA ticket number
- sixstringtheory 7y agoI work at a place that used to prescribe this. I dislike it because it adds too much repetitive noise to the abridged git log. (It occurs to me that you may be making this point in a tongue-in-cheek way.) Originally I suggested we put the JIRA number/link in the commit body, but then I learned about git-notes to add metadata to commits and now I kinda want to do this with the semantic labels suggested by the thread OP, too (I currently use the schema suggested at https://seesparkbox.com/foundry/semantic_commit_messages https://seesparkbox.com/foundry/semantic_commit_messages).
- petepete 7y agoAnd I've used git nearly every day for more than a decade and written a git client, and this is the first time I've heard of notes. Thanks!
- masklinn 7y agoNotes kinda bloat the repository with additional objects, and they can be removed independent from the commits, so I'm a bit iffy on using them for this.
- sixstringtheory 7y agoGood points to consider, thanks! It’s good to know all the tradeoffs.
- gitgud 7y agoThis is a good way to; complicate development, slow down development and add an unnecessary dependency of jira...
- throwaway40324 7y agoThat sounds awful, but I/we do name feature branches as team-<TICKET #>(TICKET TITLE),with the title as usually optional
- hyperpallium 7y agoFormatted for my fellow HN-disenfranchised mobile sufferers: Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing something; e.g. create a feature flag. Stop = End doing something; e.g. remove a feature flag. Refactor = A code change that MUST be just a refactoring. Reformat = Refactor of formatting, e.g. omit whitespace. Optimize = Refactor of performance, e.g. speed up code. Document = Refactor of documentation, e.g. help files.
- agsilvio 7y agoWonderful. Thanks.
- lugg 7y agoWhy? (Honest question, hear me out) Is it a vocab consistency thing? I see pretty consistent vocab used across orgs anyway, so given there is shardd domain knowledge / language at play, im not sure what the goal for standardization is? Don't take this the wrong way, I use a lot of these when appropriate, but I don't think I could agree that refactoring must be just a refactor, and I don't think I want to limit anyone's commits to this list of change types either. Forcing changes into these words means a lot of stuff is pointlessly bucketed when more appropriate wording could be used. Say I want to push a commit "prioritise shipping route a over route b". So I have to put it under start? Optimise? Fix? Why? Prioritise is the right word, why not just use that? Why play mind games when we have a whole dictionary to draw from?
- klodolph 7y agoSome additions I personally use: - Change: change functionality or behavior. - Cleanup: more than formatting, less than refactoring. No functional changes. - Rename: refactoring that changes a name but does nothing else. - Extract: refactoring that creates a new module or class by moving code out of an existing module or class.
- pnako 7y agoIsn't that convention just the English language?