Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Write a Git Commit Message (2014)

chris.beams.io

Post reply on HN
Print view View original

61–70 of 121 posts

Re: How to Write a Git Commit Message (2014)

#61

Post by ibgib »

1. Git commit templates. 2. Emoji. 3. Bullets in body.

1. Any article on structured git commit messages should mention git commit templates! https://robots.thoughtbot.com/better-commit-messages-with-a-...

I use a commit template for structure, as well as reducing boilerplate for expressive messages. Here is my default template on ibgib: https://github.com/ibgib/ibgib/blob/master/git-commit-templa...

2. I also use emoji (with a key there in the git commit template for reference) to communicate concepts like implemented, bug fix, etc., in a single emoji character. Note though that it is inappropriate when you start to do a pull request, as not all git message viewers will display the emoji. But I find it very useful FTMP.

3. Bullets are a simple way to enable both terse and structured comments within a commit.

Re: How to Write a Git Commit Message (2014)

#62

Post by ibgib »

jph wrote: post #28
jph wrote: post #8

My team uses a git commit message convention that helps us read fast and also is parsable by toolchains. We agree on a short list of leading active verbs: 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,…

Feedback on this git commit message convention is welcome, and so are pull requests: https://github.com/joelparkerhenderson/git_commit_message

I would recommend putting it in a git commit template if you haven't already. This will make it easier to implement the convention IMO.

Re: How to Write a Git Commit Message (2014)

#63

Post by rodovich »

pbh101 wrote: post #37
gregmac wrote: post #19

