Git in six hundred words (opens in new tab)

I teach courses on Git, and I couldn't agree more. Many of my students have been told that Git is simple, and they just need to know 10 commands. Or they can think about it like SVN. Or that they should push, pull, and that's about it.

Which has the effect of (a) making them fear Git, (b) making them feel like they'll never figure it out, (c) and convincing them that they're always on the verge of losing data. I've literally had students at the start of my course refer to Git as "that system that makes me lose files."

Once I teach people about Git's objects and data structures, things suddenly become much more obvious to these people. Git becomes less of a mystery.

I'm not saying that Git is easy for people to understand or use, because it isn't. It has a steep learning curve -- one which I think is worth the effort. But I think that it does a disservice to Git newbies to try to summarize all of Git's functionality in a short essay, and then proclaim, "See? There's not that much to learn here!"

> "You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards."

Imagine you clone a repo. So your version is identical. You now add a couple more commits to master. Now, to make them identical again, all you have to do is upload the new commits, and then get his master branch to update to point to the latest one. Makes sense, right? That's a fast-forward.

Instead, what you do is merge your latest commit with the older commit two back, which creates a third commit with identical content to the previous one. That's silly, right? That's why fast-forward instead of merge.

> "You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."

Rebase is when you take the content from a chain of commits, and make a completely new chain with that same content, just because it makes it look neater. You then change the branch from pointing at the head of the old chain to pointing at the head of the new. That's all it does. The old chain is still there until it's garbage collected a few weeks later (or you tag it to stop it disappearing).

> "You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."

I'm not sure what the fear is here, so I'm not sure what to tell you. Create a test repository with a few commits and change the hashes below for real ones:

    git checkout master # on master, whew
    git checkout e34a53 # oh no, detached head
    git checkout master # it's ok, back on master, whew
    git checkout 343a34 # oh no, detached head
    git checkout master # it's ok, back on master, whew
    git checkout fe34ee # oh no, detached head
    git checkout master # it's ok, back on master, whew
    git checkout a567ed # oh no, detached head
    git checkout master # it's ok, back on master, whew

Repeat until you're not panicking? :-)

+1. I want an intro to git that covers all the weird confusing shit newbies meet. I think I've read enough of the travel brochure version.

I spent a few weeks working with Git, taking full advantage of the cool history-rewriting stuff it can do that Mercurial still doesn't quite match. It worked, but it required the most arcane syntax I've ever seen.

Then I gave up and went back to Mercurial. It does a much better job with subrepos, and I can actually use it without always consulting a hand-scrawled reference sheet for common tasks.

You could seriously make an Oregon Trail type game that demonstrates all of the ways you can 'die' using git. It would actually be very educational.

