00.6 Git Conventions
Rules and Examples cited here are based on the given ones by Hoang Trung Phong. Thanks for that!
Important to keep in mind when using GIT in a team:
- Commit Related Changes (not a whole day’s work in just one commit!)
- Commit Often (see above)
- Don't Commit Half-Done Work (you can stage it though, for example git add FILENAME)
- Test Your Code Before You Commit
- Write Good Commit Messages (see below!!)
- Use Branches
We recommended the Github Desktop Version or Visual Studio Codes internal Source Code Control for new GIT users.
- Capitalized, short (50 chars or less) summary
- Only more if necessary. Not more than around 72 characters. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
- Always leave the second line blank.
- Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.
- Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically, a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
- Use a hanging indent
-
Example 1 (no description, only summary)
- commit 3114a97ba188895daff4a3d337b2c73855d4632d
- Author: BFFT
- Date: Mon Jun 11 17:16:10 2012 +0100
SW0007 - Update default settings for timer of class XY
-
Example 2 (description as bullet points)
- commit ae878fc8b9761d099a4145617e4a48cbeb390623
- Author: BFFT
- Date: Fri Jun 1 01:44:02 2012 +0000
SW0042 - Refactor ROS package XXX
- Minimize duplicat code in method XY and YZ
- Reduce runtime by eliminating typecast from dict to set
- Add constructor to class ZA to reduce misunderstanding```
