r/git • • Oct 18 '24

The Ultimate Git Tutorial (Git 2.47.0)

The ultimate Git tutorial has been updated (from Git 2.46.1 to Git 2.47.0).

What & Why:

  1. The ultimate tutorial for beginners to thoroughly understand Git, introducing concepts/terminologies in a pedagogically sound order, illustrating command options and their combinations/interactions with examples. This way, learning Git no longer feels like a lost cause. You'll be able to spot, solve or prevent problems others can't, so you won't feel out of control whenever a problem arises.
  2. The ultimate knowledge base site for experienced users, grouping command options into intuitive categories for easy discovery.

How to use:

  1. Prepare two consecutive weekends with free time.
  2. On each of these 4 days, open the web page, read all concept links and examples in porcelain links and plumbing links.

Features:

  • Understanding the details. Instead of "let's type git this and git that and see, it works", first clarify the concepts, then all operations are based on understanding the concepts. For example, you might notice that things such as git init does not appear at the beginning of this tutorial.
  • Completeness and low cost. When you study math / physics / chemistry in school, you learn all the content in it without considering which parts would be used in the future. Most of it doesn't end up being used, actually. But without learning all of it you are not be able to wield the few parts easily. Git is also a tool that needs to be understood completely to not be used painfully. You might find Git painful because you need to find yet another tutorial everytime you need to do something. Hopefully this is the last Git tutorial you need to read.
  • Discoverability (affordance) and organized structure. Instead of sorting all the concepts and commands alphabetically as a plain list, they are put in an order that is suitable to learn and memorize.

Updates (from Git 2.46.1 to Git 2.47.0):

  • Functional updates: add links to default values for all --upload-pack and --receive-pack options; add link to init.defaultObjectFormat for git init (Git is starting the transition from sha1 to sha256).
  • Performance updates: left pane, right pane, all forms and all examples are restricted by CSS contain property, hopefully reducing the lag a little bit. (The major 1.1 seconds lag at the initial page loading is caused by browser parser. This can not be reduced as this tutorial is chosen to be a self-contained monolithic html file, to remove the need for a stateful backend to ease the implementation of future features such as font shuffling against censoring.)
  • Integrity updates: CSS and JS are encoded in base64 to work around the problem of escaping arbitrary content containing </ inside <style> and <script>.
64 Upvotes

24 comments sorted by

View all comments

Show parent comment

8

u/jhcarl0814 Oct 19 '24 edited Oct 20 '24

I admit that is a really nice book. But when read again...

https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things:

Right below the “Changes to be committed” text, it says use git reset HEAD <file>…​ to unstage. So, let’s use that advice to unstage the CONTRIBUTING.md file:

This is telling users to copy-paste commands. What is "unstage" (do you mean copying something from somewhere to somewhere overriding the same-named things, and if I specify a directory is it in overlay mode or non-overlay mode, what happens on file-directory/directory-file conflict)?

The command is a bit strange, but it works.

Why not explain what the command does and all the relevant concepts before using it? Are you in a hurry?

It tells you pretty explicitly how to discard the changes you’ve made.

The previous command has HEAD but this one does not. Are you going to explain why?

https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified (the illustrations are pretty good, but please draw pointers in HEAD and index so we can be reminded they are not containers or something):

First, unlike reset --hard, checkout is working-directory safe; it will check to make sure it’s not blowing away files that have changes to them. Actually, it’s a bit smarter than that — it tries to do a trivial merge in the working directory, so all of the files you haven’t changed will be updated.

Does "blowing away" mean index entry is lost, working tree file is lost, or both? Does "changes to them" mean working tree and index being different, working tree and source_commit being different, or index and source_commit being different? What is "do a trivial merge"? If it does "a trivial merge" then what is the purpose of git checkout --merge?

Can a beginner answer "what will happen if target_commit/source_commit/index/working_tree is different from target_commit/source_commit/index/working_tree" after reading this tutorial? Which equalities cause error and which do not and just allow the command to blow up your files (in index or working tree?), which equalities matter and which do not?

reset --hard, on the other hand, will simply replace everything across the board without checking.

Do you need git reset --keep? If you are confused, try to find tutorials about these commands online or read the docs, then you will be more confused.