Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons and this is episode 79, I think. Right? Yeah, 79. It's weird, we haven't done... we've only done maybe two episodes in the last four weeks so I feel a little out of practice. But meanwhile I've been obsessing about The Web Ahead actually because I am building, finally, building a website for the show. Hopefully it will be out soon. I'm hoping in the next month to launch it. Maybe even by the end of August 2014. But if not, then early September 2014. So I've been loading up content and looking at old shows and just staring at transcripts and it's been kind of amazing, actually, to realize, 79 shows... [laughs] is a lot of shows, a lot of topics, a lot of good stuff. So I'm really excited to get the website finished and in a place where you can look at it. So I'm going to start talking about it on the show simply because I know a lot of these episodes, people listen much later than when they're first recorded. So perhaps you're listening to this and the website is already out. We're still totally on 5by5, all the shows are still totally there. All the pages on 5by5 are still, all those links will still totally work, the show notes and such. But we're also going to have it over on the new website where there will be a lot more information about guests, about the sponsors, and about eventually, I don't know that I'll launch with this turned on right away, but later I want to have a place where listeners can submit examples of, like, "Oh, look at this awesome WebRTC project I just did or I just found. Let's put that on the WebRTC page." And make it much easier for you to find older shows. Maybe you really want to focus on content strategy and listen to all the shows about content strategy. There will be a page just for that, where all of those shows will live together and you can find them. 'Cause now that we have more and more and more shows, it's... that's a lot of hours. [Laughs] So, maybe you want to be able to sort of focus in on a certain topic or subject or go back and listen to stuff. So that's the idea. But I also wanted to talk about it, bring it up, because there are people who are totally helping make this project happen. And it's happening faster because of their help. So you can go over to, this is going to be just a freaky place, but github.com/jensimmons/thewebahead/issues. I'm just using because, you know, it's here, easy to use, an issue tracker on GitHub to list a bunch of issues that people are helping with. People are totally helping load up content, track down bios for our dozens and dozens and dozens of guests and stuff like that. 'Cause it's taking time and it's making it much faster. So I also wanted to say thank you to Jenn Schlick, who's done so much work transcribing the shows and now also helping put those transcriptions on the website as well as other things. Jason Neel and Matt Sugihara... is that... man, I'm sorry, Matt, I don't know how to pronounce your last name. Sugihara? Phil Jones, Robert Fonó, Ross Penman, have all been really great. And Sean Fitzpatrick, who also knows Drupal, and he's been helping with some of the Drupal. It's all Drupal website built, Drupal backend stuff, he's been helping with some of that, had some great suggestions on some modules I hadn't thought of. So thanks to all of them and to everybody else who's about to start helping out. It's really been fun to work with a team again. Like a little fun volunteer open-source-y type of team.

So enough about the website. Check it out once it's up. And now I have no choice but to finish it. [Laughs] So my guest today is Tobias Günther, who is gonna explain all the hard stuff for us and make it more understandable. Hi, Tobias.

Tobias

Hi Jen. I'll do my best, thanks for having me.

Jen

That was a long, rambling, Jen-only intro. [Both laugh] The two of us are going to talk about Git today. And you are one of the founders of Fournova, who puts out Git Tower.

Tobias

Exactly. Git is a... more than a hobby for us, to say that.

Jen

Yeah. Like, I figure you probably think about Git and how Git works and how people use Git pretty much all day, every day.

Tobias

Yes, yes, because we make a Git client, a Git desktop client for the Mac, so Git is our daily work and we think a lot. We indeed think a lot about how people use it, and yeah, sure, how to make it easier to use. Because it is a bit complex but also, well, a very good system. So, good to learn to it.

Jen

Yeah. And I've been using Git Tower since the very beginning. I don't remember if it was still in beta, version 1, or if it had just come out, but it felt early.

Tobias

Yeah, I think you were part of the beta, really. Yeah.

Jen

Yeah, I think I was, 'cause I remember shopping around and looking, there were maybe two or three or four different Git GUI clients, which basically means I'm a loser, not as good as a developer [laughs] because I'm using a piece of software where there's lots and lots of buttons and pretty diagrams and lists and things to click on and I use that to make Git commits and pushes and merges and fix merge conflicts and all that stuff.

Tobias

That's a common misconception, so you're not a good developer because you're using GUI applications. We'll talk about that later on. [Both laugh]

Jen

Yeah, I mean, I don't think that that's true, but I do get that kind of, like, "Ugh, you should be using the command line if you're a real developer." [Tobias laughs] And people ask me, "Why do you use a GUI?" And honestly, it's because... I guess if I were a developer who's on the command line all day, everyday, then it would be natural to only use Git on the command line, perhaps. But many times, when I'm writing code, what I'm actually doing is designing. And my brain is in this visual mode, in this sort of spatial mode and in this mode where I'm thinking about where things are in the world and moving things around and I don't want it to be linear and language-based. I want my workflow and what I'm actually doing to be much more visual and much more about digital versions of physical spaces. And in that way, having a GUI client really fits what I'm doing, instead of yanking me out of what I'm doing.

Tobias

Yeah, absolutely understandable. Even the hardcore developers, the nerds, do use a GUI sometimes. So here at Fornova, well, I guess we're nerds, we use the command line and the GUI side-by-side. So even we at Fornova still use the command line. We don't push it away and only use the GUI client and vice versa. Still both using both side-by-side is still absolutely, well, great. Yeah.

Jen

So what are some of the things that you... 'cause I know that you also teach Git and you're putting together books and tutorials and stuff about Git. What do you think are some of the things that are maybe the, um, where people get stuck with Git? Where they... you know, they get through the basics, and they kind of, I mean, of course, the hardest thing is, "What the heck is it? Why do you need to use it?" Once people get past that and they're using Git and they're making commits on a daily basis and that's how they're working. But then they get tripped up. Like, what kinds of things do people get stuck on, do you think?

Tobias

I think it's two main things. The first one is branching, actually. It's hard to get your head around branching if you've never used it before. So that's definitely a big part of the explanation. And the other thing is coming from a different version control system, and I don't mean another distributed one like Mercurial, but a centralized one like Subversion. Maybe people are coming from Subversion these days and, well, it's a different game. Getting your head around the basic concepts in a distributed version control system like git, that's a big problem. Letting go of the old concepts while looking at version control with a fresh mind. That's really a tough thing to do.

