{"id":27671,"date":"2017-06-08T01:23:54","date_gmt":"2017-06-07T23:23:54","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=27671"},"modified":"2017-06-08T01:23:54","modified_gmt":"2017-06-07T23:23:54","slug":"git-commit-good-practice","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2017\/06\/08\/git-commit-good-practice\/","title":{"rendered":"Git Commit Good Practice"},"content":{"rendered":"<!-- google_ad_section_start -->\n<p><a href=\"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2017\/06\/git_commit.png?ssl=1\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" data-attachment-id=\"27672\" data-permalink=\"https:\/\/mamchenkov.net\/wordpress\/2017\/06\/08\/git-commit-good-practice\/git_commit\/\" data-orig-file=\"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2017\/06\/git_commit.png?fit=439%2C250&amp;ssl=1\" data-orig-size=\"439,250\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"git_commit\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2017\/06\/git_commit.png?fit=439%2C250&amp;ssl=1\" class=\"aligncenter size-full wp-image-27672\" src=\"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2017\/06\/git_commit.png?resize=439%2C250&#038;ssl=1\" alt=\"\" width=\"439\" height=\"250\" \/><\/a><\/p>\n<p><a href=\"http:\/\/wiki.openstack.org\/\">Open Stack wiki<\/a> has an excellent guide on <a href=\"https:\/\/wiki.openstack.org\/wiki\/GitCommitMessages\">how to create good commits<\/a>. \u00a0In a few places it is too specific to Open Stack development practices, but overall it&#8217;s one of the best guides I&#8217;ve seen for any project using git.<\/p>\n<p>It is basically split into two sections. \u00a0One on how to decide <a href=\"https:\/\/wiki.openstack.org\/wiki\/GitCommitMessages#Structural_split_of_changes\">which code goes into the git commit<\/a>, and the other is <a href=\"https:\/\/wiki.openstack.org\/wiki\/GitCommitMessages#Information_in_commit_messages\">what to include in the git commit message<\/a> to make it useful.<\/p>\n<p>The first part is simpler:<\/p>\n<blockquote><p>The cardinal rule for creating good commits is to ensure there is only one &#8220;logical change&#8221; per commit. There are many reasons why this is an important rule:<\/p>\n<ul>\n<li>The smaller the amount of code being changed, the quicker &amp; easier it is to review &amp; identify potential flaws.<\/li>\n<li>If a change is found to be flawed later, it may be necessary to revert the broken commit. This is much easier to do if there are not other unrelated code changes entangled with the original commit.<\/li>\n<li>When troubleshooting problems using Git&#8217;s bisect capability, small well defined changes will aid in isolating exactly where the code problem was introduced.<\/li>\n<li>When browsing history using Git annotate\/blame, small well defined changes also aid in isolating exactly where &amp; why a piece of code came from.<\/li>\n<\/ul>\n<\/blockquote>\n<p>With these things to avoid:<\/p>\n<blockquote>\n<ul>\n<li><b>Mixing whitespace changes with functional code changes.<\/b><\/li>\n<li><b>Mixing two unrelated functional changes.<\/b><\/li>\n<li><b>Sending large new features in a single giant commit.<\/b><\/li>\n<\/ul>\n<\/blockquote>\n<p>The second part is slightly more detailed. \u00a0Here&#8217;s the information that should be included in the commit message, generally speaking (abbreviated quote):<\/p>\n<blockquote><p>As important as the content of the change, is the content of the commit message describing it. When writing a commit message there are some important things to remember<\/p>\n<ul>\n<li><b>Do not assume the reviewer understands what the original problem was.<\/b><\/li>\n<li><b>Do not assume the reviewer has access to external web services\/site.<\/b><\/li>\n<li><b>Do not assume the code is self-evident\/self-documenting.<\/b><\/li>\n<li><b>Describe <i>why<\/i> a change is being made.<\/b><\/li>\n<li><b>Read the commit message to see if it hints at improved code structure.<\/b><\/li>\n<li><b>Ensure sufficient information to decide whether to review.<\/b><\/li>\n<li><b>The first commit line is the most important.<\/b><\/li>\n<li><b>Describe any limitations of the current code.<\/b><\/li>\n<li><b>Do not include patch set-specific comments.<\/b><\/li>\n<\/ul>\n<p>In other words, if you rebase your change please don&#8217;t add &#8220;Patch set 2: rebased&#8221; to your commit message. That isn&#8217;t going to be relevant once your change has merged. Please <i>do<\/i> make a note of that in Gerrit as a comment on your change, however. It helps reviewers know what changed between patch sets. This also applies to comments such as &#8220;Added unit tests&#8221;, &#8220;Fixed localization problems&#8221;, or any other such patch set to patch set changes that don&#8217;t affect the overall intent of your commit.<\/p><\/blockquote>\n<p>Read <a href=\"https:\/\/wiki.openstack.org\/wiki\/GitCommitMessages\">the whole thing<\/a> for more details, examples of good and bad practices, and more specific instructions on the spacing, line length, and more.<\/p>\n<p>And if you need more convincing or a different explanation, then Google &#8220;<em>git commit best practices<\/em>&#8221; or simply check out some of these resources:<\/p>\n<ul>\n<li><a href=\"https:\/\/sethrobertson.github.io\/GitBestPractices\/\">Commit Often, Perfect Later, Publish Once: Git Best Practices<\/a><\/li>\n<li><a href=\"https:\/\/chris.beams.io\/posts\/git-commit\/\">How to Write a Git Commit Message<\/a><\/li>\n<li><a href=\"https:\/\/stackoverflow.com\/questions\/6543913\/git-commit-best-practices\">StackOverflow : git commit best practices<\/a><\/li>\n<li><a href=\"https:\/\/robots.thoughtbot.com\/5-useful-tips-for-a-better-commit-message\">5 Useful Tips For A Better Commit Message<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/trein\/dev-best-practices\/wiki\/Git-Commit-Best-Practices\">Git Commit Best Practices<\/a><\/li>\n<li><a href=\"https:\/\/alistapart.com\/article\/the-art-of-the-commit\">The Art of the Commit<\/a><\/li>\n<\/ul>\n<!-- google_ad_section_end -->\n","protected":false},"excerpt":{"rendered":"<!-- google_ad_section_start -->\n<p>Open Stack wiki has an excellent guide on how to create good commits. \u00a0In a few places it is too specific to Open Stack development practices, but overall it&#8217;s one of the best guides I&#8217;ve seen for any project using git. It is basically split into two sections. \u00a0One on how to decide which code &hellip; <a href=\"https:\/\/mamchenkov.net\/wordpress\/2017\/06\/08\/git-commit-good-practice\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Git Commit Good Practice<\/span><\/a><\/p>\n<!-- google_ad_section_end -->\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"Git Commit Good Practice #git #VersionControl #BestPractice","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"_links_to":"","_links_to_target":""},"categories":[1,18,62,1334],"tags":[3069,2265,1588],"keyring_services":[],"class_list":["post-27671","post","type-post","status-publish","format-standard","hentry","category-general","category-programming","category-technology","category-web-work","tag-best-practices","tag-git","tag-version-control"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":17655,"url":"https:\/\/mamchenkov.net\/wordpress\/2013\/01\/09\/git-separating-folder-into-different-repository-with-history\/","url_meta":{"origin":27671,"position":0},"title":"Git : separating folder into different repository, with history","author":"Leonid Mamchenkov","date":"January 9, 2013","format":false,"excerpt":"First things first. \u00a0If you don't use git for version control yet, stop right now and go plan your migration. \u00a0You'll thank me later. \u00a0Now. \u00a0A few days ago I had a tricky problem. \u00a0A chunk of code that was initially all over the project has been refactored into a\u2026","rel":"","context":"In &quot;All&quot;","block_context":{"text":"All","link":"https:\/\/mamchenkov.net\/wordpress\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":29094,"url":"https:\/\/mamchenkov.net\/wordpress\/2018\/12\/13\/on-good-commit-messages\/","url_meta":{"origin":27671,"position":1},"title":"On good commit messages","author":"Leonid Mamchenkov","date":"December 13, 2018","format":false,"excerpt":"The evolution goes on.\u00a0 Now that we've kind of sorted out most of our infrastructure, development tools, flows and processes, I guess, it's time to look deeper into the things we've had for a while and reiterate over them. Recently, I'm seeing a lot of blog posts on articles on\u2026","rel":"","context":"In &quot;All&quot;","block_context":{"text":"All","link":"https:\/\/mamchenkov.net\/wordpress\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":24691,"url":"https:\/\/mamchenkov.net\/wordpress\/2015\/09\/01\/gitfs-version-controlled-file-system\/","url_meta":{"origin":27671,"position":2},"title":"gitfs &#8211; version controlled file system","author":"Leonid Mamchenkov","date":"September 1, 2015","format":false,"excerpt":"This was only a matter of time ... gitfs\u00a0- version controlled file system: gitfs was designed to bring the full powers of git to everyone, no matter how little they know about versioning. A user can mount any repository and all the his changes will be automatically converted into commits.\u2026","rel":"","context":"In &quot;All&quot;","block_context":{"text":"All","link":"https:\/\/mamchenkov.net\/wordpress\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":23545,"url":"https:\/\/mamchenkov.net\/wordpress\/2015\/02\/18\/git-stats-a-github-like-contributions-calendar-but-locally-with-all-your-git-commits\/","url_meta":{"origin":27671,"position":3},"title":"git-stats &#8211; a GitHub-like contributions calendar, but locally, with all your git commits","author":"Leonid Mamchenkov","date":"February 18, 2015","format":"link","excerpt":"git-stats - a GitHub-like contributions calendar, but locally, with all your git commits","rel":"","context":"In &quot;All&quot;","block_context":{"text":"All","link":"https:\/\/mamchenkov.net\/wordpress\/category\/general\/"},"img":{"alt_text":"git-stats","src":"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2015\/02\/git-stats-500x369.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":27845,"url":"https:\/\/mamchenkov.net\/wordpress\/2017\/08\/14\/pre-commit-a-framework-for-managingmulti-language-git-pre-commit-hooks\/","url_meta":{"origin":27671,"position":4},"title":"pre-commit &#8211; a framework for managingmulti-language git pre-commit hooks","author":"Leonid Mamchenkov","date":"August 14, 2017","format":false,"excerpt":"From the pre-commit homepage: Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this\u2026","rel":"","context":"In &quot;All&quot;","block_context":{"text":"All","link":"https:\/\/mamchenkov.net\/wordpress\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":14826,"url":"https:\/\/mamchenkov.net\/wordpress\/2011\/05\/05\/branches-graph-at-github\/","url_meta":{"origin":27671,"position":5},"title":"Branches graph at GitHub","author":"Leonid Mamchenkov","date":"May 5, 2011","format":false,"excerpt":"One of my favorite features of GitHub (and, probably, pretty much any other git client) is the graphical representation of branches. \u00a0It usually gives a crystal clear picture of how the source tree came about to be. \u00a0But I think today I actually managed to confuse the heck out of\u2026","rel":"","context":"In &quot;All&quot;","block_context":{"text":"All","link":"https:\/\/mamchenkov.net\/wordpress\/category\/general\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2011\/05\/github-confused.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"jetpack_sharing_enabled":true,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/posts\/27671","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/comments?post=27671"}],"version-history":[{"count":0,"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/posts\/27671\/revisions"}],"wp:attachment":[{"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/media?parent=27671"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/categories?post=27671"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/tags?post=27671"},{"taxonomy":"keyring_services","embeddable":true,"href":"https:\/\/mamchenkov.net\/wordpress\/wp-json\/wp\/v2\/keyring_services?post=27671"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}