{"id":2725,"date":"2024-04-29T14:51:55","date_gmt":"2024-04-29T14:51:55","guid":{"rendered":"https:\/\/blog.samarthya.me\/wps\/?p=2725"},"modified":"2024-07-01T15:18:58","modified_gmt":"2024-07-01T15:18:58","slug":"git-commit-logs","status":"publish","type":"post","link":"https:\/\/blog.samarthya.me\/wps\/2024\/04\/29\/git-commit-logs\/","title":{"rendered":"Git: Commit logs"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Every project has a story, and in the world of software development, that story is often told through commit logs. For those unfamiliar, Git is a version control system used for tracking changes in code. Commit logs are the detailed record of those changes, providing a crucial window into a project’s history.<\/p>\n\n\n\n

In this blog, we’ll delve into the world of Git commit logs, exploring how they work and how you can maintain them effectively.<\/p>\n\n\n\n

What’s in a Commit Log?<\/strong><\/h2>\n\n\n\n

When you make changes to your code and commit them using Git, you’re essentially creating a snapshot of your project at that specific point in time. Each commit includes several key pieces of information:<\/p>\n\n\n\n

    \n
  • Commit Hash:<\/strong> A unique identifier for the commit, like a fingerprint for your code.<\/li>\n\n\n\n
  • Author:<\/strong> Who made the changes (usually includes name and email address).<\/li>\n\n\n\n
  • Date:<\/strong> When the changes were committed.<\/li>\n\n\n\n
  • Commit Message:<\/strong> A brief description of the changes made.<\/li>\n<\/ul>\n\n\n\n

    This commit message is the heart of a good commit log. It should be clear, concise, and informative, explaining what was changed and why.<\/p>\n\n\n\n

    Maintaining Clear Commit Logs<\/strong><\/p>\n\n\n\n

    Here are some tips for keeping your commit logs clean and informative:<\/h3>\n\n\n\n
      \n
    • Write Descriptive Messages:<\/strong> Avoid vague messages like “Fixed stuff.” Instead, explain what was fixed and how it benefits the project.<\/li>\n\n\n\n
    • Focus on Functionality:<\/strong> The message should describe the changes made to the code’s functionality, not the specific lines of code edited.<\/li>\n\n\n\n
    • Use Proper Tense:<\/strong> Commit messages are written in the past tense, as they represent a completed action.<\/li>\n\n\n\n
    • Keep it Consistent:<\/strong> Develop a convention for formatting your commit messages, ensuring a uniform look and feel throughout the log.<\/li>\n<\/ul>\n\n\n\n

      Benefits of Clean Commit Logs<\/strong><\/h3>\n\n\n\n

      Clear commit logs provide a multitude of benefits for developers:<\/p>\n\n\n\n

        \n
      • Improved Collaboration:<\/strong> Team members can easily understand the project’s history and the rationale behind changes.<\/li>\n\n\n\n
      • Easier Debugging:<\/strong> When issues arise, clear commit messages help pinpoint the exact change that might have introduced the problem.<\/li>\n\n\n\n
      • Project Tracking:<\/strong> Commit logs act as a roadmap, allowing developers to track the evolution of the project over time.<\/li>\n<\/ul>\n\n\n\n

        Tools for Effective Log Management<\/strong><\/h3>\n\n\n\n

        While Git itself provides the git log<\/code> command for viewing commit history, several helpful tools can enhance log management:<\/p>\n\n\n\n

          \n
        • Git Graphical Interfaces:<\/strong> Many Git GUI clients offer a visual representation of commit history, making it easier to navigate and understand.<\/li>\n\n\n\n
        • Commit Message Linters:<\/strong> These tools enforce best practices for writing commit messages, ensuring consistency and clarity.<\/li>\n<\/ul>\n\n\n\n

          Modifying a commit log?<\/h3>\n\n\n\n
          \n
          \"\"<\/figure>\n<\/div>\n\n\n\n

          Ever made a commit message that could use some improvement? Thankfully, Git offers ways to modify existing commit messages. Here’s a breakdown of the steps depending on the commit you want to change:<\/p>\n\n\n\n

          Recent Commit (not yet pushed):<\/strong><\/h3>\n\n\n\n

          This is the simplest scenario. Use the git commit --amend<\/code> command:<\/p>\n\n\n\n

            \n
          1. Navigate to your Git repository using your terminal.<\/li>\n\n\n\n
          2. Run the command git commit --amend<\/code>. This opens your default text editor with the current commit message.<\/li>\n\n\n\n
          3. Edit the message to your liking, ensuring clarity and conciseness.<\/li>\n\n\n\n
          4. Save and close the editor. Git will create a new commit with the updated message, replacing the previous one.<\/li>\n<\/ol>\n\n\n\n

            Older Commit (or Pushed Commit):<\/strong><\/h3>\n\n\n\n

            Here, things get a bit more involved. We’ll use interactive rebasing:<\/p>\n\n\n\n

              \n
            1. Navigate to your Git repository.<\/li>\n\n\n\n
            2. Run the command git rebase -i HEAD~n<\/code>, where n<\/code> is the number of commits you want to go back and edit (usually around 3-5 is manageable). This opens a list of the specified commits in your editor.<\/li>\n\n\n\n
            3. Locate the commit with the message you want to change. In front of the commit line, replace pick<\/code> with reword<\/code>.<\/li>\n\n\n\n
            4. Save and close the editor. Git will walk you through each commit on the list you selected for rebasing.<\/li>\n\n\n\n
            5. When prompted for the specific commit you want to modify, edit the commit message using your preferred editor.<\/li>\n\n\n\n
            6. After modifying the message, save and close the editor.<\/li>\n\n\n\n
            7. Git will automatically create a new commit with the updated message.<\/li>\n\n\n\n
            8. When you are ready you need to push the changes<\/li>\n<\/ol>\n\n\n\n
              git push --force origin <your branch><\/code><\/pre>\n\n\n\n
              Reverting to a last commit?<\/h3>\n\n\n\n
              There are two main approaches to revert to the last nth<\/code> commit<\/code> that was pushed<\/em>, depending on your situation and comfort level with rewriting Git history:<\/p>\n\n\n\n
              Option 1: Using Git Revert (Recommended for Un-pushed or Private Branches)<\/strong><\/h4>\n\n\n\n
              This method is ideal if you haven’t pushed your commits to a remote repository (like GitHub) or if you’re working on a private branch. It creates a new commit that effectively undoes the changes introduced in the last nth commit(s).<\/p>\n\n\n\n
              Here’s how to do it:<\/p>\n\n\n\n
                \n
              1. Navigate to your Git repository using your terminal.<\/li>\n\n\n\n
              2. Run the command git revert HEAD~n<\/code>, where n<\/code> is the number of commits you want to revert.<\/li>\n<\/ol>\n\n\n\n
                Example:<\/strong> To revert the last 2 commits: git revert HEAD~2<\/code><\/p>\n\n\n\n
                  \n
                1. This will create a new commit with a message indicating it’s a revert. You can edit this message if needed.<\/li>\n\n\n\n
                2. Once you’re happy with the revert commit, stage and commit it using:<\/li>\n<\/ol>\n\n\n\n
                  git add .\ngit commit -m \"Revert of the last n commits (your explanation)\"<\/code><\/pre>\n\n\n\n
                  Option 2: Using Git Reset –hard (Advanced Users, Caution Advised)<\/strong><\/h3>\n\n\n\n
                  This approach is more aggressive and rewrites Git history. It’s recommended for experienced users and only if you haven’t pushed your commits to a shared repository. <\/p>\n\n\n\n
                  Using this on a pushed branch can cause issues for collaborators.<\/strong><\/p>git-documentation<\/cite><\/blockquote><\/figure>\n\n\n\n
                  Here’s how to do it (use with caution):<\/p>\n\n\n\n
                    \n
                  1. Navigate to your Git repository using your terminal.<\/li>\n\n\n\n
                  2. Run the command git log<\/code> to identify the commit hash of the commit you want to go back to (the good state before the last nth commits).<\/li>\n\n\n\n
                  3. Use the command git reset --hard <commit_hash><\/code>, replacing <commit_hash><\/code> with the actual hash you identified in step 2.<\/li>\n<\/ol>\n\n\n\n
                    Warning:<\/strong> This detached your HEAD from the current branch, meaning you’re no longer pointing to the latest commit history.<\/p>\n\n\n\n
                      \n
                    1. To fix this and create a new branch pointing to the commit you reset to, run:<\/li>\n<\/ol>\n\n\n\n
                      git checkout -b new_branch_name <commit_hash>\n<\/code><\/pre>\n\n\n\n
                      Remember:<\/strong> Always double-check before using git reset --hard<\/code> and ensure you understand the implications of rewriting history.<\/p>\n\n\n\n
                      \"\"<\/figure>\n\n\n\n
                      Additional Notes:<\/strong><\/h3>\n\n\n\n
                        \n
                      • These commands only affect your local repository. If you’ve already pushed the commits you want to revert, you’ll need to push the new revert commit(s) as well.<\/li>\n\n\n\n
                      • Consider the impact on your team if you’re working on a shared branch. Communicate any changes to the commit history clearly.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
                        Every project has a story, and in the world of software development, that story is often told through commit logs. For those unfamiliar, Git is a version control system used for tracking changes in code. Commit logs are the detailed record of those changes, providing a crucial window into a project’s history. In this blog, […]<\/p>\n","protected":false},"author":2,"featured_media":2727,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[34],"tags":[],"class_list":["post-2725","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technical"],"_links":{"self":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2725","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/comments?post=2725"}],"version-history":[{"count":2,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2725\/revisions"}],"predecessor-version":[{"id":2751,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2725\/revisions\/2751"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media\/2727"}],"wp:attachment":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media?parent=2725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/categories?post=2725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/tags?post=2725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}