Jen

Yeah. So let's talk about branching then. About why you would want to use branching and when and then maybe what about it is hard.

Tobias

Yeah, yeah, sure. The reason to use branching is, you want to be sure that you're allowed to mess up, actually. You want to be allowed to make mistakes and that is the reason why you can use branches. Because if you're using branches, your topics are separated clearly between each other. If you're not using branches, you're putting all the stuff in the same, let's say, context. Let's talk about branching like they're folders on your computer. You want to put invoices into the invoice folder and graphics into the graphics folder. If you mix that up, chaos is the result. And that's the same when developing stuff. Separating topics with branches is a great thing and it's your safety net, actually. If you make mistakes in one context, that's not a big problem because all the other contexts, all other features, a stable line of your code, is still safe and won't be broken by that. So that's the biggest thing, the biggest reason to use branches, actually.

Jen

Yeah, I mean, so you're basically, you're on master. Anything anybody ever does is automatically put on master unless they switch into another branch. You make a branch. And that's one of the things, I guess, the big things when... it now feels like an epic decade ago, but I guess it was only maybe three years ago, four years ago. That people were switching from SVN to git, and it was like, hey, it's super easy to make a branch, do it, so you just clickity-click, in my case, [both laugh] or on the command line, type whatever it is you're supposed to type, and you make a new branch and then it's like a parallel universe where you can experiment and do crazy things.

Tobias

Absolutely. Yeah. And people came from Subversion and branching wasn't invented by git, by no means. Subversion knew the concept of branching, too. But people knew, "Wow, branching is really difficult in Subversion so... I'm not sure if I want to use that in Git either." So that's a big problem because branching in Git is a whole different story and it's a lot easier. You should give it a chance.

Jen

So, I mean, I feel like, I work alone a lot and I use branches when I want to kind of go down a weird path. Especially if I'm designing and I'm like, "Oh, I have an idea for designs, but it might be completely..." It's the same reason I switch and make a new copy of a file in Photoshop or something. 'Cause I know I'm about to do something really crazy and I might want to just throw the whole thing in the trash and I don't want to have to step back through history or figure out where it was in the past... I just want to be able to chuck the whole thing when I decide that it's a failure. And that's a great reason to make a branch. But that's not the most common reason that people make branches. And what I've seen a lot when I've worked on development teams is that... I guess sometimes it's been like, "Ok, let's each make a separate branch." So there's, like, the "jen" branch and the "fred" branch and the "aaron" branch and the "wally" branch and then each person is in their own little space and they can do whatever they're doing and they push their work back to master when they feel like it's ready. But what I've also seen more common is that people make feature branches and that every time there's a ticket, a user story or a bug ticket or something, somebody makes a branch to go with that particular ticket, and they do all the work for that ticket in a branch, and then they push that back into the main repo. What is it that you've seen when it comes to... not so much the technology, 'cause what the branch technology does is fairly static. But the ideas, culturally, on teams, how to use branches and why to use them and what to make, when you have rules on your team about what everybody's supposed to do. Like, what workflow is it that seems to work well for people?

Tobias

Yeah, yeah. So that's, as you said, that's different for each team. The most important thing, I guess, is to agree on a common workflow on a team. Actually there are two big workflows that can coexist, even, in a project. One is a topic branches, like you said. For every topic, and by topic I mean a new feature, a bug fix or an experiment or something, there's a new branch for that. That's topic feature, by definition is, well, is short-lived. It's not there until the end of the project but only until the end of that feature or until the bug is fixed. That's the small, the short-lived branches. Then there is the long-running branch concept. In bigger projects, you mostly have a stable line, maybe that's the master branch, and don't ever commit directly on the master branch. This is dangerous because it's production code and below that come all the feature branches. So it's really a hierarchy and those long-running branches are there during the whole project. So you have a master for production and a development branch, maybe another testing branch or something, and then the short-lived topic branches. So these are two very common workflows that I often see with people. That's very common in the wild, actually.

Jen

Yeah, and then I've also seen tagging put on top of that. So that if there's, say... like you just said, there's feature branches and then there's a main development branch that sticks around longer and then there's a stable line that people use tags to say, "This is the 0.4 release and the 0.5 release and the 0.7.4 release and the..." just to kind of mark little flags in the world of, like, "Ok, we actually pushed that to the world."

Tobias

Yeah.

Jen

I mean, what do you think is tough about that? Where do teams fail in figuring that out... it just seems so controversial and, like, nobody's quite sure that they're doing it the way that they want to, or nobody's really quite sure how they're supposed to do it, or...

Tobias

Yeah, yeah. I think people coming from different backgrounds, that's one problem. So having a very complex branching workflow with a team of lots of designers is just probably too much and a bit overkill, probably. But on the other side, the CTO might want to have his reasons for thinking about a complex workflow. So I think it's important to find a balance in the team. Don't make it too complex and on the other hand, I think, I said before, people do have to learn the basics of Git. So even if they come from years of experience in version control and they think they already know how things are going, chances are they might not. Because Git is a bit different and, I said before, branching works a whole bit different than in other systems. It's really worth to take the time and get the basics right. I think that is one of the problems.

Jen

Yeah. Will you talk a bit about how branches are different than forking a repo and submitting a merge, a pull request, kind of workflow?

Tobias

Yeah, sure. So forking a repo is actually making a copy of the repo. In contrast to that, branching is just on the repo level. If you're creating a new branch, it's just a new context inside of that repository. And in contrast, if you're forking a repository, you're making a complete copy of the whole repository. These are different levels of action, actually.

Jen

Yeah, I mean, it feels like I see it mostly in open-source projects. Where you don't give the whole world access to the original codebase. You give them the opportunity to fork it. Why is that being used as a workflow instead of trusting people to actually be on the one and only main, the real repo?

Tobias

That's a valid question and I can't provide an answer to that. [Both laugh] If there are really complex projects, of course you'd have to take, well, complex workflows, but in most cases, I think, this would be inside of a one in the same company, it would be overkill, I think. Because as you said, you can do a lot with branches, with simple branching inside of one repository. If you have a bunch of high-class nerds, that might want to use that workflow. It's, of course, definitely a valid workflow but I think not necessary for most cases, let's say it like that.

Jen

Yeah, I mean, it's cool. It's really cool that Git has all these tools and has all these powers because then you can just kind of figure out, you know, you can do whatever you want. You can do whatever you think is best for your team. Even when your team is just one person. That's another thing that I find interesting, is that Git can be extremely useful even if you just have one person or maybe two or three people working on something and you have a tiny little team.

Tobias

Yes, absolutely. This is not a big team issue or a big team tool. You get all the benefits of using version control by yourself. Being able to roll back to recover from mistakes. That will happen. This is the most important thing, I guess. Being able to experiment safely in your own project, even if no one else is affected by your mistakes but yourself. It's still worth being able to recover, to undo. That's the reason why version control is important.

Jen

So let's talk about that. 'Cause that's another place, I think, where I stuck, I think I'm sure other people get stuck, right? I can say all these wonderful things about how awesome it is and how you can always roll back and you can recover work and blah blah blah. But then the truth is, when I need to roll back and I need to recover work. [both laugh] frequently I'm lost. I'm like, "I'm really glad that that's there, but I don't know how to get to it." Or, "I think I know how to get to it, but I'm getting... I'm confused." Or, you know, why do I want to use Git revert vs Git reset vs Git clean? And when do I need to use --hard? Usually, I'm just like, "Undo the stuff that I did and take me back in time." I want the Git take-me-back-in-time command. Like, where is that? [Tobias laughs] So can you talk about, how do you get back? How do you recover? What are some of these options? When do you use one versus another one?

Tobias

Sure, that's a great question. Because indeed there are a couple of different ways to undo. It's a broad term, so, yeah. Let's start with the most basic distinction. You can undo uncommitted local changes in your working copy and you can undo committed changes, older revisions and so on. Let's look at the first case, first. Undoing stuff that is not committed yet, that is local in your working copy, local changes that you just made, is, well, the easiest thing to do but also the, well, the only undo action that you cannot undo. If you're discarding local changes, you should be damn sure. Because you cannot undo this. The reason for this is, it has never been committed to the repository. It's not saved in Git's great database and if you undo local changes, they're gone. This would be on the command line, the Git checkout command. Same as switching branches but the two dashes, sorry about that, I didn't design Git. And there's the other type of undo that deals with committed changes. Commits that have already been recorded in the local repository. There are, I would say, two main commands to do that. There is a Git reset command and a Git revert command. Actually the distinction is easy. Let's see if I can tell it in an easy way. Reset really takes you back to a certain revision in your repository. If, let's say, you're rolling back with the revert command, sorry, with the reset command, by five commits. These newer four commits are, essentially, gone. You could recover, in theory, so there's nothing lost if it proves wrong. But essentially they're gone and you're at commit number, well, n-4. Revert, in contrast to that, just takes one commit and reverts its effects so nothing is deleted by a revert. Let's say you have one commit in the middle of your repository and you know the changes you made in that commit are bad. Everything else beyond that point was fine but this commit in the middle is bad and you want to revert its effects. That is the case for the revert command because revert creates a new commit, actually, with the opposite changes. So if I deleted a line in that old commit, the Git revert commit will create a new commit that re-adds this line. This is the distinction between reset and revert. Could I shed a little bit of light on this?

Jen

Yes.

Tobias

Oh great.

Jen

Yeah. And I think, um. Yeah. [Tobias laughs] I don't know what... I mean, I'm having a hard time remembering just personally why it's so hard when I was doing everything on the command line several years ago. What's the --hard and...

Tobias

--keep. Yeah.

Jen

Yeah. So explain those extensions.

Tobias

These flags are for the reset command. So if you want to roll back to an older commit, you have a hard option, you have a keep option, you have a soft option, so there's lots of options. The main distinction between hard and let's say, keep, is if you say hard, the changes made in between are really, well, swept away. So you're having a clean working copy after that, no local changes, and you're at that old commit. If you use the keep option, the changes in between, let's say, the new changes containing these commits will be preserved and restored as local changes in your working copy. You will have all the stuff that happened afterwards but not committed anymore but as local changes. That's the main distinction. In most cases, I guess, you will want Git reset hard because that's the cleanest and the easiest way. But also, kind of destructive. Yeah.

Jen

Yeah. One kind of just... I mean, it's interesting, 'cause sometimes you just know. Maybe it's different for other people, but for me, the most common situation I find myself in, is one where I know I want whatever the thing is I'm trying to get rid of, to go away. [Both laugh] Like, there's no doubt it needs to go away. And I want to be able to kind of start over.

Tobias

You're one step further than me, in most cases, because I have a hard time figuring out what it is that has to go away.

Jen

Right. Well, that's a different show. [Both laugh] That's a different episode on how to find bugs in code. I think it's sometimes 'cause you don't know what you've done and you just want to, like, undo it all and just do the thing that you were trying to accomplish in the first place. You want to attempt to do it again from the beginning. I think it depends on what you're writing code for. I think there's some situations where that's a complete waste of time and if you've been working for four hours, you want to keep four hours of work and just, you know, alter 15 minutes of work. But sometimes, I think, maybe it depends on what kind of code you're writing, but you want to just get rid of those last four hours, have the experience as a human and the knowledge that you've gained doing it wrong. But then, you know, be able to just start fresh and write the code cleanly from the beginning the way you would have had you been wiser four hours prior.

Tobias

Yeah, yeah. That's also another case for branching, actually. You might even get away with, well, deleting that branch because it's cheap and easy and creating a new branch and starting from a different starting point, actually. That's another classic example of branching where it makes things easier.

Jen

Yeah, and you know, I think... it's vaguely coming back to me. The moments when I've really needed these commands the most have been when I've had merges go bad. I realized that merge... my attempt to do a merge to solve a merge conflict went really badly and I just want to not have that be around. [Both laugh] And go back to the beginning when I needed to solve the merge conflict and try again. So will you talk some about merge conflicts and what they are, why they're hard?

