How to write a Git commit message (2014)
1–10 of 185 posts
Re: How to write a Git commit message (2014)
#2I prefer Github's method of "git commit messages don't matter, pull requests do".
Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this:
1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch
2. Have engineers care about the pull request quality rather than commit messages
It's easier to be more expressive in a pull request, and intermediate changes while working on a PR aren't super interesting to me.
Re: How to write a Git commit message (2014)
#3I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
If you really want just one commit on your PR you can reset your branch to its target before you merge:
git reset --soft
Which will undo all commits and leave all modified files in the staging area. Then you can make one commit and force push it to replace your branch @ remote.
Re: How to write a Git commit message (2014)
#4I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
This works well enough if (and only if) your company has a culture of small, atomic PRs.
Re: How to write a Git commit message (2014)
#5I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
If you really want just one commit on your PR you can reset your branch to its target before you merge: git reset --soft Which will undo all commits and leave all modified files in the staging area. Then you can make one commit and force push it to replace your branch @ remote.
Thanks for the tip, man! Really helpful indeed.
Re: How to write a Git commit message (2014)
#6I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
But the PRs aren't part of your git repository? IMO a git repository should be self contained and not require a hosted provide to give context. It lets you manage your work with superior local tooling and without a browser running. Basically I take the exact opposite approach where my PRs are always just a short summary of the commit messages and provides a place for me to put the github specific things like the "Fixes #..". But I make sure my commits are a clean artifact of the changeset by themselves (ie. I do any squashing, etc, on them outside of the PR).
Re: How to write a Git commit message (2014)
#7I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
That's such a different approach than I've grown used to, but different platforms encourage different flows.
I've been using bitbucket (not the shiny nice new bitbucket) at work for years and its PR search is so abysmally bad that anything in the PR message but not in the commit message may as well not exist once its merged. `git log` is forever, bitbucket search is /dev/null
I'm curious what other affordances or lack of affordances encourage what git behavior.
Re: How to write a Git commit message (2014)
#8I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
If you really want just one commit on your PR you can reset your branch to its target before you merge: git reset --soft Which will undo all commits and leave all modified files in the staging area. Then you can make one commit and force push it to replace your branch @ remote.
You could also rebase and squash all commits into a single one and then rewrite the commit message with git commit --amend.
Re: How to write a Git commit message (2014)
#9For those who write multi paragraph commit bodys, is there a tool you use to format them?
Example commit on the React repo [1]. It just seems like a lot to type in the command line.
[1] https://github.com/facebook/react/commit/ec52a5698e2dfea7050...
Re: How to write a Git commit message (2014)
#10I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like
feat: support new line chart
fix: update props for new line chart
chore: bump dependency version
What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore etc) to determine the next appropriate version [1].