Six3 Getting Git

Editor's Notes

• #2: helloI’m daniel cox, a software engineer on i2ps, and this is Getting Git.I asked to give a talk on git because I believe it to be brilliant but misunderstood software with a high-learning curve, and I think every developer would benefit from a deeper understanding of it
• #3: half my slides come from a presentation of Scott Chacon’s,which I’ll mention again at the endsince the talk ended up being shorter than I expected, please feel free to interrupt me with questions
• #4: here is the master plan
• #5: and here is the approximate breakdown.the talk is mostly meant for those of you who already use git but don’t love it yet,though I do have a few slides on what git is
• #6: git, first, is a version control system. it was designed to solve two major problemsversioning - you need to keep history of your content so you can e.g., go back… or branch off to try new things… remember what you've done… try to figure out what someone else has done...collaboration - you need to work together with other people on a project without emailing files back and forth or overwriting each other's changesother things git is: a very simple content tracker, a key/value object database with a vcs front-end, and a toolkit
• #7: it’s also a creation of linustorvalds, to serve the needs of the linux kernel
• #8: Git is a toolkit of about 152 commands…
• #9: most of which are not useful to humans, and exist mostly to be run by other commands and scripts.
• #10: These are referred to as “the plumbing commands”, and we’ll only get into a couple of these
• #12: However, there are about 40 commands which human users are expected to need frequently at the command line, to perform most of the useful features git provides for your daily work.
• #13: These are “the porcelain commands”.
• #14: We’ll cover about half of these, and touch briefly on more.
• #15: here’s something git isnot - it’s not subversiongit is much faster, you can work on an airplane, branching isn’t something you need to have a meeting about, git drops in one hidden directoryand much much more!Git uses a lot of the same vocabulary as Subversion, but a different dictionary. The words have quite different meanings.(checkout, commit, branch...etc. - they mean completely different things in git than they do in subversion)
• #16: Git hides out of your way until you need it, in a hidden directory in the root of your project folder: .githere we make an empty foobar directory, go into it, and run git init to make it a repository. now we’ll look inside the new .git directory
• #17: a fresh git repository is tiny. more than half of the clutter here is inoperative sample files
• #18: I’d also like you to see that as your repository grows, it gets larger but not much more complicated. When you add a file and commit, the resulting repo looks like this.As we’ll talk about soon when we talk about the git object database,
• #19: this (54) contains the directory information,
• #20: this (cc) contains the commit information,
• #21: and this (e6) is the empty file.But we’re getting far ahead of yourselves now…
• #22: We’ll sortof work our way up towards proficiency starting with the most basic commands, and ending with collaboration.
• #23: The very most basic way you would use a git repository as you work records the steps you took to get your repository where it is now.You initialize it, work a little, use git status to ask git what you’ve done, “add” some files (or parts of files) to be snapshotted together, and then you tell git you’re really serious about it and you want it recorded forever.
• #24: And we’ll throw in git tag, since it’ll round out a discussion I’d like to have about the effect of all of these commands.Git tag creates a permanent, human-readable and optionally annotated and signed pointer to some commit, so you’ll be able easily to get back to important commits later, such as release points.
• #26: Initializes an empty repo
• #27: git add tells git that you'll soon want some of your recent changes (and perhaps not others) to be recorded for posterity
• #28: I’ll interject here that it’s always a good idea to run git status before you do something permanent, as a quick check of your grasp of the situation.
• #29: And there you go. It even tells you what to do if you don’t want one of those files in the next commit.
• #30: Git commit takes a snapshot of the way everything is now, reusing what it can, and carves it in stone
• #31: And it tells you what it did
• #32: Including a shortened SHA of the commit and a summary of the changes it introduces.
• #33: And we’ll add a tag named “first_commit” for kicks.
• #34: This will be about the order of your normal micro workflow. Lots of working (sorry), adding, committing, and maybe an occasional tag.
• #35: now for a discussion of the git object database, the major component of git’s back-end,for de-mystification purposes
• #36: I showed you this slide earlier…
• #37: … sporting a git repo created using those most basic commands: git init, add and commit.
• #38: The thing to remember as we discuss the git back-end is that all of the information from this snapshot of your work is stored in files in this “objects” directory.We’ll return to this repository often to illustrate concepts.
• #39: the Git Object Database is a content-addressable filesystem in the back-end of git
• #40: You give it some arbitrary content, and it stores it, hashes it, and gives you back the 40-char SHA1 hash key you can use to retrieve it again.
• #41: all objects go in subdirectories under the objects directory
• #42: and when objects are stored, the first two characters of the SHA is the directory, and the remaining characters the filename
• #43: There are only four kinds of objects that Git stores during normal use.but first…
• #67: So say you have a little README file in a project called “SimpleGit”, and you’ve committed it to the repository.
• #68: The content is simply text,
• #69: As mentioned before the header has the string “blob”, a space, the content size, and a null-byte,
• #70: It’s compressed,
• #71: and handed to the Git Object Database, where it’s assigned a SHA.
• #96: Now I intend to rapidly reconnect all this theoretical information to our concrete repository.
• #97: First we’ll add an annotated tag, which adds a new object to the object database.
• #98: Now we’ll peek into each of these objects to give you an intuition about what git is doing for you with these commands.
• #100: cat-file –p is a plumbing command that allows you to peek into a commit given its SHA.It just so happens that the object I asked to see was the tag, which shows what object it points to, some meta information, and the annotation message, as discussed earlier.
• #101: Now we’ll open the object it points to, which should be the commit…
• #103: It is.The commit contains the SHA of the tree it points to, some meta information, and the commit message.
• #104: In any commit but the first one, the commit would have a “parent” line, pointing to the SHA of the commit that came immediately before it, here.
• #105: Let’s open the tree this commit points to next.
• #107: The tree contains one blob, and when that blob is checked out into the working directory, it will be named README.
• #108: And here’s that empty blob.
• #110: History Inspection.So, now you know how to record the history of your project as you work, and what git is doing for you, but for that information to be useful we’ll need to be able to inspect the history we’ve created.
• #111: so we’ll add three new commands, git log, diff and show
• #113: git log, without any arguments
• #114: prints out a pretty nice history of your commits in reverse order
• #115: or, there are many options you can pass to reformat the logs or get more information from them
• #121: git diff
• #122: git diff will actually give you a nice unified diff of two files or of states of your repository, or of the changes you’ve made since you last git-added anything…But what’s a treeish?
• #124: they’re a big bag of different ways to refer to a commit or commits …(which you should remember are just snapshots of the way your working directory is or was)
• #131: This one will make sense later when we talk about merges, and thus commits that can have multiple parent commits.
• #137: to get ahead of ourselves a little bit, here’s one especially useful range which will allow you to preview what you’re about to pushuse with git log, or with git diff if you need a bit more detail
• #138: git show.git show will try to show you something useful for whatever treeish you give it.
• #139: So if you give it a tag, such as the one we made earlier, we get the tag information, the information for the commit it points to, and a diff of what that commit introduces.
• #141: Now we control our present and remember our past, but what of the future.Of course we'll be working on several things at once, and what we're working on now will probably be different than what we have in production, or even what our colleagues are basing their work off of.We need the concept of branches to make that easier, and so git supplies very cheap branching
• #143: git branch lists, creates or deletes branches
• #144: here’s the creation of a new branch
• #145: the listing of the branches, with a little asterisk there to show you which branch you’re currently “on”
• #146: and deletion of brancheslittle-d delete will only successfully delete the branch you name if the branch you’re on already “contains” all the same commits.big-D delete nukes the branch no matter what, which is less drastic than it might sound, since the actual orphaned commits aren’t actually removed for months.deleting a branch only deletes the branch reference.
• #147: What’s a branch reference?
• #155: and this is important: the references themselves contain just one thing, in plain text: the SHA of the commit they point to.HEAD, in the root of .git, is the only way git knows which branch or commit you’re currently “on”, and it too is a plaintext file which just specifies which ref (or commit) it should go to.
• #157: but back to this slide for a second, since we’re about to talk about git checkout.the main point of git checkout is to change the HEAD file to point to something else, and then update the working directory to match.
• #158: so here I checkout new_branch, andbecause the current branch is now new_branch, if we made changes to our files and committed them, the contents of new_branch would update to the new commit’s SHA, but master would not
• #159: as an aside, there are many shortcuts in git, and one relevant one here is that you can create a branch and check it out in a single command with git checkout –balso, in case you were wondering, we’ve covered many things recently that are quite different from subversion, and “checkout” is a pretty radical one. checkout clearly does not mean the same thing in git as it does in subversion, if you’re familiar with that VCS.
• #161: Branching and Merging
• #162: say we have a repository with two commits.the master branch is at C1, which is also the current branch
• #163: we make a new branch and check it out
• #164: and we do some work, and commit,and the branch we’re on advances as we do
• #165: more work
• #166: now we checkout master
• #167: and do some work on that branch
• #168: and we’ll add a tag
• #169: checkout experiment branch again and do some work,and at this point, we decide the experiment was successful, and we’d like to merge it back into master so people can take advantage of it
• #170: we checkout master, since that’s the branch we want to merge onto,and we merge in the experiment branch.all this means is that the files are merged, and a new commit is (usually) recorded to log that it was doneSo… the files from the source branch tree that aren’t already on the target tree are merged in, and where a file was changed in both, the conflict is resolved automatically or manually
• #171: if git ever has trouble merging files, usually because two branches made different changes to the same place in the same file,it’ll put these markers in the file, and you just have to
• #172: manually edit the file the way you want it and delete the markers
• #173: and then save,git add them to mark them resolved,and commit them, and all will be well.the messages git gives you when there are conflicts are very helpful
• #175: a basic use of rebase can be thought of as an alternative to merging, which results in the same files but a cleaner history in the log
• #176: say we have this history, where we made two commits, made a new branch jess, made two more commits, checked out master, and made two more commits there as well.
• #177: a merge at this point would create a new commit on master with two parents.
• #178: here’s what would happen to the same tree if we rebased instead of merging. remember that master is the current branch.
• #184: so you end up with a linear history that’s easier to follow in the than a branched history. the “true” history can be examined using the reflog, which we’ll discuss a bit more later.rebasing rewrites the history, so don’t rebase if other people have used your commits. for instance, do not rebase commits that you’ve already pushed to a remote repository!but again, we’re getting ahead of ourselves again…
• #185: first, now that you know how to branch, I’m going to tell you how many successful developers branchin many open source projects, you’ll almost always see a stable master branch,
• #186: one or more development branches
• #187: which regularly
• #188: get merged back into master when they’re stable
• #189: and many topic branches
• #190: which is where most of the individual developer work is done,and which get merged back into development when they’re complete
• #191: master usually represents the production branch,
• #192: and development is your trunk
• #193: this is, of course, mere convention, and you don’t have to follow it, but it does make your work easier to understand and discuss,and you will be more easily able to switch back and forth between topics if you have topic branches to reduce the coupling between unrelated tasks
• #194: on to Collaboration, and more generally, remotes.We need to be able to work with other people, but the whole repository is on my laptop so... what?
• #195: our new commands are git remote, push, clone, fetch and pull
• #197: say there’s some web-accessible git repository somewhere and you already have a copy of the simplegit2 repo you’ve been working on, and would like to send up what you’ve been working on.
• #198: you find the url of the remote repository
• #199: this one uses the ssh protocol, so we can send as well as receive
• #200: we use git remote add to tell git we’d like to add a new remote repo to it’s records
• #201: we’ll nickname it “public”
• #202: and give it the url we found on githubnow, nothing at all happens when you add a remote, except that git has associated that nickname with that url
• #203: but now we can say things like git push
• #204: public
• #205: master, which, if our changes are downstream from the remote repo, will send all new commits on our master branch to the remote master branch
• #206: git remote with no arguments will tell you things about the remotes you have configured
• #207: and git remote show gives you a bit more detail
• #208: git clone is exactly what it sounds like – it makes an object-for-object clone on your local machine, of a remote repository. it also makes a local branch to track the currently-active remote branch, usually master, and checks it out.
• #214: fetch is the opposite of pushit downloadsany commits you don't already have from some branch of the remote repository into a not-that-hidden branch of your repository.No merging is done, but the commits are available for you to look at.
• #215: say we have a repository with a remote configured
• #216: simplegit again
• #218: notice that we’ve downloaded the upstream commits from the remote master not onto our master but onto another local branch, called github/master
• #219: which you can see using –a on git branch.now, this is an important point – remotes aren’t anything new to the git data model
• #220: they are simply branches, and appear underneath .git/refs/remotes/nickname/branchname
• #221: now this branch can be used in every way like a normal local branch, except that it cannot be checked out.you can merge from it, rebase onto it, cherry-pick from it, browse its logs… etc.
• #222: git pullthis one will be easya pull is not the opposite of a push.
• #223: the default behavior of a pull is a fetch, followed by a mergesince I’ve talked about both of those, I won’t spend any more time on it
• #224: those are the commands…
• #225: here are some practical examples
• #226: say we have this setup, and in our local repo, a bunch of commits.
• #227: we can git push over ssh to a public repo we control
• #228: so someone else can git fetch from it to get our commits
• #229: they may add their own,
• #230: and push to their own public repo
• #231: which we can fetch from to get (notice) only their three new commits.
• #232: which we can send to our repo if we like
• #234: this one’s a bit more complicatedthis is the github model, and is quite social
• #235: commit
• #236: tree
• #237: blobs
• #238: i have a public project I’m working on, and that remote is nicknamed “public”so I push my commit tree there
• #239: nick clones
• #240: and does some work
• #241: jessica clones
• #242: and does some unrelated work
• #243: they both push to their own public repositories
• #244: now, I’m interested in their work because it’s based on mine and perhaps they asked me to merge it into the main project…so I need to be able to access it in my local repo
• #245: so I nickname nick’s public repo url “nick”
• #246: andjessica’s
• #247: “jess”
• #248: and now I can do cool things like git fetch nick
• #250: and git fetch jess
• #251: to get their work for inspection
• #252: I like it all, so I do a fancy three-way merge
• #253: and push everything up to my public repository for the whole world to use
• #254: that had to be pretty fast, but notice the propagation of objects
• #255: nick’s
• #256: jessica’s
• #257: and my merge objects
• #258: that wraps collaboration
• #259: on to advanced stuff, starting with…
• #261: you remember the .git directory
• #262: well, there’s the index
• #267: imagine we have some repository, and its state is laid out here
• #268: on the far left we have the git object database, which currently contains two commits, one tree and two blobs
• #269: on the far right our working directory,
• #270: and in the middle the index.
• #271: we then checkout master,
• #272: which populates the index with
• #273: the SHAs of the files as they appear in the object database,
• #274: the SHAs of the same files as they are in the “staging area”,
• #275: and the SHAs as they are in the working directory.(and by the way, the SHAs are always 40 characters, but I use just three here to save space)
• #276: it also keeps track of the modified time
• #277: and the filenames, which both match those in the working directory.
• #278: now say we edit file2, which changes the mtime
• #279: when git status is run, the index is updated with file2’s new SHA and mtime under the working dir column
• #280: because the “staged” SHA for this file differs from the working dir SHA,
• #281: git knows to tell you that you have a file that has been “changed but not updated”
• #283: now let’s “add” that changed file to the staging areapeople usually just say that the file is “added to the index”, or “staged”
• #284: notice that after an add, the staged SHA for the file matches the working dir SHA, which is still different from the object directory’s SHA because the file hasn’t been committed
• #285: however, a dangling blob of that file’s current state has been added to the object database before any commit
• #286: now if you run git status,
• #287: git knows that the file is staged to be committed.
• #288: so when you run git commit
• #289: it updates the index appropriately,
• #290: writes the new commit in the object database, the new tree containing one old file blob and the one new file blob that was stashed there earlier,
• #291: and moves the branch forward to the new commit.
• #292: one more time.we edit both files again, and run git status.
• #293: the mtimes are both different,
• #294: so git knows to update workingdir SHAs.
• #295: this time we’ll only git-add file1,
• #296: which updates only its staging column in the index to match the working dir,
• #297: and not that of file2.
• #298: so when we run git status
• #299: git tells us the right thing about both files, based on the differences between the relevant columns in the index.file1 is a change to be committed,
• #300: and file2 is changed but not updated.
• #301: and of course, when we then commit,
• #302: the index is updated and the object dir receives a new commit and a new tree with the new file1 blob, and the master branch is advanced.
• #304: On to hook scripts.This will take about thirty seconds, since you all either do some bash scripting or that would have to be its own talk anyway…
• #305: when youinit a new git repository in the more recent versions of git,
• #306: it always creates a few sample hook scripts for you, in the “hooks” directory.
• #307: The samples tell you generally what to do, but note that there isn’t a sample for every event that can trigger a hook.you’ll have to look online to find them allthis one verifies that any filenames you’re trying to commit contain only ascii characters.another useful thing to do might be to bootstrap your rails database on a git checkout to ensure consistency, etc.
• #308: last thing before we move to troubleshooting: useful things you’ll need occasionallythe goal here is mostly to make you aware of these commands, so you can look them up when you need them
• #309: interactive git-addoften what you’ve changed would be awful to type, so you select it with your mouse, copy it, and paste it back in.
• #310: there is an interactive add, which lets you pick the files by number and even let’s you add individual changes inside a file, instead of the whole file at oncewe’ll enter u (or 2) to “update” the index
• #311: it shows us the list of unstaged changes and we’ll select the item labeled 1
• #312: notice there’s a little asterisk to the left now to show us we’ve staged it
• #313: it tells us we just updated one path, and we’ll ask it for the status with “S”
• #314: there’s the updated status again, and we’ll do “q” to quitand when we run regular git status, now it’s listed as a change to be committed
• #315: interactive add is cooler than this, and I encourage you to try this one out on a file where you’ve made multiple changes.it allows you to add individual patches in the file to the index to be committed, instead of the whole file- useful for making neat, conceptually-grouped commits
• #316: these will go faster nowgit stash tucks all of your uncommitted working directory work away for just a bit, most commonly so you can change branches without messing up your uncommitted work,and you can bring it back later with git stash pop (which removes the stash from the stash list) or git stash apply, which leaves it thereview it with list
• #317: something very cool about git stash is the --keep-index option, which will stash all changes except for those you’ve already staged with git addthis is very useful in conjunction with patch-adding, for testing to see if a patch-added commit actually builds
• #318: default behavior of git cherry-pick applies the changes introduced in a particular commit and records a new commit for themvery useful for pulling in just a few of the changes in someone else’s hot idea branch after a git fetch
• #319: git fsssssck is the final defense against lost thingsI won’t elaborate, but if you’ve ever committed or stashed something and then seemed to lose it in any way, it is almost certainly still retrievable,but you might need this command to find it. when you do, make a new branch that points to it so you don’t lose it again
• #320: the reflog tracks changes to where the references are pointing, and anything that happened while they were pointing thereit is your “true history”useful for figuring out how things originally were before a rebase or other history rewrite
• #321: git bisect will help you find where an error was introduce into your code, and thus probably what changes cause that error, by doing binary search through your history
• #322: you start with git bisect start,then you tell bisect that the current state is bad, and that the last known good state was the commit pointed to by this tag heregit automatically checks out a commit in between those
• #323: there’s nothing wrong here, so you tell git and it checks out another commit, half-way between the one you just tested and your bad commit
• #324: this oneis bad, so you tell git with git bisect bad
• #325: and this one is good, so you tell git, and it now has enough information to know which commit introduced the errorand it shows information about that commit
• #326: finally, run git bisect reset, which will return your HEAD to where it was before you startedor you’ll get yourself into a weird stateyou can also give git bisect a script to run that determines if the code is good or bad, and it’ll do everything automagically for you
• #327: Oh good, we’re almost half-way through the talk.
• #328: troubleshooting is something best learned while you’re in the middle of a problem,so I’ll do the same thing I did with the grab-bag of useful commands, and just make you aware of some things,and you can check these slides later when you need them
• #329: how to change you rmind about what you want to commitgit reset with no arguments is the opposite of git add,git checkout HEAD filename will permanently nuke the changes made to that file,and git reset --hard will permanently nuke all changes since the last committhe last two are dangerous, since they destroy uncommitted changes!
• #330: the difference is that default git reset moves the branch pointer to a particular commit and updates the index,but git checkout moves HEAD itself and updates the working tree
• #331: how to change your mind about a commit after you’ve already committedif you just committed something and realized you didn’t add all your files, or you messed up the commit message,git add whatever you want and run git commit --amendthis is actually short-hand for rebasing onto HEAD~ and then committing - it undoes the last commit, turns it into a patch, and commits afresh
• #332: how to ditch a commit by moving the branch pointer backyou can ditch a commit or just move around and explore by moving the branch pointer before continuing workwith git reset --hard or git branch -f (for “force”)
• #333: how to uncommitt things you didn’t mean to committhere are three options -1)reversion, which is always an option,2) just ditch the commit by moving back to an earlier commit before continuing work,3) and the nuclear option, which you’d need for accidentally-committed sensitive data or enormous files. git filter-branch can actually go back through your entire history and permanently remove a file, rewriting every commit since you committed that file.The last two will wreak havoc on anyone who’s already based work off of yours
• #334: and a good way to avoid these problems in the first place is a good .gitignore file before you start working
• #335: you can actually have a global .gitignore file if you edit your configuration like thisand then make a .gitignore file in your home directory
• #336: here’s what’s in mine
• #337: this is just something to be aware of - some editors won’t notice when a git checkout, merge or pull, for example, yanks the files out from under it and replaces them with new onesyou could accidentally overwrite someone else’s work
• #338: and here’s the summaryother than that, I just hope this talk has given you enough insight into git that you can hash through any issues that arise
• #339: we’re almost done, so a quick review
• #340: here are the twelve most used git commands, and git status which my fingers automatically insert after every commandgit init conjures a new repo from the air,git clone makes a local clone of a remote repo,git add stages changes to be committed,git commit carves them in stone,git branch manages branch pointers in the tree of commits,git checkout jumps around the branch tips and checks out the relevant files,git merge will merge two or more branches, recording a new, multiple-parent commit,git remote manages remote repos,git fetch downloads new commits in those repos,git push uploads new commits to those repos,git diff shows the differences between treeishes…and git log shows you the history of commits in your repository.git status shows the status.
• #341: And one last time, the .git directory.you should recognize most of what’s in here now, and what you don’t know about yet is either peripheral or easily discovered on git-scm.com
• #342: speaking of which.here are some excellent resources