Tobias

Actually, let's start by saying, they're actually not hard. [Both laugh] That's the feeling that I want to leave you with. Conflicts are actually easy to understand. It's only in most cases, Git can merge, Git can integrate most stuff by itself. The cases where you have a conflict are rather rare. And the case is you and a colleague or you and yourself in another branch changed the exact same line in the exact same file. Actually, this shouldn't happen all that often. And if it does, you might want to talk a little bit more and see if it's really necessary that you're working on the same piece of code at the same time. This is something to talk about. When it comes to a merge conflict, the important thing to remember is, you can always start over. There is nothing lost. You can always play that game once more and see if you make it to the end. I guess that's the most important thing to remember. You can't mess up in that situation, actually. If you do, start over and re-do the merge, as you said. And then it's really just thinking about, you have two, in most cases, you have two versions of a file that clashed. Well, which version do you want to use? The left one, the right one, or is it a mixture that is necessary? That's really... there's no magic in that. It's looking at the files. It's looking at the solution. And it's, well, the only person that can say what is right is you or your colleague. This is actually programming again. You have to decide how the correct solution should look. That's a thing that Git can tell. I said, it's not magic, it's just, well, trying to figure out what is right. The last part is stating what is this right version or editing it until it's right. That's actually all.

Jen

Yeah, I think the thing that made merge conflicts so hard and so frightening is a lack of great tools several years ago. And understanding that there was some kind of... and also, really, not knowing what a merge conflict was. I mean, knowing that something crashed into something but I don't know what that is. And then, I'm supposed to tell it which one I want and I don't know how to know that 'cause I can't see anything and I don't know what to say in order to tell it, even if I could, even if I did know, right? So all of that has been solved and I think a lot of it has been solved by better tools. Part of it is understanding that, as you said, a merge conflict is where two lines have been changed separately but sort of at the same time and the computer's not smart enough to know which one it should use. In a normal situation, it overwrites the old one with the new one. But if there's two new ones, if there's one old one it's supposed to overwrite, and there's two new ones, it's like, "Well, which new one do you want me to use? You need to tell me." But then the tools. I mean, this is where back in the day, especially SVN days and stuff, I had a tool called DeltaWalker that was like, "[Trumpet noise] Get out DeltaWalker!" [Both laugh] I always thought of some opening of some TV show with, like, a cowboy or something. I don't know, or maybe a space robot or somebody marching into the rescue. 'Cause it would give you graphs. It would give me a visual, like you said, a left and a right and it'd show you, there's two new versions. This is one and this is one and there's a button that says, "Which one do you want?" and you can say, "That one, this one, that one, this one, this one, this one, that one." And then you can push the button at the bottom and then you're done. When there's a tool like that, it's not hard or frightening. And that's what I've been very excited about using Tower for most recently. It feels like you grab some kind of a GUI so that you can really see what's going on. And then it's really not that scary.

Tobias

Yeah, yeah. The point is visualization, I guess. Making things less abstract because I exactly know what you mean. When I started working with git, a merge conflict was scary as death. I never knew what was happening. That was the frightening part. As soon as I understood, well, it's two versions of a file that, well, I have to figure out. Do I want to use the left one or the right one? Or do I have to edit them to make the solution correct? There will not break anything if I do this or that? I just have to decide. Making this decision, this fact of the situation visual, is, I think, is half the way. Because people begin to lose their fear of the situation. That's all. Because the situation itself is not that difficult.

Jen

Well, I also think that the fear came from any of us who used CVS or SVN. [Laughs]

Tobias

Oh yes.

Jen

Because there was great reason to be very afraid. [Both laugh] You probably, it was probably going to end with a phone call to the dev ops people and maybe taking out the repo for the entire team.

Tobias

Shut down the computer and run, run, run, leave the country! Yes. [Jen laughs]

Jen

Like, maybe you were going to break everything and it was going to take two days to fix it. Maybe you were gonna wipe out your colleague's work and maybe...

Tobias

Lose your job, get homeless, and everything else. Just because of a merge conflict. That's... oh yeah. Absolutely. [Jen laughs]

Jen

You're going to lose your house. [Both laugh]

Tobias

If you're lucky.

Jen

It's gotten... it's not that bad now. Git it not nearly as punishing as those older systems. I think there's so many great tools out there today that it makes it much easier. And perhaps this is the one thing that a lot of people who do stay on the command line most of the time go ahead and grab another tool for, is merge conflicts. Because it's so much easier. I mean, I've opened up the text. You can open up the code file and it says in there, there's like a bracket bracket bracket bracket bracket bracket head bracket bracket bracket bracket. [Both laugh] And you're like, searching for these markers in the code that Git has dropped in there to say, "This is where there's a problem. We've surrounded the problem with this special robot code to show you where you need to..." And you can do it that way, but it's easier when you don't have to.

Tobias

Yeah, and understanding what this robot code - that's a nice term - what this robot code does, and that it's not magical. You can remove it, save the file, and say, "Well, that's my resolution." Or you can leave it in, even, and you have strange characters in your resolution. It's just a text file. Well, no magic. That's good to know.

Jen

So, ok. What's next? Oh, here's a question from Larry Garfield. "Tell people about git add -p. It's the best thing ever." What's git add -p?

Tobias

Yeah. Well, let's start with what git add is, actually. In Git you have to tell the system which changes you want to have in the next commit. Just because something was changed locally, doesn't mean it's in the next commit automatically. So this is great for making granular commits because that part is important because just cramming all your local changes that you have since a week into a commit is not useful version control. So keeping commits small and focused on a topic is important. That's the Git add thing. And git add -p is a way to make this even more granular. P is for patch. It's for smaller things. You can even add parts of a file to the next commit. You might have some changes at the top of the file that belong to one topic and at the bottom of the file you have another set of changes which belong to another topic. So if you're a good version control user, you'll make at least two commits with these different topics and with git add -p you can say, "I want that part of the file, that part of the changes, in my next commit." Commit. Go on. And after that, maybe modify the files some more or discard the changes or simply add the rest of the file to the next commit. So that is git add -p.

