11/18/2023 0 Comments Github see commit historyI’m a product of GitHub culture, so I tend to throw a lot of commits into my projects. In both cases, more historical context on a change can be easily found by going back to the mailing list discussion or the pull request conversation. From GitHub’s perspective, individual commits become less valuable because the atomic unit is the pull request. From Git’s perspective - likely because of the ease of use inside a mailing list approach - a single atomic commit makes most sense. These are two extremes of viewing what the core unit of change is for the respective project. It effectively serves the same purpose as one of Peff’s individual commits. This would not get accepted in git-core.īut click up from the commit’s page and take a look at the pull request and the general format becomes immediately familiar: it’s an extremely well-written and accessible discussion of the changes in that pull, complete with the analysis of the performance impact it will have. It’s a fairly stereotypical commit for GitHubbers: hell, even the commit message itself is emoji. It’s an egregious example for the sake of illustration, but take a look at this particular commit on the Atom repository. Nathan Sobo ( is one of my favorite pull request authors. Every single change enters production via a pull request, and as such, the pull request is king… not necessarily the commit. On the flipside, GitHub is the best example of how to work within, and if you ask them, they’d probably defend their process with the exact same rationale: it allows them to move with speed, quality, and safety. They should know they’re the best example of working efficiently within Git. Git’s maintainers would say this commit process is designed to ensure speed, quality, and safety. This is a byproduct of their process: contributors are to use git format-patch and git send-email to send their patches to the mailing list so that changes can be efficiently reviewed, discussed, and merged to master. Each commit is designed to be a comprehensive, standalone measurement of the change introduced into the repository. This works for git-core because their unit of change is at the commit level. More often than not, the diff may only be a couple of lines but he’ll likely include a detailed, multi-page writeup with code examples and performance benchmarks in the commit message. He’s the number two committer to Git itself, and his commits are truly lovely to read. My favorite commit author of all time is Jeff King ( I like his commits so much that even if I were the Sepp Blatter of the Commit Olympic Committee, I wouldn’t need to be bribed to nominate him as a finalist. Why do developers take different approaches to repository histories? A tale of two changes Over the last five years, I’ve gotten a lot of questions along the lines of “should I rebase my branches or deal with a merge commit or maybe even squash all of my commits down into a single commit before merging?” Like most pedantic programmer debates, my answer is usually “I don’t care, I’m going to grab another slice of pizza, you do you”, but I’ve been thinking about this a lot recently and I think there’s a more interesting question to consider instead: I have no shame - okay, maybe a little shame - dropping these commits into my repositories: Information on a repository's commits page.įor more information on how Git considers commit history, see the "History Simplification" section of the git log help article.Look, I don’t give two shits about my Git commits. If you want to see the entire history, GitHub provides a view with more This truncated view might not always contain the information you'reĪfter. This makes reviewing branches more efficient, since you only see the commits that affect the file. For example, if a side branch made a change and then reverted it, that commit would not show up in the branch history. It makes the history simpler by removing commits that didn't contribute to the final result. Any commits on theīranch that touched the file will not be shown.įor a file's commit history, GitHub explicitly follows this simple strategy. When merged, did not impact the final contents of the file. Instead of looking at every commit toĭecide whether it touched the file, Git will omit a whole branch if that branch, When Git shows the history of a single file, it simplifies history by omittingĬommits that did not change the file. Git has several different ways of showing the history of a repository. The history for a single file may omit commits found on the repository's commit history. These two commit views may show different information at times.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |