{"id":324,"date":"2021-05-01T18:05:46","date_gmt":"2021-05-02T01:05:46","guid":{"rendered":"https:\/\/bornski.com\/maria\/blog\/?p=324"},"modified":"2022-11-21T13:54:04","modified_gmt":"2022-11-21T21:54:04","slug":"demystifying-git-git-commits","status":"publish","type":"post","link":"https:\/\/bornski.com\/maria\/blog\/2021\/05\/01\/demystifying-git-git-commits\/","title":{"rendered":"Demystifying Git – Git Commits"},"content":{"rendered":"\n

What is a git commit?<\/h2>\n\n\n\n

A git commit is the object that contains all the relevant information about your repository and files at the time of the commit. Commits are the git objects you’ll interact with most frequently, and everything in our series will build on this knowledge.<\/p>\n\n\n\n

Commit ID<\/h3>\n\n\n\n

Git uses SHA-1<\/a> to calculate a hash of the commit object and the resulting hash becomes the commit ID. If any information about your commit changes, the SHA-1 hash will change (unless you’re intentionally running a collision attack<\/a>, which is well outside the scope of this series, so we’ll ignore that possibility), thus resulting in a new commit object and a different commit ID.<\/p>\n\n\n\n

\"\"<\/a>
Example git history with commit IDs
Command: “git log --pretty=short<\/code>“<\/figcaption><\/figure>\n\n\n\n

Snapshot of your files<\/h3>\n\n\n\n

For each commit, git stores a snapshot of all the files in your repository. This means that regardless of which files you changed in the commit, git can easily figure out the exact state of your repository at the time.<\/p>\n\n\n\n

Git uses a “tree” object to contain information about other objects in your repository and uses SHA-1 to create a tree ID for each tree object. Any changes to the file contents, file names, or directory names in your repository will result in a different, thus resulting in a new tree ID for the new snapshot. The “Git Internals – Git Objects<\/a>” chapter of the “Pro Git” book has a great deep dive if you want to learn more about git objects.<\/p>\n\n\n\n

\"\"<\/a>
Git log in raw mode with tree IDs highlighted
Command: “git log --pretty=raw ec74f0026<\/code><\/em>“<\/figcaption><\/figure>\n\n\n\n

While git stores a snapshot of your entire tree, most commands to view git commits and git history display only the differences between commits. While this is often the information that someone wants to know, this method of display can mislead people into assuming git stores deltas or differences in the commit.<\/p>\n\n\n\n

\"\"<\/a>
Viewing a commit using ‘git show’ displays a diff, not the full file tree
Command: “git show ec74f00266dbf3a63288ca641f1f4325791567aa<\/code>“<\/figcaption><\/figure>\n\n\n\n

Who and When<\/h3>\n\n\n\n

Git stores information about who worked on a commit and when the commit was created. Git was originally designed<\/a> for Linux kernel development. In the Linux kernel community, developers who would like to make a change write their code and then send the change to the Linux kernel mailing list<\/a> for discussion and code review. Once the relevant maintainer is satisfied, they incorporate the change into the kernel<\/a>. This workflow means that more than one person is involved in every commit, so git keeps track of both Author and Committer information for each commit.<\/p>\n\n\n\n

Author<\/h4>\n\n\n\n

The Author<\/code> is the person who originally created the commit. The AuthorDate<\/code> is the timestamp of when the commit was originally created.<\/p>\n\n\n\n

Committer<\/h4>\n\n\n\n

The Committer<\/code> is the person who created this exact commit. The CommitDate<\/code> is the timestamp of when this exact commit was created.<\/p>\n\n\n\n

Viewing and updating Author and Committer<\/h4>\n\n\n\n

You can view the Author<\/code> and Committer <\/code>information by adding --pretty=fuller<\/code> to commands like git log<\/code> and git show<\/code>. When you first run git commit<\/code> and create a commit object, the Author<\/code> and Committer <\/code>information will be the same. <\/p>\n\n\n\n

\"\"<\/a>
This commit has the same author and committer information
Command: “git show --pretty=fuller ec74f00266dbf3a63288ca641f1f4325791567aa<\/code>“<\/em><\/figcaption><\/figure>\n\n\n\n

Any changes to the commit via commands like git cherry-pick<\/code>, git rebase<\/code>, or git commit --amend<\/code> will update the Committer<\/code> information but leave the Author<\/code> information alone.<\/p>\n\n\n\n

\"Screenshot<\/a>
This commit has different AuthorDate and CommitDate values. This commit was cherry-picked from our prior commit (ec74f0026<\/em>).
Command: “git show --pretty=fuller 734f7b3a208734237fe1cd9e89707a2c70a0969a<\/code>“<\/em><\/figcaption><\/figure>\n\n\n\n

By default, git log<\/code> will display the Author<\/code> and AuthorDate<\/code>, which can make history look a bit surprising. If you see a commit that says it was made earlier than the prior commit, it probably actually has a later CommitDate<\/code>!<\/p>\n\n\n\n

Parent commits<\/h3>\n\n\n\n

Git stores the commit ID(s) of any parent commits in each commit object. The very first commit in a repository will not have a parent commit. <\/p>\n\n\n\n

\"Screenshot<\/a>
Our empty initial commit has no parent commit
Command: “git show --pretty=raw 5504457e8df354fc66cee371b52cfa072153392a<\/code>“<\/figcaption><\/figure>\n\n\n\n

Merge commits will have multiple parent commits — One for each branched merged together. Most commits will have a single parent commit: the most recent commit on the current branch in your working directory at the time you created the commit.<\/p>\n\n\n\n

Commit message<\/h3>\n\n\n\n

The git commit message lets you explain your commit to your future self and other people looking at the repository. As with all other aspects of the commit object, any changes to the commit message will result in a new commit ID.<\/p>\n\n\n\n

How does this affect working with git?<\/h2>\n\n\n\n

Comparing Commits<\/h3>\n\n\n\n

In the strictest sense, git commits are only the same if they are the literal same object — eg, they have the same commit ID. Two commits may make exactly the same changes to your files but if they have different parent commits, commit messages, Author<\/code> information, or Committer<\/code> information, then they are not<\/strong> the same commit. <\/p>\n\n\n\n

As a concrete example, these commits are identical except for CommitterDate<\/code>. They therefore have different commit IDs, so they are different<\/strong> commits.<\/p>\n\n\n\n

\n
\n
\"\"<\/a>
Command: “git log -p -2 --pretty=fuller ec74f00266dbf3a63288ca641f1f4325791567aa<\/code>“<\/figcaption><\/figure>\n\n\n\n
\"\"<\/a>
Command: “git log -p -2 --pretty=fuller 734f7b3a208734237fe1cd9e89707a2c70a0969a<\/code>“<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Other Impacts<\/h3>\n\n\n\n

We’ll talk more about how commit objects affect git workflows in future installments!<\/p>\n\n\n\n

Try it for yourself!<\/h2>\n\n\n\n

All examples on this post were created using https:\/\/github.com\/mariabornski\/demystifying-git-examples<\/a> and git version 2.25.1<\/code> on Ubuntu 20.04.1 LTS (GNU\/Linux 4.19.128-microsoft-standard x86_64<\/code>).<\/p>\n\n\n\n

You’re welcome to go clone the repository yourself & try out the commands! Similar commands will work on any git repository, you’ll just need to substitute your own commit IDs.<\/p>\n","protected":false},"excerpt":{"rendered":"

What is a git commit? A git commit is the object that contains all the relevant information about your repository and files at the time of the commit. Commits are the git objects you’ll interact with most frequently, and everything in our series will build on this knowledge. Commit ID Git uses SHA-1 to calculate … <\/p>\n

Continue reading “Demystifying Git – Git Commits”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[39,28],"tags":[40,34],"_links":{"self":[{"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/posts\/324"}],"collection":[{"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/comments?post=324"}],"version-history":[{"count":5,"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/posts\/324\/revisions"}],"predecessor-version":[{"id":361,"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/posts\/324\/revisions\/361"}],"wp:attachment":[{"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/media?parent=324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/categories?post=324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bornski.com\/maria\/blog\/wp-json\/wp\/v2\/tags?post=324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}