Jen

Nice. I do that a lot. Because I'll... [laughs] In fact, I actually, one time, I... I work a lot in Drupal, I work a lot in Drupal front-end development, writing a lot of CSS for themes for Drupal. And when I'm working by myself on my own projects, I have, in the past, tended to do things like, just make a commit that's like, everything from Thursday. [Both laugh] Or a bunch of changes. A bunch of changes. [Laughs]

Tobias

That's a very popular workflow, actually. The most popular, I guess. And it's understandable.

Jen

It's terrible! [Laughs]

Tobias

Yeah, but we're all used to that kind of workflow.

Jen

I know, it's so bad though, that the folks who... I'm a big fan of Pantheon and I host a lot of sites on Pantheon and it was so bad that, in fact, like, way back in the day when Pantheon was still new, one of the founders pinged me one day and he was like, "What's up with your commits?" [Both laugh] 'Cause I think I had asked about it. I was having a support problem and I asked the question and he looked at my commit log and he was like, "What?"

Tobias

I call that a wake up call. [Both laugh]

Jen

He shamed me into... [laughs] But now that I'm trying to do much better, you know, of course. [Coughs]

Tobias

Sure, sure.

Jen

You know, I'll have a CSS file that's maybe page.css or typography.css where all the typography for changes go. All the CSS for the typography goes. But I'm actually working on, you know, this particular thing and that particular thing. And it's really nice to be able to just go and clickity-click and, look at that, Git Tower GUI, and be like, "Ok, these lines," like, "I should have made a commit earlier and I didn't. I moved on to this other thing, so let me go back and cherry pick through and find the lines of code that belongs to that thing I was working on this morning and then I'll make a new commit with the stuff I'm working on this afternoon." Especially when I'm working by myself and I don't have tickets for all of this. I don't have user stories for all this stuff. So I'm not consciously moving from one user story to another user story or one task ticket to another task ticket. It's just sort of bubbling out of my chaotic brain.

Tobias

Yeah, that's natural. When you're working, you can't just reduce yourself to just one topic. You see another line of code that might be good to change in that context, too, so you branch out a bit and do this and that. Later when it comes to wrapping the stuff up in nice little packages, that's the point where you should get tidy and make small commits.

Jen

Yeah. So let me ask you about remote repositories. Because... so back with the SVN world. And I don't want to get into SVN too much, because I feel like SVN is over.

Tobias

Thank you. [Both laugh]

Jen

There was this model in which there was a, kind of a master robot, like headquarters where everything lived. And you, as a lowly human, were just gathering some of the code and some of that information on your local machine. You're making changes and then you were pushing those... that's not the right word, but you were, whatever, shoving those changes you made back to the robot headquarters. One of the beautiful things about Git is to just sort of wipe that model off the board. Where every instance of the repo is, in fact, a clone of robot headquarters. So if I've got a laptop and there's four other people with laptops and then there's, I don't know, the main computer in the office, and then there's the live web server, and there's the whatever, wherever we've decided to put this thing. Our remote backup in another country or something. We... all of those sort of equally important as all of the others. Any of them could get wiped out and any one of them could become the sort of new, official... and it seems like... new, official robot headquarters. It seems like there's a... even though all of them are equally important, there is a convention that has carried over where... I guess it's theoretically possible, say, for three developers to be working on a project together. It's not going to be on a live web server yet. Maybe it's not even a website. Maybe you're making a native application or something. It's a piece of software that you're writing. It could be where all three developers have laptops and they just push their changes to each other and there is no central place where everything's saved. But that may or may not work because... this is where my understanding starts to break down, and I want you to correct me if I'm wrong. It seems like if everyone closed their laptops at the same time, you know, or one person's awake and working and they're trying to shove their changes to everybody else but those guys are offline, and this person's over here and she hasn't gotten the changes because that person over there is offline still. It seems like there's a culture-way to work where there is a sort of central, remote repository where... that's always online. Just for the sake of it always being online. And it's, I don't know, the main backup or something. Or it's the main place where it lives. And that's where people use things like BitBucket or GitHub or set up their own servers to be that place. So will you talk a bit about the remote repository situation? What works or doesn't work as a remote repository? And this idea that you don't necessarily need it? Or maybe you could have more than one. Like, you could put it on GitHub and on Pantheon and on BitBucket and on a backup server of your own choosing. I think. Is that right?

Tobias

Yeah, that's absolutely right. I would have interrupted you. No, everything is correct. The main thing with remote repositories is, it's a means of exchange. You need a place, a central place, to collaborate. That hasn't changed from the Subversion days, actually. But the thing with Git and other... that's a decentralized part of a distributed version control system like Git or like Mercurial, is you're not depending upon such a remote repository. You're completely independent of any remote repository. You can do, I guess, 95% of work offline on your own computer. So if you don't have a connection, if you're in the train or something, you can commit, you can add stages, add changes to the staging area, you can even look at the project's history because what you have with a clone, with a local version of a remote repository, is a full-blown repository. There is no more first-class and second-class repository thinking because they're the same, actually. The only thing that's different between the remote repository and a local one is you have working files on the local one. That is all that there is to it. The objects are exactly the same. It's just that in local case, you have a working copy of working files, and in a remote repository, you don't. You just have the Git repository, just the Git database, let's say it like that.

Jen

What do you mean by working files? I don't know what that means. What do you mean?

Tobias

Your project files, actually.

Jen

You mean files that you're editing? Your changing files?

Tobias

Yeah, yeah, yeah, your actual files that you're working on. So if you're having a web project, those CSS, HTML and PHP files lying there. Inside of that project folder, you have one little hidden .git folder and this .git folder is actually your local repository. Inside of that, this is the place where the magic happens and this is also, this could be a remote repository. Your HTML, PHP and other files are your working files and that little .git folder is a repository.

Jen

Are you saying on the remote, that the remote only keeps the .git folder and then it doesn't have the other...?

Tobias

Yes, yes, absolutely.

Jen

But why? What's up with that? Wait, I didn't know... I never knew that. So if I somehow, you know, SSH'd in to a remote repository server and looked at it, you would see the .git file, which contains all of the information to be able to create these files and roll them back in history and such. But the actual files themselves wouldn't... you wouldn't see them sitting there in the file system?

