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

41–50 of 121 posts

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

#41

Post by nighthawk454 »

We've used this style in our commit messages for a few years, and it's been great. We also only allow fast-forward merges of squashed commits for our branching strategy.

  [ISSUE-ID]: Title

  [Problem]
  State problem and customer impact

  [Solution]
  Describe and justify solution

  [Test]
  Describe automated/manual testing

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

#42

Post by steveklabnik »

nitemice wrote: post #24
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…

Sounds like your markdown interpreter has an issue, or you're leaving lots of white space at the end of your lines. Generally, in markdown, if you insert a line break, it won't translate to an explicit line break unless you put two in a row, or if there is 2+ spaces at the end of the line. See [1] for an illustration [1]( https://johnmacfarlane.net/babelmark2/?text=This+line%0Ashou... )

Either behavior is allowed by the CommonMark spec, in fact.

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

#43

Post by component »

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,…

This is great

Some of the active verbs are also commands that automatically close/reference issues right out of the box on GitHub & BitBucket (& I'm sure on GitLab too)

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

#44

Post by ribasushi »

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…

> What I do miss however, is a good description of the overall change.

https://github.com/ribasushi/dbix-class/commit/1cf609901

Something like that I take it? :)

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

#45

Post by jlgaddis »

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.

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

#46

Post by nothrabannosir »

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.

Small, incremental commits are an asset with git blame, git bisect and git revert. I find it much easier to deal with too many small ones, rather than too few large ones. Especially if you keep the convention that master is always "merged into", i.e. "left of the merge", i.e. "parent 1".

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

#47

Post by achr2 »

The main issue with commits is that they end up representing more than a single logical change.

Are there any tools that allow you to initiate a commit as an 'intention stack' for work I am about to do, rather than work I have already done?

I'd love to be able to write an intent message "refactor XYZ.." before starting in on that activity, then when I have to go down another rabbit hole in the middle I push another intent message to the stack, then pop back out afterward and continue with XYZ. The final overall commit message could be auto generated from the initial intention and all tangents.

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

#48

Post by phailhaus »

Git has zero opinion on when you commit or what the messages are. Commits are made in private. Commits are also immutable. This is a losing battle.

If you use a code management tool like BitBucket or GitHub, it seems like the unit of work is less a commit and more a PR. A PR's description can always be edited and refined for future engineers, and a PR (almost) always represents a block of work that can be reverted. Instead of creating a hundred different approaches to writing commits that engineers essentially have to get right the first time, why not just focus on documentation in the form of PR's? It seems like if you could trivially tie a commit back to the PR and ticket it came from, most of these problems would be solved.

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

#49

Post by jononor »

achr2 wrote: post #47

The main issue with commits is that they end up representing more than a single logical change. Are there any tools that allow you to initiate a commit as an 'intention stack' for work I am about to do, rather than work I have already done? I'd love to be able to write an intent message "refactor XYZ.." before starting in on that activity, then when I have to go down another rabbit hole in the middle I push another i…

Commit each of the changes you make, including possible detours etc. Then use git rebase -i to work it into a sane history later.
Post reply on HN