Took me many steps to finally internalize enough of git internals (still a tiny bit) to start losing fear and discomfort. I find it very similar to learning the semantic of dynamic languages (python: http://www.pythontutor.com/, js) where you need to see the data model evolving next to the main `pointers`. It looks obscure but it's not large. Small things aren't easy but not necessarily complex #hickeyism.

https://codewords.recurse.com/issues/two/git-from-the-inside...

ps: maybe it just fits my brain's inner working, I like to see every details before grasping the abstraction.

Is this an intro or a summary? Because I don't think there's any easy path to learning git, but there's a path, and it goes through understanding the internals, not memorizing UI idiosyncrasies.

The thing about git is that the internals are sensible and cohesive, whereas the UI is a train wreck. This is the opposite of svn where the UI is simple, but the internals are a train wreck.

The simpler subset is useful for personal or internal projects, however, so it's useful to have it spelled out.

(And BTW my own simple subset is still simpler - no branches, for instance, as it helps people delay merges which IMO they tend to overdo even without branches; also helps people pull and think they "got the changes" without actually running the new stuff. Also, my own understanding of rebases, detached heads etc. etc. is minimal at best and I seriously dislike having to learn that sort of thing and having to keep it in mind.)

When I read your comment, I'm imagining Adventure...

Git does not check with the remote unless you tell it to. So "origin/master" points to what master on origin pointed to the last time git contacted the origin remote.

To have git contact the remote again, you can do "git fetch origin" (or just "git fetch"). Then git will tell you your copy is out of date compared to origin/master, if there's been commits on origin since.

If you commit things, then your copy will be ahead of origin/master, so origin/master is what is out of date and you need to git push:

    ~/dotfiles % git status            ✓✗ master:c024cb4 - dotfiles 
    On branch master
    Your branch is ahead of 'origin/master' by 1 commit.
      (use "git push" to publish your local commits)

`git fetch` and `git push` talk to the remote(s) (if any) that you have configured. Most (all?) other commands are local operations. `git status` compares your working copy to your local `.git/` database.

If you want `git status` to compare `.git/` with the state of a remote, you must first `git fetch` the state of a remote into your local `.git/`. And you may have multiple remotes, as well...

I've used git for years after having spent years with SVN. no one taught me SVN and never really read much documetation. It was so simple and straightforward. Git introduces a lot of new power and features, but nowhere near the cost increase of the learning to use it. FWIW, I always hoped Mercurial would win. It's at near feature parity with git, but is far easier to use.

Because git lied to you. When it says "you are up-to-date with origin/master" it did not actually check that it is up to date with the code on the origin. This is one reason why Git is inhumane. It's reasonable that it didn't check with the remote repo, but its misleading use of the word "origin" does not help new users.

As others have said, you'd need to do 'git fetch' first before 'git status' would report a difference.

The reason git doesn't do this automatically is because, in its simple model, it doesn't waste time trying to connect to the remote 'origin' or any other remotes you may have configured every time you do 'git status', which is most often used to check what you've modified locally.

I can understand why this would be jarring coming from SVN, where you always want to be checking against the remote/server. Since git has a copy of all history locally, remotes are de-emphasized compared to centralized VCSs.

Git maintains a local copy of remote branches (to some extent, I'm not sure of the mechanics) and I believe you can cause it to update that with 'git remote update', 'git fetch' and a couple of other tools.

Same reason your OS won't upgrade your packages unless you update the package list from the repository. I can empathize with the confusion coming from SVN.

I think it's safest to assume that any `git` command that doesn't by necessity make a request to the remote repo (like `git {fetch,pull,push}` and others) does not make a request to the remote repo.

You might very well be right. It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.

I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.

The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.

Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.

A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.

Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details?

Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings.

Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details.

Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.

I think calling the basics of the data model its 'precise implementation' is excessive. It's like complaining about having to learn the precise details of your display server because someone tries to explain to you how windows in a typical window manager work. The underlying model of git is not terribly complicated, is distinct from (but maps reasonably closely to) its implementation, and it makes understanding all the operations on a repo and working directory a lot easier, as well as making it easier to google for help if you get stuck or want to do something new.

Git hides a lot of complexity, instead exposing an unintuitive set of commands to control your data. Multi-user distributed version control is a very complicated problem to which there will never be a simple solution. If you are willing to sacrifice some features, there are probably simpler solutions that would be more fitting with your work process.

I agree. Everyone should do their own cost benefit analysis. Git has a set of features and costs that make it highly suitable for some combinations of organization and project and not so suited for other combinations. There is no silver bullet.

SourceTree (by BitBucket) has a decent GUI Git client.

The official github client is trash. The last time I used it was a year ago, so it might have improved since then.

I like SmartGit enough that I paid $80 for it (despite the fact that it seems weird to pay money for dev tools these days). You can download it and use it free for non-commercial use, though.

I'm reasonably comfortable with the git command-line tools, but for keeping the simple things simple I really do like an integrated all-in-one visual diff/VCS client program and SmartGit is the best one I've used for git.

SourceTree (mentioned by fsk) is kind of a trainwreck on Windows, in my experience (moving to SmartGit was the result of me getting fed up with SourceTree and looking for something not as frustrating). From what I understand the Mac version works better, though I haven't used it. While the UI is quite nice to start, the Windows version of SourceTree tends to soft-hang a lot (goes into non-responsive states it eventually recovers from, but will hang for like 30+ seconds at times) and it has a lot of weird issues with multi-monitor setups (it'll sometimes randomly jump to the other monitor during pane resizing and such).

git comes with `gitk` and `git instaweb` out of the box; both of these are point-and-click graphical tools that show you branches, merges, and specific commit hashes.

I think what you're looking for here

> you click a commit and the repo shows up on the desktop as a mounted drive. We could use ordinary tools to edit the image and when it's unmounted it becomes a new commit

is basically `git checkout -b newbranch 80238ec` followed by `git commit -a`.

I like Source Tree for Windows and Gitg/Gitx on Linux/Mac. Also recommend downloading P4 Merge and setting that up as your default merge tool.

Nope, git can be initialized in directories with files in them.

  ➜  ~  mkdir test1
  ➜  ~  cd test1 
  ➜  test1  echo "hello" > hello.ttx
  ➜  test1  ls
  hello.ttx
  ➜  test1  git init
  Initialized empty Git repository in   /home/david/test1/.git/
  ➜  test1 git:(master) ✗ git status
  On branch master

  Initial commit

  Untracked files:
    (use "git add <file>..." to include in what will be committed)

  hello.ttx

  nothing added to commit but untracked files present (use "git add" to track)
  ➜  test1 git:(master) ✗

In fact, the Git Parable specifically addresses this articles approach to teaching git in the introduction:

"Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying."

Makes the 600 words achievement seem less impressive, if you put it in the context of existing git education.

Same thought here. The Git Parable is interesting. OP lost me on line 3. I know git was just curious.

As a new user of Git, I cannot support this comment enough. The Pro Git book is a fantastic resource that cleanly and concisely outlines the command AND the conceptual framework upon which Git operates.

I strongly recommend that all new users read at least those first 3 chapters, but also the very useful chapters on using GitHub - a website that I have personally found extremely unintuitive to use.

The essay seems to encourage the realisation that nothing really special is happening under the hood, which in my view is important for people who are learning to use git.

For six hundred words, I think it does a good job.

And then skip ahead and read chapter 10: git internals. This was really helpful for me to understand the fundamental concepts of git and why it is designed the way it is.

Hmm, the reflog usually (always?) provides all the info you need to undo the last action. I wouldn't be surprised if it were possible to build a "git undo" command on top of that. The fact that no one has yet done so is a great illustration of your point, though.

I think your attitude is completely reasonable, and I'm with you on your skepticism. However I am pleasantly surprised that, for once, a software fad lines up with what is actually technically superior. Linus knows how to design software correctly.

Probably due to HTTPS Everywhere. Try disabling the rule for Fonts.net.

Agreed, it's like the perl of vcs. Please go away.

Hear, hear.