 This is going to be a rehash of a presentation I gave to my co-workers. We used Git, obviously, at work, and we used it in kind of a weird way. And we found that when we brought new developers on, it took them a little bit of time to get up to speed on using Git. And I noticed one thing when I was learning Git, which was that people who have gotten over that Git learning curve, they start to say things along the lines of, you know, Git really makes a lot more sense when you finally understand food. I found that that was not terribly helpful. I found myself saying things like that to a friend of mine who then gave me the feedback that, yeah, you said that, too, and a lot of other people said that, and I didn't really get it until I had that same epiphany myself. So I sat down to think about what the perspective was that made Git finally make sense to me, and this is what came out of that. So, Git makes more sense when you understand Git. I did a quick search for that, came up with a million results. This was one of my favorite ones. This was Kent Beck last year, actually earlier this year, finally figuring out the Git commands for doing graph manipulation stuff. And I thought this was awesome for two reasons. One, because it was a great example of this statement of the form. It makes much more sense when you understand X. And two, because I read, I've read several of Kent's books, and he's great. And it just fiber gets to me that I have understood something before he did. And that was really cool. This was the other awesome one that I came across. Homie Moe. I had some manifold stuff in Hilbert's space. This was great. I have no idea what the fuck to be. Yeah, I don't know what to say. Okay, so my goal for giving this talk to my coworkers, and I hope that some of you will take this away as well, was that once you understand where the pointy bits are in Git, and you understand what they do for you, you can get a lot more comfortable using Git without feeling like you're going to chop your leg off. And more kids. So Git is obscure. It also is ridiculously powerful. There's a reason so many of us use it. Most of that power, I find, comes from the way that Git looks at your code and the history of your code. And that's not really Git. That is a computer science thing that can be taught. And once you understand that, again, it becomes much easier to use. This is a great quote from a couple of years ago about Git Rebase Interactive. This is from a wonderful article about running a Jamaica that you show up on the read. These slides are all online. And I can show the link at the end. It's powerful. It's from the way computer scientists see the world. It's surprisingly easy to think about. I wrote this for a number of co-workers who do not have computer science backgrounds. I expect you guys to get this fairly quickly. But it's the same set of slides, so I'll just run through them. This is the neighborhood where I live in Portland, Oregon. It's fantastic. Lots of trees and everybody gets lost because it's not on the grid. Some friends of mine call this the Vortex of Portland. Nearby, there's a bridge. Here's a drawing of Konigsberg-Prussia, a family tree, a social network, a really fun graph they generated at Facebook a while back showing connections between cities. Some sort of sporting event, I assume. And a fun screenshot from Visual Phasaurus, which is a really fun little thing to load up at parties if you load it up 10 minutes beforehand because it's a job. So what these things have in common? I decided to run through these slides again with some helpful graphics overlaid on them. Here's my name right again. Here is the Morrison Bridge, Konigsberg-Prussia family tree, social networks, both part of the Facebook sporting event, Visual Phasaurus. The things that these things have in common are one, that they don't have places to be, and two, they have ways to get between them for anybody who's not having their science degree, they call that graph theory. This is a screenshot from the Wikipedia entry on graph theory. Scared by the math. Or as a friend of mine, as a co-worker of my footage, all I heard was nerd, nerd, nerd. A graph is a collection of nodes and a collection of edges that connect, each edge connects two nodes. Nodes basically are places to be, and there are ways to get between them, and that's all you need to know. The history of graph theory goes back to the 18th century. As I was told the story, and this may be apocryphal, but as I was told the story, there was a favorite pastime of people with money and time to try to walk through the city of Konigsberg and cross every bridge, of which there were seven, exactly one time. Tempina, and this guy Leonard Boyler, who was famous among mathematicians, wrote this paper and basically invented graph theory. I said I was going to talk about it, and this is the timing, this is the perspective that I wanted to share. Gip commands are really about working with graphs. Going through those pictures that I have before, in a different order, we have nodes that are places to be, edges are ways to get between them. I have some examples. Konigsberg pressure, this is the original graph theory problem. The thing that I really love about this particular example is that one of Boyler's key insights was that from the perspective of this problem, it doesn't matter where you go, once you've crossed a bridge, if you go onto the island and you walk around and you keep shopping, it doesn't matter what that is, because from the perspective of the problem, you're only concerned about which bridges you're trying to cross. So this idea of taking only the key information and throwing everything else away is something that I really love, and it's key to being able to actually solve problems. This is an example of a fairly large graph. This was Facebook doing some connections between cities, and they colorfully linked between them more brightly if there were more pairs of people in those cities that had friendships with each other. I also like this one because it shows where the world is on Facebook and where it isn't. Again, my neighborhood, I should say about that. One other thing about graphs is that sometimes, actually there is something to say about that, in this one you can go across the edges in either direction, in this one you can only go from one end to point B, and if you want to get back, you have to find another way to get back. We call that kind of an edge, a directed edge, and that kind of a graph is a directed graph or a digraph for short social networks. I just included this slide to illustrate to my non-technical coworkers that you can attach information in a graph to either the edge or the node. Family Tree is a directed graph with some interesting properties that non-mathematicians don't really care about. This one I included because it's exactly the same as the Family Tree in structure. It's just describing a very different problem and I thought that was kind of cool. I only included the visual as a source because when you look at it, it's completely obvious what it is and you don't have to have any idea of what graph theory is, but it's also like no translation is required to think of it as a graph. It's sort of the mathian continuum of graph theory. So, the point. When I learned graph theory, it was a lot of fun. It changed the way that I looked at the world. Once I had that perspective shift, I started to see graph theory in a bunch of different places and I thought that was a fun thing and I was really, I was kind of upset when I learned graph theory that I was 27 or 28 years old and all of my life I had not known about this stuff. It was just kind of an accident that I wound up learning about it and I was like, hey, this is really cool. I don't want to walk up to people and say, hey, learn about this, it's great. I've gone on about graph theory in these slides because it is really about manipulating graphs. So having that tool set, in addition to being sort of a general thing that helps you look at lots of different problems, it also helps you think about it. Most of the power I've said earlier comes from the way that it looks at the world. Once you understand that, it becomes much easier to use it without feeling like you're going to shoot your foot off. And again, I'm going to throw this in because it's a joke. It was funny. Okay, so this is a screenshot of my primary Rails application network from back in May of last year and the screenshot is from GitX. This is merge hack. Anybody have Git repositories that look like this? So, yeah, the Git repository is a graph. Every commit in Git is a node in that graph. It's a point in history to where something happened that you care about and you said this is this version as of this point in time and here's what's interesting about it. And that, unless it's your very first one, that has some history that came before it. So nodes can obviously point to other nodes that they're based on. So you say, here's the initial state of the world and then I make this change and then I make this change and then I make this change. And of course you can branch off and that's time travel and all kinds of other stuff. Most commits point to one, you can have commits that point to two or more and it has to be octa-gathering, we've all seen. Actually, I think it was today, possibly just an hour or two ago, Michael Schwerin gave this great talk at OSCON, gave, again, this talk at OSCON, called Git for ages four and up, which is a great talk. You should go and watch it if you're at all shaky with Git. I included this partly because it's a great link and it's worth watching the video, period. And partly because it's another example of this, it makes so much more sense when you understand X. Go check it out. He uses Tinker Toys to describe the state of the repository as he goes. It's great fun. The short version of that is that most Git operations do one of these. They either add a node to the graph or they move a label around from one node to another node. And when I say label, going back to the Tinker Toys thing, he's got these structures that he makes out of Tinker Toys. And then these 3x5 index cards are labeled like master and feature branch that as they type commands to make new commits in the graph, he takes these labels that are on popsicle sticks and takes them off of one node and puts them on another node. And that's the effect of doing Git merge or Git rebase or whatever. This is a screenshot from Git X, another one, a simpler one. Any non-max here? I see one. Two hands over there, three. All right. I saw somebody tweet earlier that this conference was like the best ad for Apple ever. So anyway, Git X is great. I use it every day. It uses four colors for its labels, where label means either a branch or a tag. When you're looking at it, it shows the current branch in orange. It shows local branches in green. It shows remote branches in blue and yellow to indicate a tag. And I'm going into this because it's kind of relevant to the way that I learned to get better at using Git. The reason that Git is horrible to learn is that it uses this random terminology and it assumes that you know what it means. Local branch references move around when you do things like Git commit and Git merge. Remote branch references move when you have done stuff on your local repository and then you type Git push. So that's saying, take the state of my world and make the state of that world over there be similar. Tag references don't move at all. Sorry, it's going to be the last time I get this presentation. There's this other concept of reachability. So if you're looking at this graph and you're standing at H... The history of the world that you can see is HGFBA. If you're standing at E, you can't see H and vice versa. So each of these are sort of like alternate universes. There's another fun way of thinking about it. And the reason that I mentioned this is that references are a way that you can sort of nail down parts of this graph. References, which is to say a label, which is to say either a branch or a tag are a way of making commits, which is to say nodes and the history that they depend on, something that you can get back to. The reason I mentioned this is that when I first started using Git, I was super paranoid about using code. I would actually back up the entire directory before I did something I was worried about. Change to the parent directory, recursively copy the whole thing to a backup, go back in, do something that I thought was a little bit scary and confirmed that it worked. And if I was happy with it, then I would go back up, delete the backup and continue working. And if I screwed it up, then I always have that complete copy to go back to. Has anybody else done this, or is it just me? I'm good, okay. Thank you for validating that. I did that for like a year until I finally realized that when I did those things, I was always worried about what some merge was gonna look like or maybe I was playing around with rebase, which is kind of a dangerous command. But I realized that I was always working on a branch when I did this. Branches are references, and references make commits reachable. So what I could do was create a new throwaway branch, you know, from wherever I go and get checkout-meat-food. Do whatever I was trying to do with that branch. If I screwed it out, then I could switch back to the original branch, delete the new one, and that history would eventually be garbage collected. If I got it right, then all I had to do was say, get reset this to go over there or do the merge or whatever it was, and continue working. That one thing saved me, well, first off, it saved me a lot of time in, you know, that CP-R, et cetera. And then it really helped me figure out what was actually going on and feel a lot more comfortable that even if I did something really dangerous, I could always get back to where I started. And so this became the strategy that I would use, and this is why I spent a little bit of time talking about Gidex in particular. Gidex lets you look at the state of the repository at a particular point in time, and then when you hit Command R to refresh, it goes back and updates the display and shows you the new state after you've done something weird. So what I started to do, and this is a strategy that you can either use yourself or teach people who are new to it, you basically check out a new branch and, you know, I consider that like a save game. You look at Gidex and kind of visualize the part of the graph that you're interested in, and you really understand what it's telling you, what each branch label is, and figure out what you want to do. Do what you need to do, switch back to Gidex, and before you hit refresh, you'll figure out in your head what it's supposed to change to after you hit refresh. So you say, well, if I had this branch over here, this level here, and this level here, and I did emerge, then I hope that this one has moved up and now there's a new command that points to both of those things that were there before. So you figure out in advance what you expect to see when you hit refresh, and then you hit refresh. And then you have a chance to either say, ah, I was right, I've learned something, I'm able to make these predictions, or I didn't understand something correctly, and then you have a chance to figure out what was different. Do you have a chance to learn something new? That's really it. I have some prepared for my coworkers, but I don't remember them at the moment, so I'm not going to try and do live coding on stage. I'm completely unprepared. The slides for this talk is on the website, to thinklikeagid.heros.com. And yeah, that's it for me. Any questions? This is a question for the broad audience. I'm curious to know if using Git, I have a chance to do a graph theory. What's always so interesting to me is not knowing exactly what the whole everything is due to graph. And I was curious if anything is used for this, you know, as knows the tool that actually was I'll just sort of leave it at the graph So to try and paraphrase the question, the command line is sometimes hard to approach and you're wondering if there are GUI tools or something that you can use to work with it in a different way, in the alternate ways of representing it? Yeah, I don't use GUI, but the system is actually making modifications to the command line by looking at the graph or the page and getting an actual license to use that. I have just actually trained two non-technical co-workers to use GUI Tower and they seem to do reasonably well with that. It's like $60, but they have a particular trial that you can play with. GUI Tower, it's gith-tower.com. Anybody else have tools that they like? I just have a comment for the last question. You can also remove labels around GDX as well with your mouse. Can you really? I don't do it personally, I can't do anything. Sorry, the comment was that you can remove labels around GDX, which I did not know, that's cool. Yeah? This is Gith-tower, I use it at a lot of games and I wish it had more features. The comment was, Tower is great, but in the back, in the yellow. Here's a fork by Brother Bar, I think it's the name of the guy that's like a much more advanced version of Gith-tower. The Brother Bar fork, I saw something about that this morning, I was going to check it out, thank you. Yeah? Did explaining it like this help less technical people, like designers or from the developers understand it? Unfortunately, the two designers who I was really hoping I wrote this for them, both of them were actually out that day. Sorry, the question was, did this talk and did explaining it this way help less technical folks? And yes, it did. I got great feedback from the QA person, and I don't want to say if the QA person is non-technical, but they're certainly less technical than the dev team. I got great feedback from our father, Toner, and those two people I've since trained to start doing it again. Any other questions? Thanks very much.