GIT Commit Good Practice
Git commit messages can be considered like a well formed email, it contains a subject line, a body and additional metadata.
topic: Short commit subject Commit description spanning multiple lines while staying bound to the 79col limit. Bug-Id: 1234 CC: firstname.lastname@example.org Sample-Id: 00000000-zzuff Signed-off-by: Name Surname <email@example.com>
- The first line should be limited to 50 characters and should not end with a period.
- The body message should wrap at 80col
The metadata tags should appear after the body with a newline separating it.
A commit should be as atomic as possible, short and impacting the smallest portion of code. Git provides tools such as git bisect that work the best with such small commits and overall reviewing small changes is easier.
The topic should not the same as the filename, but just hint the area of the code it impacts, e.g.: lavc is a good topic for a patch doing wide changes over libavcodec, build is a good topic for a patch improving the build system.
To add additional information such as a commentary or a link to your repository you can use the --annotate option when using git-send-email and write below the --- line.
topic: Short commit subject Commit description spanning multiple lines while staying bound to the 79col limit. Bug-Id: 1234 CC: firstname.lastname@example.org Sample-Id: 00000000-zzuff Signed-off-by: Name Surname <email@example.com> --- This is a commentary to the patch, it will not appear in the tree but will help tracking it if I add a http://link/to/my/repository or if I put my doubt about the patch here so the reviewer can answer me directly. libavcodec/utils.c | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-)
In case a broader email should be sent the --compose option can be used to have an initial email before the set of patches.