just going to leave this here: http://stopwritingramblingcommitmessages.com
How to Write a Git Commit Message (2014)
71–80 of 121 posts
Re: How to Write a Git Commit Message (2014)
#72My 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…
Changing _public_ history is bad. I don't see any problem with rewriting your _personal_ history before merging it in.
Re: How to Write a Git Commit Message (2014)
#73My 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…
[the merge commmit message] is where I would like people to really take the time and describe the change extensively
Re: How to Write a Git Commit Message (2014)
#74My 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…
[the merge commmit message] is where I would like people to really take the time and describe the change extensively http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03492.html
Never thought of that usage of merge commits. This is a great place to write the couple paragraphs that you might have in a Pull Request, better than squashing IMO.
I've found that for smaller commits, if you have something long you want to explain in the commit message body... you should probably put it in a code comment!
If you don't think it merits a code comment, it's probably not important enough for people to look up the commit message body either (if only because the commit message body is less likely to be seen).
Re: How to Write a Git Commit Message (2014)
#75My 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,…
Not a bad idea actually. It's like the PowerShell 'approved verbs'. At first I was like 'meh' but after a while it makes sense as it greatly improves discoverability. Looking at a couple of repositories I contribute to this also looks close to what 'good' committers tend to use automatically.
Re: How to Write a Git Commit Message (2014)
#76My 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?
Re: How to Write a Git Commit Message (2014)
#77My 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…
Changing _public_ history is bad. I don't see any problem with rewriting your _personal_ history before merging it in.
Not only not a problem, but a must in my book and I'm fairly sure I'm not alone. For me it's like a new workflow which I always wanted but never could have without git. A lot of days for me now consist of creating a lot of small commits and then every couple of hours when a single 'thing' is finished, start an interactive rebase and create a storyline which is easy to read, understand and follow. This can be even one commit sometimes if it makes sense. And in repos I manage myself an if the change spans several days it's usually big and I might create a seperate branch and have a merge commit so it's extra clear all commits belong to feature/xxx.
Re: How to Write a Git Commit Message (2014)
#78My 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,…
conventions on commit messages can turn the git log to a good project's story, take a look at "Angular vs React : text analysis of commit messages" for the example https://medium.com/@sAbakumoff/angular-vs-react-text-analysi...
Re: How to Write a Git Commit Message (2014)
#79Earlier quoted context omitted.
> 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? :)
Wow. That took some commitment!
There's actually a paragraph at the end about that too :)
Re: How to Write a Git Commit Message (2014)
#80He mentions using the imperative mood for the subject line, but doesn't anyone else think it makes more sense and sounds better to use the present tense, e.g. Opens the pod bay doors Instead of Open the pod bay doors ?
Maybe but it's nice to fit in with the existing imperative mood in the automatic commits (Merge x into y)
You can read them in your head like this "Applying this commit will $MSG"