Want to share your content on R-bloggers? click here if you have a blog, or here if you don’t.
As mentioned about a million times on this blog, last year I read Git in practice by Mike McQuaid and it changed my life – not only giving me bragging rights about the reading itself. 
I decided to give Pro Git by Scott Chacon a go too. It is listed in the resources section of the excellent “Happy Git with R” by Jenny Bryan, Jim Hester and others. For unclear reasons I bought the first edition instead of the second one.
Git as an improved filesystem
In the Chapter 1 (Getting Started), I underlined:
“[a] mini filesystem with some incredibly powerful tools built on top of it”.
Awesome diagrams
One of my favorite parts of the book were the diagrams such as the one illustrating “Git stores data as snapshots of the project over time”.
A reminder of why we use Git
“after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.”
The last chapter in the book, “Git internals”, include a “Data recovery” section about git reflog and git fsck.
One can negate patterns in .gitignore
I did not know about this pattern format. In hindsight it is not particularly surprising.
git log options
The format option lets one tell Git how to, well, format the log. I mostly interact with the Git log through a GUI or the gert R package, but that’s good to know.
The book also describes how to filter commits in the log (by date, author, committer). I also never do that with Git itself, but who knows when it might become useful.
A better understanding of branches
I remember reading “branches are cheap” years ago and accepting this as fact without questioning the reason behind the statement. Now thanks to reading the “Git Branching” chapter, but also Julia Evans’ blog post “git branches: intuition & reality”, I know they are cheap because they are just a pointer to a commit.
Likewise, the phrase “fast forward” makes more sense after reading “Git moves the pointer forward”.
The “Git Branching” chapter is also a place where diagrams really shine.
Is rebase better than merge
“(…) rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history.”
“Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.”
Reading this reminds me of the (newish?) option for merging pull requests on GitHub, “Rebase and merge your commits” – as opposed to merge or squash&merge.
Don’t rebase commits and force push to a shared branch
The opportunity to plug another blog post by Julia Evans, “git rebase: what can go wrong?”.
The chance of getting the same SHA-1 twice in your repository
“A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.”
Ancestry references
The name of references with “^” or “~” (or both!) is “ancestry references”. Both HEAD~3 and HEAD^^^ are “the first parent of the first parent of the first parent”.
Double dot and triple dot
I do not intend to try and learn this but…
The double-dot syntax “asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another”.
The triple-dot syntax “specifies all the commits that are reachable by either of the two references but not by both of them”.
New-to-me aspects of git rebase -i
git rebase -i lists commits in the reverse order compared to git log. I am not sure why I did not make a note of this before.
I had not really realized one could edit single commits in git rebase -i. When writing “edit”, rebasing will stop at the commit one wants to edit. That strategy is actually featured in the GitHub blog post “Write Better Commits, Build Better Projects”.
Plumbing vs porcelaine
I had seen these terms before but never taken the time to look them up. Plumbing commands are the low-level commands, porcelain commands are the more user-friendly commands. At this stage, I do not think I need to be super familiar with plumbing commands, although I did click around in a .git folder out of curiosity.
Removing objects
There is a section in the “Git internals” chapter called “Removing objects”. I might come back to it if I ever need to do that… Or I’d use git obliterate from the git-extras utilities!
Conclusion
Pro Git was a good read, although I do wish I had bought the second edition. I probably missed good stuff because of this! My next (and last?) Git book purchase will be Julia Evans’ new Git zine when it’s finished. I can’t wait!
R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you’re looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don’t.
Continue reading: Reading notes on Pro Git by Scott Chacon
Understanding Git: From Reading Notes on ‘Pro Git’ by Scott Chacon
Git, the all-important version control system, is often noted for its learning curve. A recent blog post delves into insights gained from reading ‘Pro Git’ by Scott Chacon, expanding our understanding of Git’s capabilities and tips for using it efficiently.
Git as an Improved Filesystem
“[a] mini filesystem with some incredibly powerful tools built on top of it.”
This sentiment resonates through the book, emphasizing the unique features of Git, most notably the way it stores data as snapshots over time. This nuanced way of data handling ensures it’s difficult to lose a commit and furthermore strengthens the structure with regular pushes to another repository.
The Importance of Good Comprehension
- Branches: The blog post highlights the importance of understanding Git-specific terms like ‘branches,’ referring to pointers to a commit.
- Fast Forward: This term, used when Git moves the pointer forward, is a sign that the user has a good grasp of basic Git operations.
- Rebase vs Merge: ‘Rebase’ is preferable for a cleaner history, resulting in a linear look when examining the log of a rebased branch. On the other hand, ‘merge’ takes the endpoints and merges them together.
The blog post urged caution towards rebasing commits and force pushing to a shared branch, stating that there could be potential risks involved in such tasks.
Familiarizing Oneself with Ancestry References
Ancestry references entail advanced usage of Git involving symbols like “^” or “~”. For instance, both HEAD~3 and HEAD^^^ point to “the first parent of the first parent of the first parent”.
Understanding Commit Syntax
Differentiating between double-dot and triple-dot syntax is important in Git. The former instructs Git to resolve a range of commits reachable from one commit but not from another, while the latter involves all commits reachable by either of two references, but not by both.
Editing with git rebase-i
‘git rebase -i’ enables editing of individual commits – this strategy is extensively covered in the GitHub blog post “Write Better Commits, Build Better Projects”. The command also lists commits in reverse order compared to git log.
Plumbing vs Porcelain Commands
These are Git’s low-level and user-friendly commands, respectively. Mastering both is crucial for a comprehensive understanding of Git.
Conclusion
Reading ‘Pro Git’ offers invaluable insights into Git management, highlighting aspects like rebasing, branching, commit editing and understanding various commands. Such knowledge can deeply improve one’s ability to navigate through version control systems when programming. As part of constant improvement and knowledge expansion, it’s advisable to keep exploring new resources and guides available in this area.