DEV Community 👩‍💻👨‍💻

Discussion on: Git Gud at git

Collapse
 
johncip profile image
jmc • Edited on

This is a really cool idea, and a Git playground would be useful for the after-school CS program I'm part of. I'm also kind of in awe that you're using C++ for this.

But I have to say that the way branches are modeled here doesn't really line up with how I've come to see them. While it can be sometimes useful to picture them as "lanes," branching in Git only made sense to me when I started picturing them as just pointers to a commit.

(If commits are lanes, what does it look like when a commit is part of multiple branches?)

It's deceptively simple, and for a long time I didn't get that I didn't get it. I had come to Git from Subversion, where branches actually are lanes. Eventually I read Think Like a Git and Git's model finally clicked. Suddenly I was able to branch, merge, cherry-pick and rebase with zero surprises.

It boils down to this: Git has commits, which are full snapshots, and pointers to commits, which give you a way to name them. During a new commit, tags (one type of pointer) stay on the previous commit, and branches (the other kind of pointer) may move to the new one. Only one actually does -- and git calls that the "checked out" branch.

Collapse
 
nichartley profile image
Nic Hartley

Yup, branches are pointers to commits, but there are two issues with drawing them like that:

  1. It makes it hard to tell which commits are part of which branches (you need to manually follow them back from the head, and even then it's hard to tell where one branch 'splits' from another)
  2. It makes it much harder to render.

Honestly, the latter was the biggest thing; we tried to get labels pointing at the branch head, but because of all the edge cases it was surprisingly hard to get it happening without making something look weird.