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

91–100 of 121 posts

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

#91

Post by milesrout »

scrollaway wrote: post #87
ajross wrote: post #36

Earlier quoted context omitted.

> 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.

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

No it doesn't. In fact I had to edit a comment I made above this one about four times until I got the formatting right. It annoyingly ignored me doing this:

    line one
    line two
    line three
and assumed I meant this:

    line one line two line three

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

#92

Post by milesrout »

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 particularly like this because it doesn't interfere with the flow of the commit message's first line in explaining what it does. There are too many commits out there that waste half the first line with the ticket number, area of code, etc.

Instead of 'JAT-1241: app/index.js(opt): Optimised the index', 'Optimised the index' should be fine. Tools can understand that, and can already work out which files changed.

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

#93

Post by eriknstr »

blaisio wrote: post #85
eriknstr wrote: post #76

Earlier quoted context omitted.

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.

For my personal projects I often commit unfinished stuff. Using the kinds of flags you describe sounds like a good idea for projects where more people are involved indeed. Thanks.

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

#94

Post by eriknstr »

milesrout wrote: post #90
eriknstr wrote: post #76

Earlier quoted context omitted.

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

Thanks.

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

#95

Post by scrollaway »

milesrout wrote: post #91
scrollaway wrote: post #87

Earlier quoted context omitted.

> 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.

>This text box I'm replying to you with is a plain text textbox. It word-wraps just fine. No it doesn't. In fact I had to edit a comment I made above this one about four times until I got the formatting right. It annoyingly ignored me doing this: line one line two line three and assumed I meant this: line one line two line three

You're talking about the comment output, which is html after being processed. The text box is plaintext, and it word-wraps :)

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

#96

Post by rickycook »

eriknstr wrote: post #93
blaisio wrote: post #85

Earlier quoted context omitted.

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.

For my personal projects I often commit unfinished stuff. Using the kinds of flags you describe sounds like a good idea for projects where more people are involved indeed. Thanks.

well, it works for anything that you deploy often. some features are just big, and you don't want to have something sitting there undeployed for weeks. it helps to have bigger teams, because merging and deploying often is obviously good, but merging and deploying often help to make sure your individual parts don't slow anything down/etc, especially if the feature isn't self contained

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

#97

Post by andrewshadura »

CydeWeys wrote: post #54
phailhaus wrote: post #48

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. I…

Private commits aren't immutable at all. You can change anything about them up until you push them to a remote repository that other people are syncing from. I routinely squash a bunch of private commits together before issuing a public PR, for example.

No they are. You can create different commits replacing them though.

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

#98

Post by phailhaus »

CydeWeys wrote: post #54
phailhaus wrote: post #48

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. I…

Private commits aren't immutable at all. You can change anything about them up until you push them to a remote repository that other people are syncing from. I routinely squash a bunch of private commits together before issuing a public PR, for example.

Commits are immutable; when you squash commits you're replacing them with new ones and rewriting the history. And since there is no difference between your local repository and the remote one, the reason why you wouldn't squash commits on the remote repository is to be nice to your coworkers.

So unlike PR's, if your coworkers criticize your commit messages it's already too late.

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

#99

Post by wst_ »

pm215 wrote: post #89
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.

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

I think it is a matter of definition of "small" and "enormous". If you have a small thing, easily comprehensible, but big enough for it to be a complete piece of work. Then probably you also have separate task for it, and the change you introduce doesn't break the build. So it the end it's just a perfect candidate for pull request.

But note the comment above mentioned a commit for variable change. Or a commit for adding some comment sentence. Nano commits they are.

Sure, tasks should be small, easy to get, easy to review. But there must be a balance. Going to extreme, both ways, doesn't do any good.

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

#100

Post by wst_ »

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

How do you enforce such commits messages? People makes mistakes, or forget stuff. But when you have a pull request, all intermediate commits are already pushed to central repository. They already are public. You can't change them anymore. Pre-commit hook?
Post reply on HN