Reputation: 1079
I was once participating in a data science course and the professor advised that in using git
, commit messages should be added via the editor. He actually advised against using the git commit -m "message"
option. I don't recall why he stated this.
Well, I've consistently ignored this advice, especially when I have very short commit messages, but I was wondering if there is any merit to it. I've searched the web but have not found anything on this.
Upvotes: 1
Views: 291
Reputation: 3179
This morning I got to do git history surgery on master for a new repository where someone accidentally checked in their dependencies and then deleted them (this drives a release management tool we have batty - nodejs JSON.stringify barfs if you hand it an object that is too large).
As one of my coworkers asked, "Shouldn't he have noticed this during the commit?" To which I responded, "not if he used 'git commit -m'".
I found this question while looking for a very good article that crystalized this problem for me about 5 years ago. The author claimed you should outright ban 'git commit -m' and the more time I have to fix problems like this, the more I agree.
Upvotes: 1
Reputation: 28742
If you need to write a multiline commit message and you really trust your own typing you can do
git commit -m "Fix for bug #00001[hit enter]
[hit enter]
By analyzing the foo in the bar the fix resulting in baz was applied.[hit enter]
This fixes the bug and tests have been provided in tests/testBaz0001 directory[hit enter]
"[hit enter]
Do remember that you cannot change what you typed in the previous sentence once you've hit enter, hence the do you trust your own typing.
For complex commits that another person needs to read, use an editor. Or if you feel lucky use commit -m with a multi line message.
Upvotes: 1
Reputation: 1581
It depends a lot on your workflow.
If you work on a local branch, for example a branch dedicated to solve a ticket or implement a feature, you may commit very often, and use git commit -m
. But when you merge or rebase your work in the upstream, then a short message is a bad practice. The goal of git is having a history, so a short message is useless and even if the amount of work is small you want to at least give context and describe your changes. In this type of workflow, commit often with short messages and rebase/merge with a big, nicely formatted message (the choice of formatting is up to you and your team).
Depending on how you integrate your work in your master branch (or whatever useful branch you may have), typically if you do not commit often, you might as well never use git commit -m
but always git commit
.
Upvotes: 1
Reputation: 977
Well your professor was actually right. We should not use git commit -m "message"
because it is not useful for a very descriptive and intricate change.
For instance, writing a message of this sort would be next to impossible via the -m
option. It is always advised to use an editor for the same.
To open the editor, you do a git commit
and it takes you to the default editor you set, where you can type your commits. You can change your editor by changing the .gitconfig
file! :)
I use Vim for this purpose, you can choose any editor you like.
Best.
Upvotes: 2