The only one that really drives me crazy is > Wrap the body at 72 characters Why? Because the git CLI doesn't wrap properly? To borrow a quote, that seems like a 'you' problem, not a me problem. Maybe I'm just biased because these days I almost entirely interact with git through a GUI (either desktop client or web interface), and though I use the CLI occasionally (mostly for branch management, sometimes for quick com…

Linus Torvalds answered exactly this question [0]. Not that that means you should unblinkingly take it on authority, but the original reasoning is: the renderer doesn't alway know when a line should be wrapped. Examples: a stack trace, or long log line, or essentially any other quoted artifact that has a specific pre-determined format. The relevant quote from the link: Some things should not be word-wrapped. They may…

I understand this rationale, but I think most developers will encounter commit messages written by bozos who don't press enter after every 72 characters, far more frequently than commit messages that contain stack traces or other fixed-format artifacts. (Disclosure: I am one of these bozos.) The tool flubs every non-wrapped paragraph just so it can preserve the occasional blob of ASCII art.

If the tool applied reasonable wrapping heuristics and got it wrong once in a while, it could easily offer a `--no-wrap` option to let users see the message exactly as it was composed.

Re: How to Write a Git Commit Message (2014)

#64

Post by ibgib »

wst_ wrote: post #30
data_hope wrote: post #12

My personal, subjective impression: Commits are getting smaller and smaller nowadays. As in: In the subversion days, many people commited only few times a day, sometimes not for several days. SVN commits of course involved a sync with the server (a "push" in git lingo), and thus usually represented a much larger increment with a substantial change to the code base [X] With git, it became very common to structure chan…

I find tons of small commits a clutter and waste of time. I don't see any reason for doing so. On the contrary I can see disadvantage - reading and understanding a history later may become difficult task. After all what counts is your full chunk of work, reviewed via pull request, and merged to master. It should be treated as a whole. Has it really become so common with git? I don't see such trend around me.

> After all what counts is your full chunk of work, reviewed via pull request, and merged to master. It should be treated as a whole.

I find the PR mechanism works great for the view of the whole, whereas the individual commits are great for the pieces. So in my commit history, you can read the timeline, and then if you want to see the commits squashed down, you click on the individual PR. On the PR screen (assuming you're using GitHub), it has a nice list of the subject lines of each of the individual commits.

Re: How to Write a Git Commit Message (2014)

#65

Post by ibgib »

greenhouse_gas wrote: post #16
data_hope wrote: post #12

My personal, subjective impression: Commits are getting smaller and smaller nowadays. As in: In the subversion days, many people commited only few times a day, sometimes not for several days. SVN commits of course involved a sync with the server (a "push" in git lingo), and thus usually represented a much larger increment with a substantial change to the code base [X] With git, it became very common to structure chan…

Would be interesting if there was a way to annotate a set of commits, like "commit ???? - ????: refactored A,B, and C" so you'd get the advantage of small commits and clearer messages.

This is what PRs are good for. Also, with my particular approach to commits, I always have at least one issue associated to a commit, and I'm always working on a particular branch associated to the issue. I pick an emoji that captures the issue/branch in a single concept, and I have that in my subject line. This is combined with my git commit template mechanism, and I like it. At a glance, I can see which commits belong together, and if I want to look at the whole, I go to the PR.

E.g. https://github.com/ibgib/ibgib/pull/180

Re: How to Write a Git Commit Message (2014)

#66

Post by kevinmannix »

I've really welcomed the recent GitHub features such as "squash & merge" and "rebase & merge". Instead of parsing through 200 commits of "typo", "lint", "spacing", a feature is placed in a compact diff with the feature title & related task id as the commit message.

A commit should be a unit of work. Tests should pass before and after. The commit message should describe the change. Ensuring that you have a good commit message then influences what content you contain in a commit.

Re: How to Write a Git Commit Message (2014)

#67

Post by stared »

jph wrote: post #34
stared wrote: post #13

I really recommend angular-style commit messages: https://github.com/angular/angular.js/blob/master/CONTRIBUTI... type(scope) message e.g. feat(button) added play button Types are: - feat: A new feature - fix: A bug fix - docs: Documentation only changes - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - refactor: A code change that neither fixes a bug no…

If you like this format, then you may want to try a similar format that uses the same purpose, plus uses words that easier to read and that make more sense to people in more cultures. We use Add, Fix, Refactor, Reformat, Optimize, etc. See my comment on this thread or https://github.com/joelparkerhenderson/git_commit_message

I don't mind command names.

However, in the linked article no visual separation between type and message (and no scope) is something I consider less useful.

Re: How to Write a Git Commit Message (2014)

#68

Post by bjourne »

It doesn't matter that much. Some things in programming mater a lot, like consistent indentation and casing. Some things doesn't, like perfectly formatted commit messages. whether the verbs in commit messages should be in imperative or present tense is just too much.

I can tell you that I have been programming for a very long time. So if someone asks me "Why does it MATTER if lines are longer than 80 characters?" then I can answer "Because it means that the distribution of line-lengths will be more uniform, meaning that you will be able to fit more code on the screen, meaning that the amount of scrolling you'll have to do when trying to understand the code is greatly reduced." And scrolling interrupts your focus, which is bad. But if I ask someone, "Why does it MATTER if verbs are in present or imperative tense?" no one can answer.

Re: How to Write a Git Commit Message (2014)

#69

Post by nimchimpsky »

jlgaddis wrote: post #45
nimchimpsky wrote: post #32

I can't believe believe people write essays on how to write a git commit message. It even includes an example of not including a full stop - I'm all for examples, but sometimes they are not necessary. Do other people not have actual work to do ?

(I haven't written such an easy. Regardless...) I can't believe people whine about ways I spend my time (or what I choose to write about). It's not like you are being forced to read any of it.

its been submitted to a message board for comments, did you expect everything to be positive ?

GIT commit message are hardly significant, unless you are doing some form of automated release notes - and then you just follow whatever convention is required.

Re: How to Write a Git Commit Message (2014)

#70

Post by flukus »

data_hope wrote: post #12

My personal, subjective impression: Commits are getting smaller and smaller nowadays. As in: In the subversion days, many people commited only few times a day, sometimes not for several days. SVN commits of course involved a sync with the server (a "push" in git lingo), and thus usually represented a much larger increment with a substantial change to the code base [X] With git, it became very common to structure chan…

> As in: In the subversion days, many people commited only few times a day, sometimes not for several days.

This was often the source of merge hell. Half of what makes git merges easier is the smaller commits that it encourages.

Post reply on HN