Tobias

Absolutely correct, yes. That's why remote repositories are sometimes called "bare repository" because they lack a working copy. That's the reason. So, yeah, you only have those versions in that kind of database and could, well, you use it to exchange files. If I upload a version, if I push some new commits to that remote repository, the remote repository receives the changes and saves the new commits, but there's no use in having a working, the name it, a working copy. Because no one should work on the remote server.

Jen

Yes, please.

Tobias

Mmm hmm. [Jen laughs] Don't FTP into that server and change things.

Jen

Drives me crazy when there's someone on the team who does exactly that. They FTP, or more commonly they SSH into a remote something or other. Maybe not the... I guess it's not the remote Git.

Tobias

Well, it's so comfortable, but yeah. No.

Jen

They SSH into the dev server, they edit files on the dev server, and then they don't put them into Git.

Tobias

Mmm.

Jen

So that when you go to pull, you're not pulling their changes and you can't figure out why the dev server doesn't match your local server. Oh, it's because they edited files on the dev. [Whispers] Don't do that. I'm going to come haunt you.

Tobias

Those are the colleagues that don't live long.

Jen

Man, those are the... oh, man. Ugh. Having flashbacks. [Tobias laughs] So a dev server... say you're working on a website. A dev server, a testing server, a staging server, a live server, they all have working copies of files because they're running... you can go to the URL and you can see the web server running, right? So you've got those files. But a remote server is different in that those files have been told to not be there? To go away?

Tobias

Yeah. Actually, even in the case of the dev and production server, you strictly don't have a working copy in the version control sense. What you should have is a mechanism, a deployment mechanism, that checks out, that gets files from the repository and puts them into your... wherever you want them to have. But this should really be separate. This is a place where people mix up version control and deployment and these should really be kept separate. One thing you could use to make that happen is hooks. Hook scripts in Git allow you to do something when something else happens. For example, let a script run that gets the latest version from the repository and puts it, copies it to your web server location when a push happens. When somebody performs an upload. This is really a deployment workflow. This should be kept separate from version control.

Jen

Yeah. Yeah. When you've got people who have the skills to do that. Or when you have a big enough project that it's worth doing, taking that extra effort, I think, in my opinion. And sometimes I feel like with smaller projects, it's a layer of complexity that's not necessarily needed.

Tobias

I feel it's still too complicated. I feel it's still like version control was five, five to 10 years ago. I think this should change and I guess it will. Well, who knows.

Jen

Yeah, yeah, deployment's a whole other... something. I don't know what the word is.

Tobias

[Laughs] Something.

Jen

It's just, it's crazy how complicated websites have gotten. It just really is. Even that you have a development server and a test server separate from your live server. Even on smaller projects.

Tobias

Yeah, historically that's pretty new, actually.

Jen

Yeah it is.

Tobias

We just stopped hunting deer in the forest and now we're having development and live servers. [Jen laughs] It's crazy.

Jen

Right, that's true. We were just hunting deer in the forest two generations ago. What happened?

Tobias

[Laughs] And now there's live and development servers.

Jen

Yeah. Alright, let me jump in here with our other sponsor. Then I'm going to ask you about sub-modules. So get ready. [Laughs]

Tobias

Oh, I'm gone, I think. [Both laugh]

Jen

So, sub-modules. Sub-modules seem cool. But hard.

Tobias

[Laughs] Both correct.

Jen

I want to explain what's cool about them and I want to understand why they're hard.

Tobias

Right. [Laughs] The cool part is probably easier. If you have, well, some kind of library that you want to include in a project, you have a couple of options. One is, copy the library code and commit it to your project. And the problem with that, well, many. Because you can't stay up to date with the library. If the library advances, say you have, don't know, a carousel for your image gallery or something and you copy the code into the project. Anytime the original developer fixes a bug or adds a feature, you're in trouble because you have to find the new files, again copy them into the project, well, that's tedious and error-prone, especially in bigger projects where it gets more complicated. Sub-modules are a means to include other Git repositories into your main Git repository project. This keeps it nice and easy. You can use all the Git stuff in those sub-projects, in those sub-repositories, too, so you can fetch and pull changes and say which exact version of that sub-project you want to use in your project. That's the reason why sub-modules are cool.

Jen

Yeah, I... I mean, like, so, yes. We all know what libraries are anyway. But yesterday, there's a jQuery plugin called Chosen which is kind of awesome. With the new website I'm building, there's lots of places where it's like, "Oh, you're adding a guest to the website. Well, which episode of The Web Ahead did that guest appear on?" There's a list of 78 shows, now about to be 79 shows, right? So is that a little, do you have to scroll in a little tiny box to find the right show? Or do I have a giant list of checkboxes that takes up five inches of the screen? This is a little jQuery plugin that kind of turns that select list into a much, much better thing. Like it just makes it way easier to use it, right? Who knows, there could be a bug, or when the new version of jQuery comes out maybe something breaks or maybe there's some kind of a something, they realized, "Oh, we could write this better, let's re-write the code." I'm probably not gonna know about that. I'm probably not gonna bother to go back and check every six months to see whether or not this plugin has been updated. And maybe I don't need the changes but... the other use case, the real use cases that I totally want to use it for, sub-modules, is, again, with Drupal, you create a theme, but you can also have parent themes. And so I want to have sort of the Jen-Simmons-thinks-Drupal-should-be-done-like-this parent theme that I use across a whole bunch of different websites. Where I can add in all this code that kind of wrangles Drupal and changes things that I always want to change on every single project. And then have a child theme of that and have the child theme be, like, ok, the theme for this particular project with the look and the feel and the typography and the specific CSS for this website. And then I want to be able to make changes to that sort of Jen-Simmons-master-theme and pull it in five different websites all at once automatically. Instead of having to copy and paste the changes, you know? And be like, "Oh, right, ok, well, I changed it over here. And then this site I haven't worked on in a couple months, I should copy those changes from that one over to this one. And, wait, where's the... oh, I just totally fixed this bug already, where's the... which repo, which project is that in? Oh, it's in that one." That's what I'm doing right now, is manually moving all that stuff around when I'd like to use Git for that and to have one Git repo that has my master theme in it and then pull that repo and put that into the repos of all these other projects that are the Drupal projects with the Drupal codebase and all the modules and the themes and everything. But I'm not able to do that because there's no sub-module support on my dev live testing server platform. And the reason there's no support is because apparently it's also very dangerous and very hard. How is it that you can really create a black hole in the universe with sub-modules and explode everything? [Both laugh]

