> Files in Git can be in one of these three states: Modified, Staged, Committed<p>> Staged: The current version of the modified file is staged to be included in the next commit.<p>A bit of a nitpick, but if I change a file, "git add" it, and then change it again, both of these statements are false.
This is pretty cool. Worth noting that Git does not actually only store full copies of files every time you make a change, this article I found does a really good job at explaining Git's packing: <a href="https://gist.github.com/matthewmccullough/2695758" rel="nofollow">https://gist.github.com/matthewmccullough/2695758</a>
I really recommend doing the "Build your own git" challenge on CodeCrafters in order to gain a deep understanding of git internals.<p><a href="https://app.codecrafters.io/courses/git/overview">https://app.codecrafters.io/courses/git/overview</a>
Reminds me of this talk [0] led by CB Bailey, a top answerer on StackOverflow for the tag 'git' [1].<p>They create commits from scratch from the command line--manually creating each /.git/ file with shell commands and a text editor. Really fun talk. Would highly recommend it for people who were planning on learning about git internals at some point.<p>[0] "How does Git actually work? - CB Bailey & Andy Balaam [ACCU 2019]"<p><a href="https://www.youtube.com/watch?v=N0m42TKk_dc" rel="nofollow">https://www.youtube.com/watch?v=N0m42TKk_dc</a><p>[1] <a href="https://stackoverflow.com/tags/git/topusers" rel="nofollow">https://stackoverflow.com/tags/git/topusers</a>
Nice article. What is interesting to me is the reactions to articles like this. Not the fact that the git internals are not widely known, I mean that is true for nearly any more complicated topic. In this case I mean the fact that this is actually well documented.<p>Don’t get me wrong. I think articles like these help a lot to demystify git and I believe it makes the tool easier to use and reason with when one knows what it does. But why is nobody finding or reading the later chapters in the docs?<p><a href="https://git-scm.com/book/en/v2/Git-Internals-Git-Objects" rel="nofollow">https://git-scm.com/book/en/v2/Git-Internals-Git-Objects</a>
It was learning about the topics in this post that enabled me to create this repo:<p><a href="https://github.com/grantm/no-more-f-s-repo">https://github.com/grantm/no-more-f-s-repo</a><p>Parental Advisory: Contains strong language.
> git<p>On the topic, I'm just going to plug the tool git-branchless. Completely transformative for my use of git at work. Stacked commits that actually work!
Love this!<p>I think there may be an error around the "git write-tree" step. That or I did something wrong.<p>Here's my user test: <a href="https://www.youtube.com/watch?v=bul4CPRkv6c" rel="nofollow">https://www.youtube.com/watch?v=bul4CPRkv6c</a>
Fantastic article! It seems to me that the flexibility of low-level git objects would lend itself to be embedded in other software systems for version control purposes (e.g. tracking changes in a CMS)
I used to struggle with formatting my Git commit messages and often forgot the necessary Git commands.<p>Now, I've found a utility (made by my brother who shared it with me a few days ago and I told him to opensource it since I liked it soo much) that handles all the formatting and rewriting for me. I just write my commits, and it takes care of the rest.<p>Here's a video demonstrating this magic (though it's for rsync): [asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1](<a href="https://asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1" rel="nofollow">https://asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1</a>).<p>Check out the utility here: [github.com/zerocorebeta/Option-K](<a href="https://github.com/zerocorebeta/Option-K">https://github.com/zerocorebeta/Option-K</a>).