linux
git commit Argument
There are three topics, but they all tie in together under the discussion of commiting code and making good commit messages.
HOW TO COMMIT CODE PER STANDARDS
git commit $x (bad!)
In this situation most coders would (if with a laugh) quickly type dot (.) or dash-a (-a) if a situation warranted its positive use. However, in most all cases, these are considered bad practice:
Here is a common standard for committing code:
git add -p; git commit;
- git add -p; (followed by)
- git commit;
- git add -p; (followed by)
- git commit;
This is a wise method for committing code.
the "add -p" segment affords programmers a final chance to look out for "gotchas" like "error_log(oops)"
COMMIT MESSAGE CREATION
EXCERPT FROM `GIT LOG --PRETTY==ONELINE`
252321 Merge branch 'stage'
80c402 Merge branch 'feature-7121-replace_app_community_call-2' into stage
2aeb9a fix the total update
4f134e also update the cart.total on pfsweb tax/shipping calculation
840c0d cart_payment.received is supposed to be the ammount we "received" which is best represented for paypal in the PAYMENTINFO_0_AMT from the response
The excerpt shows 5 commit messages, above in bullets. We'll come back to those in a minute.
In vim, the commit message can be color coded. The text color changes when the message length nears 79 characters...and then it turns red...showing the commit msg creator that he or she hath typed too far!).
One of the many good reasons to keep it under 79 is to make the log show up well formatted *and* to provide more room for programmers to show other debugging tricks or notes or even snippets of code that you just weren't sure or maybe even wished there had been a chance to ask someone about, even short comments about how the code should or shouldn't run. One or two lines usually will suffice.
Let's compare...here are (79 characters) and then the (commit msgs) after the single, blank line.:
79 characters vs length of commit messages
Merge branch 'stage' (*252321*)
Merge branch 'feature-replace-tax-call' into stage
Fixed the total update
Also updated the cart.total on client's tax/shipping calculation
cart_payment.received is supposed to be the ammount we "received" which is best represented for filling the AMT_0 element in the response
So we can have our cake and eat it too. Make the commit message 79 or fewer characters, while providing a great bit more detail without ruining the output of `git log`.
A BETTER COMMIT MESSAGE
When making the `git commit` call (after completing hunks adding with `git add -p`), the vim editor launches, and we begin typing, perhaps a commit msg like this:
hotfix-some-complex-stuff: added filtering column
There was a problem with the filtering of the report.
here is an example url: http://foo
What i tried to do was use the actions data to solve it.
Instead, i ended up just putting a column in the database
so i could filter the report using other magic.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch stage
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: asdf
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
In the end, the point is to create a git log that tells a clear story to anyone reading it. Using `git add -p` and `git commit` (without the -m) are the first steps in that direction.
Last Updated: 2013-08-08 19:46:34