Tobias

Let's say sub-modules are a little bit touchy. I would say. [Jen laughs] It's true that managing them is not really easy. I can't tell you a concrete reason, it's just a bit complex. Initializing them is easy, but then managing them and keeping them up to date and on the right version and if new changes drop in, that's not exactly easy. To be honest, I wouldn't know how to do it on the command line. No chance. I would have to learn this, too. That's actually where I need, desperately need, a visualization in a desktop GUI like Tower. I'm lost without that. So, yeah, they're touchy. And I think you really need to need them to justify using them. There are a couple of cases but if you can get away without sub-modules, that's fine. Just because you could use them, doesn't mean you don't have to. But anytime you're reusing code, so the examples you made are exactly cases for sub-modules. If you want to reuse code or include code from a third party, that's probably calling for sub-modules.

Jen

Yeah. And there's something about third party code that maybe you don't necessary want to update it. But there is definitely something about your own reused code that it feels like, you know, there's an efficiency there. Having some sort of version control across projects would really help. But, yeah, I mean, that's another reason that I do like using Tower or advocate for GUIs in general, is that... well, not all of them. But most of them. The good ones and Tower is definitely, this is true of Tower, like, it lets me try things that are more dangerous and edgy and maybe require a certain level of Git mastery that I don't actually have. It lets me try them because I have faith that the tool is going to keep me from doing something dumb that I can't... things like, I want to push but I didn't commit things yet. Or I go to pull but I haven't... you know, simple stuff like that. It just reinforces the proper workflow in a way that the command line is a little bit more, "Sure! You want to do that? I'll do that for you." [Both laugh] It's a little bit more of a babysitter and it's a little bit more like, "Eh, you probably don't really want to do those four things in that order. That's not going to work out. You need to... here, let me show you a graph of what you're trying to do. That's not a good idea."

Tobias

Take off the helmet, it's not necessary.

Jen

It feels that way, but it feels like it's really, it helps keep you from doing something stupid. Which is why I got all excited about sub-modules, like, I don't know, a couple years ago when I heard about them for the first time. I was like, "No! Let me use them! I know I won't do anything wrong, 'cause I'm using these super powers that are protecting me from being stupid." I don't know if that's true or not, but I felt that way. But I couldn't use them anyway.

Tobias

That's probably good to know that I even I have to use in that use, is a GUI and Tower, because, well, I'm half a developer or a third a developer and some stuff is just too complicated for me. I know where to keep my hands off the command line and what I can do on the command line and for some things I just need, desperately need visual aide, and sub-modules are one of those topics where it gets easier. Sub-modules are one topic that is not... I could be hanged for saying this... it could be better in Git. It could be better implemented. It's really a bit complex and, yeah, we're trying to make that smoother in Tower. That's our mission, if you want.

Jen

What's another thing about Git that a lot of people don't use but is there and it's powerful and kind of awesome if you're up for the challenge?

Tobias

I suspect that stashing is not that common. Or if you're starting out with Git and coming from Subversion, the stash is a completely new concept. Essentially it's a clipboard for local changes. Imagine you're working on some stuff and a bug report comes in and you have local changes that you don't need at that time. You need a clean working copy to, well, create a new branch for the bug fix or switch to another branch or roll back even and undo things. But you don't want to lose your local changes currently. So the stash is something you just use to take those changes and put them on that kind of clipboard. That's pretty new to most people. And, I guess, the topic that Gregory, was it, that asked git add -p? I don't remember.

Jen

Oh, Larry Garfield, yeah.

Tobias

Oh, sorry. Yeah, Larry. So staging parts of a file, even single lines or chunks or hunks, that is special to git, too. And, well, after some time you really can see the value in that. At first it might be overkill but it definitely is a great thing to do.

Jen

I guess most of what people could do to get better at Git is get better at the human side of it. The culture of making good commits, using branches, organizing things nice and clean and neatly. Writing good commit messages.

Tobias

Yeah, that's also the possibility for people to... and I really mean that, to become better developers. I really notice this with myself. I became a better developer by using Git. I made commits that made sense and that made things easier for the team, that made things easier to understand, even later. These are all things that really help a development process. Git itself, or version control, is not a reason for using itself. It has to bring value and that is, in my opinion, it's more quality and, well, growing as a developer.

Jen

I was watching some, you know, cooking reality TV show lately. Or maybe it was a documentary, actually, about professional chefs. They were talking about how, like, a really great professional chef will run a kitchen in a certain sort of way. Where things are very well-organized and very clean and when they prepare the food, they're spending two hours in the afternoon chopping up vegetables and such and putting things, that they'll... there's a certain kind of... a great, a well-run kitchen will frequently be extremely organized. Where the salt and pepper is always in the top right corner of the table and the vegetables are all lined up in this very particular order and they get lined up that exact same way, day after day. And that the person working on the fish station or whatever, has, like, their tools are set up in this particular way and that they'll get a ticket and they'll cook that table's dinner and then they'll clean and then they'll set up for the next ticket. Very quickly, I mean, extremely quickly. But that there's something about the art of being organized and being clean and being, just, it's... I mean, people call it anal retentive for something, but there's just this way of being, of holding up that kind of organization as important to the quality of the outcome and as part of what it means to be a professional what of what it means to be a master at that particular craft.

Tobias

Yeah, yeah, absolutely.

Jen

And I feel like there's a way in which that applies to being a developer, as well. Between Git and the way you organize things in Git and branches and the commit messages and, also, the way that a team runs its tickets. That having really well-written user stories and a very strong discipline around tasks always being part of user stories and that you don't have these extra tasks floating around and that you only work on the stories that are in the current sprint and that your bugs are actually really bugs, they're not sort of secret feature requests.

