Git 201 - A Deeper Look at Git @ KCDC 2016

Editor's Notes

• #8: A quick overview of the basic structure for git – blobs are contained by trees, which contain each other, and which are contained by a commit. Blobs and trees are subatomic particles, composing the literally atomic commits. Like reality, almost all of the time, just knowing how atoms work is enough. Sometimes there’s effects that make no sense which require subatomic knowledge, but until those points it’s not necessary.
• #10: Commits and commit topologies are the most important pieces of Git. The “atomic” commits form into “molecules” of topologies (typically called branches). The edges of the DAG are then the deltas.
• #12: Here we have two commits, side by side, and we’re going to try to get a diff between the two. Commit 1 has three files – one in the root of the repo (File 1) and two in a directory (helpfully called Directory), which are File 3 and File 4. Commit 2 has three files – File 2 in the root and File 4 and File 5 in Directory. File 1 and 2 have the same blob: identically the same. Git will (sometimes) reinterpret this as a rename. File 3 is in Commit 1 but not in Commit 2, so it’s a delete. File 4 has different blobs in the two commits: it’s a change and a diff will be generated. File 5 is in Commit 2 but not in Commit 1: it’s an add.
• #13: Time to go to the command line. Explain what you’re doing – committing data to be served via a service. In this case, MTG decks. Magic has different ways to play it, called “formats”. We’re tracking formats in different branches, because Reasons. New tournament – block format! So “git checkout –b mtg_2014_block” There are uncommitted changes, so “git add .” then “git commit –m “New decks.”” Talk about what a branch is – a pointer to a specific commit. A major tournament is over so we’re making a tag for it. “git tag –a SCG_Open_07_2014 –m “SCG Open Finalized Decks.”” Lightweight tags are just like (mostly) immutable branches. Annotated tags identify the tagger, the message, the date, and have a checksum. Talk about how a branch is actually a pointer to the entire DAG (directed acyclical graph) at that point. Two important things to realize: A branch is not constrained by anything – any branch can point to any commit (even HEAD or master!). The hash for each commit includes its parent – that means ANY history change will cascade through the DAG! We’ll see an example when we rebase.
• #16: Different ways to get upstream in your repository… note that these work on ANY name for a commit! And they can be chained, like in the last example, since the valid names for a commit (sha1, tag, branch, etc) plus the ^ and ~ operators are a valid DSL.
• #17: Anything valid in block format is valid in standard format, and so we need to merge those commits in: “git checkout mtg_2014_standard”, “git merge --no-ff mtg_2014_block” The “no-ff” option on a merge performs a guaranteed merge commit – by default git will try to avoid making a merge commit if it can, through doing what is basically a rebase. –no-ff forces it to make a merge commit instead.
• #18: Different ways to get upstream in your repository… note that these work on ANY name for a commit! And they can be chained, like in the last example, since the valid names for a commit (sha1, tag, branch, etc) plus the ^ and ~ operators are a valid DSL.
• #26: Example time yet again. We have a repo. We’ve been doing on-the-ground reporting for a local tournament and we’ve made a bunch of commits as we went so we didn’t lose anything. Could push this, but it looks terrible. What to do? Rebase! Interactive rebase – git pops open whatever editor we have configured. One row = one commit, in reverse order. It does this in an editor so you can copy and paste, and so you can change the command from “pick” to something else. Show the list in gvim next to the list in gitviz. There is one reorder, then two fixups, then one commit to reword and one commit to amend. What if there had been commits on block we had to worry about? Rebase to the rescue! Normal rebase. Call out how it applies each commit in turn. We could have done both at once (and we should have!) but I broke it apart for clarity.
• #29: Example time again. git branch –D mtg_2014_legacy ./gcscript.sh See!
• #31: A discussion of git workflows – I’m going to exclude the issues caused by external tools here and focus only on git. It – essentially – boils down to four types of git workflows. We’ll work through the same example with each of the four types – just as a visual, to avoid a lot of unnecessary typing.
• #32: “Pure “ merge – using only the merge command (with --no-ff option). First merge develop into the feature to get the changes from Feature Branch B, accounting for conflicts if necessary. Then merge the feature branch into develop.
• #33: “Pure” rebase – First rebase the feature branch onto current develop to pick up branch B’s changes. Then alter develop’s head ref to point to F, either via manually editing it (bad!) or a fast-forward merge.
• #34: Rebase then merge – First rebase the feature branch onto current develop to pick up branch B’s changes. Then merge feature back into develop, using a --no-ff merge, to retain the merge commit.
• #35: Rebase then squash – First rebase the feature branch onto current develop to pick up branch B’s changes. Then interactive rebase to squash to one or a few large commits. Then fast-forward merge feature into develop.
• #36: ??????
• #39: SO MUCH STUFF TO READ, you guys. Seriously.