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

81–90 of 121 posts

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

#81

Post by petepete »

rosser wrote: post #7
pmontra wrote: post #2

The most important tip is "Use the body to explain what and why vs. how". I'd also say: remove thw -m option from git and force people to open the editor. Do not accept messages shorter than 3 lines, start the editor with a template Title What changed and why it changed.

Dogmatism like "commit messages must be at least three lines" will result in commit messages like: here's some code. Concentrating on form over substance is myopic.

Totally agree. Using three lines of text to describe fixing a typo in the comments or rewording/reformatting a block of text will just lead to an unclear message.

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

#82

Post by jwdunne »

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 a great idea. Interestingly, Google has a tool that will analyse your git history and identify "hotspots" i.e code that is regularly associated with commit messages with words like "fix".

I'm wondering if the same general idea is applicable to other types of commits given your list. For example, if you are regularly adding features and a certain part of the code base is touched, perhaps with a lower ratio of "refactor" commits, that code could be a solid candidate for refactoring.

Here's the tool i mentioned anyway https://google-engtools.blogspot.co.uk/2011/12/bug-predictio...

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

#83

Post by frant-hartm »

clusmore wrote: post #53
wst_ wrote: post #30

Earlier quoted context omitted.

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.

>On the contrary I can see disadvantage - reading and understanding a history later may become difficult task. I'm replying to you but this is directed at everybody who advocates squash merge and discourages small commits. IMO this is a tooling problem, plain and simple. When I am committing to Git, I am using the "write" components of Git which are incredibly powerful. I can commit in as small a chunk as I want and…

There is "Collapse Linear Branches" action in Intellij's git log viewer (and I guess any Jetbrains IDE) which does pretty much what you describe :-)

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

#84

Post by pbosko »

My team uses task number and title as a commit message. We just can't fit all the description from task into one line of comment. So, when we look at git blame - we get a reference to a task in project management tool where we can find all the reasons behind a given change.

If there are more commits for the same task, all of them bare the same commit message. After each review, we add a comment to project management tool. That way we focus only on newer commits when performing another round of reviews.

Every other attempt to describe changes and intentions in one line seems doomed to me.

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

#85

Post by blaisio »

eriknstr wrote: post #76
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,…

I like all of these but am wondering what the following two mean. Start = Begin doing something; e.g. create a feature flag. Stop = End doing something; e.g. remove a feature flag. Could someone explain these and give a few examples?

The idea is usually to allow committing partially completed or deployed features, which are hidden by config flags until you're ready to activate them. When the feature is fully baked and effectively always on in production, you just remove the flag to make it permanent.

Using feature flags can increase a team's productivity by encouraging multiple commits a day, every day. It can also make rollbacks faster.

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

#86

Post by _pmf_ »

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

Useful; never actually thought about using ubiquitous language here, but it makes absolute sense.

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

#87

Post by scrollaway »

ajross wrote: post #36
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…

> Why? Because the git CLI doesn't wrap properly? First off, the commit message is plain text (by design) and can't be "wrapped" automatically, and any tool that tried would be insane. The reason for 72 characters is that the CLI, like lots of other presentation mechanisms (including quoting in other commits or in code), wants to indent your message for readability. And the uniform standard width for terminals has be…

> First off, the commit message is plain text (by design) and can't be "wrapped" automatically, and any tool that tried would be insane.

This text box I'm replying to you with is a plain text textbox. It word-wraps just fine.

There's myriads of plain text inputs and outputs you encounter every day and they all word wrap just fine.

The terminal is an aberration in that regard.

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

#89

Post by pm215 »

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.

The main reason I request commits to be split up is for ease of code review. It's much easier to review three commits that each do one easily comprehensible small thing than one commit that does three things at once. It's also better if you find there's a bug -- you can bisect down to a commit that's fairly small where the bug should be easy to see, rather than one that's enormous and where the bug is hard to find among all the other changes.

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

#90

Post by milesrout »

eriknstr wrote: post #76
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,…

I like all of these but am wondering what the following two mean. Start = Begin doing something; e.g. create a feature flag. Stop = End doing something; e.g. remove a feature flag. Could someone explain these and give a few examples?

The current buzzword for feature flags is 'branch by abstraction'.

The idea is that instead of making a version control branch to change feature A to feature B and then merging back into the mainline of development, you build an abstraction over the thing you want to change, build a new implementation of that abstraction, switch out the two and then (if you like) remove the abstraction, all within the main line of development.

So instead of history that looks like this:

    *    Merge branch 'feature-cookie-login' into master
    |\
    | *  Polish up cookie feature
    | |
    . *  Switch from tokens to cookies
    . |
    . *  Clean up and refactor login code
    |/
    .
    .
    .
Your history looks like this:

    * Stop abstracting the authentication type.
    |
    * Switch from auth tokens to session cookies
    |
    * Add a SessionCookie authentication type.
    |
    * Start abstracting the authentication tokens as a generic authentication type
    |
    .
    .
    .
But with any completely arbitrary commits interspersed between those commits, as none of them break other code. The first one creates an interface, the second one reimplements the interface, the third switches the used implementation and the optional fourth removes the abstraction and deletes the old implementation.
Post reply on HN