Tobias

Yeah, yeah. Keeping the chef image for just a second, it's not about, it's not only about the cooking. It's the tools and the workflow around that make it efficient and good in the end. Agreed.

Jen

Sharp knives and a clean table and really nice quality vegetables.

Tobias

Just like with developing, yeah. Good vegetables.

Jen

No more Cheetos. [Tobias laughs] Soda and pizza. So, oh! And you also have... let's tell people about the Learn Version Control with Git Step-by-Step Course for the Complete Beginner.

Tobias

Yeah, yeah, yeah. We made a... well, we're pretty close to people learning version control, as you might imagine. We noticed there's a lack of documentation or of learning resources for not so technical people. If you have a master's degree in information science, there's lots of books for you. But if you want to start as a designer or a web designer or a project manager and get our head around Git and version control, there's hardly any learning resource for you. We started with that in mind and created a free online platform with an eBook for these people. So, for people who start out with version control, and especially with version control with git, and take them from, not A-Z but A-P, actually, I guess. From beginner to intermediate, take things slowly and really start at the beginning and show those things that are really necessary for a beginner to understand.

Jen

Nice. And so there's an eBook that people can read online for free, right? Or they can buy an eBook that also comes with the tutorial video that goes... like, that you can read on a Kindle or an iPad.

Tobias

Absolutely. You don't have to spend a dime to get started with Git. You can get that eBook with the video but not necessarily. So you can learn for free on git-tower.com/learn.

Jen

Nice. And then you have a video course coming out soon?

Tobias

Yes. Well, soon is a matter of definition. [Jen laughs] I'm working on it. That's probably good to know and good to say. We're working on it. We want to make it a great video course so taking small steps in each video and a couple of videos, not just a two hour series, but something small that takes people from step to step. That's coming out soon.

Jen

Nice. And if people want to learn more about Tower, they can go to git-tower.com.

Tobias

Absolutely.

Jen

And check it out. And you just came out with version 2. What do you think are the biggest differences between version 1 and version 2?

Tobias

Well, we smoothed out the sharp edges in version 2. We really wanted to focus on making things easier, on making workflows easier for people. Features, of course, you have to have a lot of new features in a major upgrade. That's a case. But the important thing for us was really to make Git easier than with version 1 and already there, this was our motto that we lived up to. Just as an example, we introduced a merge conflict wizard. I think we're the first application that features a visual way to deal with merge conflicts. That's typical, I guess, for the software, or for our thinking. Another thing is we integrated with the big code service, the code platforms, like GitHub, BitBucket that you had a sponsor, and Beanstalk. We're really making it easy. Cloning a repository is just another click away. So you don't have to fumble with passwords and usernames and authentication tokens and OTP codes. There's so much stuff in that space.

Jen

Yeah, I used to always open up the command line to clone the repo and then once it was open, once it was cloned, then I would switch over to Tower. And now it looks like you can just do that right inside Tower. Yeah, and the merge conflict stuff, too. It's so nice to have it baked right in to this tool. Because I used to open, like I said, I'd open a different tool to do the merge conflict stuff and now it's just all in one place. I've noticed it's faster. It just seems to be much faster.

Tobias

Oh, definitely. Yeah.

Jen

The... what was the other thing? Oh! I can pull without having... like, normally, and I think the rule with Git is, in order to pull changes from the remote server, you have to have all your local changes already committed. And if you've got uncommitted local files, then you've got to stash them so you can pull and then unstash them and push. The other day, I just wasn't even paying attention and it was like, I was ready to push some changes but I also had already... like, I probably made a change, made a commit, thought I pushed it, didn't, made some more changes to the code, went to the dev server, realized that I hadn't pushed the changes that I needed to push. I went to push but I couldn't because I needed to pull, so I pulled, and I was like, "Oh my god, I just pulled with uncommitted files just hanging out." [Both laugh] Some magic thing. Like they got stashed secretly and then unstashed quickly and I was like, "Awwwwesome!" [Both laugh] Little things that I used to trip over. It's like, I totally broke all the rules on how you're supposed to do Git and I don't care because it's fine.

Tobias

You're getting away with that, yeah. That's the stuff we want to make easier. Another example is, in version 1 and in other tools, you have to explicitly tell Git to download new changes from a remote server. You never know when there are new changes. With version 2 we do this automatically for you in the background and even tell you if there are new commits for a certain branch, or if you're behind or ahead. If you have commits that you haven't pushed yet. This is the stuff that we want to help people with and make, well, make the damn thing easier, I guess is the thing.

Jen

Yeah, and in a way, you're adding a layer of extra better design, user experience on top of Git. Git has these stumbling blocks and you're actually ironing those out. Like, it's not just that you're taking the awesome stuff about Git and making it easier. You're, like, fixing the broken stuff about Git in a way that is not necessarily true of other tools.

Tobias

Yeah, I like to think of this like that, too. [Laughs]

Jen

So, anyway, I love this thing, and people should go check it out. They can follow you on Twitter. What's your Twitter handle?

Tobias

Let's take @gittower as the Twitter handle because there's more life on that channel. My personal is @gntr, G-N-T-R, but as I said, it's more exciting to follow @gittower. [Laughs]

Jen

Cool. Well, I'll put both of those links and all of the other links, including the codes for the sponsors and the links to sponsors and all the links to all the stuff we've been talking about today, in the show notes for the show. Which will be at 5by5.tv/webahead/79 and they will also, in the future, be on, I think the domain... I think we're going with - and this is it, this is the first public announcement, so if you listen to the end of this episode, you get to know this when other people don't know this - thewebahead.net/79. I have a couple domains and I'm sort of debating a little bit back and forth which one. I can't get any of the dot coms. Shucks. But I think I'm going with thewebahead.net/79. If you have opinions about that, you can totally ping me on Twitter, or again, you can jump into the group that's helping make this. These questions are questions sometimes I ask of this group, which is at github.com/jensimmons/thewebahead/issues. Talking about, like, what's the best URL? And what do you think of this or that. Kind of a beta test group for the new site. So, that's it for this week. Thanks for listening and tune in next week.