BRAD: Welcome to Apply Filters, the podcast all about WordPress development. I’m your host, Brad Touesnard, and joining me, as usual, is my cohost, Pippin Williamson.

PIPPIN: Hey, everybody.

BRAD: Today, we are going to be talking all about Git, and branches, and pull requests, and all that good stuff.

PIPPIN: Sure thing, so a quick introduction to Git. For anybody who is not aware, Git is a version control system that allows you to track changes to your code base and manage those changes in a mostly sane manner. It is a tool that, if you’re not familiar with it, you should absolutely go learn it. You may be familiar with something like SVN or other version control systems that are kind of similar. But I think every serious developer should absolutely be learning version control. And, personally, I think you should be learning Git —

BRAD: Yeah.

PIPPIN: — because Git is pretty awesome.

BRAD: Anyone that’s been around for a while, like developing for, you know, ten-plus years, you’re probably familiar with CVS, and then SVN was kind of the successor to CVS. You know SourceForce, like the big repo (repository)?

PIPPIN: Yes.

BRAD: I think they started on CVS and then switched to SVN at some point.

PIPPIN: That’s cool.

BRAD: And I’ve even used Visual SourceSafe, which is a Microsoft product.

PIPPIN: That’s one I have never used. Granted, I don’t tend to use any of the Microsoft programming tools.

BRAD: Yeah. And then there’s another one I’ve used: Perforce. It’s pretty big with kind of like enterprise stuff.

PIPPIN: I’ve heard of that one.

BRAD: Yeah, they’ve been around for quite a while.

PIPPIN: Cool.

BRAD: But Git is the new kid on the block, and it is awesome.

PIPPIN: Yeah. For anybody, if you’re not familiar with Git, go to GitHub. Basically GitHub, which you’ve probably heard of, is like a social code repository, and it is all based on Git. So if you do anything in GitHub, you’re working in Git. So even if you’re not super familiar with version control or interested in version control, being able to use GitHub is a pretty darn good reason to learn it because GitHub is awesome.

There’s a couple of things that we want to talk about with Git and managing your projects, and those are learning how to manage branches, so using Git branches for release management, bug fixes, new features et cetera. I’m going to tell you a little bit about my work flow, and then, Brad, if you want to weigh in.

BRAD: Sure.

PIPPIN: So when I build a new version, let’s just use Easy Digital Downloads for this example. I do everything in branches, and my whole team does everything in branches. Right now we’re getting ready to push out a new release for Easy Digital Downloads Version 1.9. This release has been in development for the last six months, five months, three months, whatever, however long we’ve been working on it. And so we’re been building everything in a branch. And so we call it Release 1.9 is the name of our branch.

And so we do everything in this branch, and by having this in a separate branch, we can actually do development on another version, or do minor bug fixes to the current version simultaneously. So we have all of our code for 1.9 in this branch. We have all of our code for 2.0 in another branch. And then we have a code for — let’s say we have a quick security fall that we need to push out an update for, we have our latest stable code in another branch.

And then, if we have a new feature that we’re introducing, we’ll create what’s called a feature branch, and so we’ll have this branch called “features/view order details” or something like that. And we’ll do all of our coding in that feature branch for that new particular feature. And while we’re doing that, any development that’s going on to fix other bugs, or other unrelated features is happening in different branches. So all of our development is happening simultaneously, but independent from one another.

BRAD: Right. So that feature branch, when it’s, like say you’ve gotten it to a point where you’re like, “You know what? I think it’s ready. I think it could go in the next release,” do you then merge that into the release branch for testing?

PIPPIN: Yes.

BRAD: Okay.

PIPPIN: Yes. So we’ll have our release. We’ll just call it Release 1.9, and then we have a feature branch called “view order details”. As soon as “view order details” is complete, we’ll merge it into Release 1.9. At any given time, in the EDD workflow, we have at least three branches. We have our master branch, which is considered the latest stable version. Basically that’s the version that everyone out in the world is using right now, plus maybe a couple minor bug fixes.

BRAD: Right.

PIPPIN: We then have the next major release, so Release 1.9, and then we have a feature branch. So the feature branch gets completed; it gets merged into 1.9.

BRAD: Right.

PIPPIN: As soon as 1.9 is ready to go out, it gets merged into master and gets pushed out.

BRAD: Right. So I’m going to guess that the reason that you use a feature branch, instead of just working right in the 1.9 branch, is because: what if that 1.9 is ready to go, but you haven’t finished the feature yet? Maybe the feature needs to go in 1.9.1 or something else.

PIPPIN: Yeah, that’s a huge reason. We have features that — there was an API that I was working on. It was going to be a webhook API. So if you’re familiar with Stripe or PayPal, or any other payment system, you know that they have these things called webhooks. Basically, when something happens, they send a remote http request to a URL with a payload, some postdata. And so we were going to build the same kind of API. So any time something happens with a payment — let’s say a payment is completed, a payment is refunded, or something like that — we could send a webhook to some URL. So I was building an API to do that, and I was planning to release it with 1.9.

I got about half way through the feature and then realized I’m not going to do this. I decided to not do it.

BRAD: Right.

PIPPIN: At least not at that time. So if I had been building that directly into our 1.9 branch, that would have been a real pain in the ass to rip it out.

BRAD: Yeah.

PIPPIN: But because I had it in a feature branch, I could literally just let it sit there and nothing’s wrong.

BRAD: Yeah. Yeah, I mean you’ve pretty much described the exact same system that we were using in our development.

PIPPIN: Cool.

BRAD: So it’s good to know that other people are working the same way.

PIPPIN: Has it worked out well for you?

BRAD: To be honest, we’ve kind of just settled on this now. We were doing some other things previously. We were just kind of using — we would do branches and then pull requests. So it was a similar system, but now we’re not using pull requests any more. So what we would do —

PIPPIN: So when you say pull requests, do you mean for people, third party developers to submit patches, or do you mean for your own internal development…?

BRAD: Own internal development. So any time I had done, basically a set of commits, any set of commits, even if it was just one commit, I would open a pull request and assign it to another developer in the team.

PIPPIN: So that someone else reviews it.

BRAD: And someone else would review it, and then they would merge it and, you know, fold it into kind of the main branch.

PIPPIN: Sure.

BRAD: But what we’ve realized is that it’s kind of excessive because, every time you a create a pull request, it creates like another, basically another GitHub issue with its own set of comments.

PIPPIN: Right.

BRAD: And so you have this kind of parallelism going on where you have an issue in your issue tracker, that describes the issue —

PIPPIN: And then you have a pull request that also describes the issue.

BRAD: Exactly. And then your conversation is fragmented between the two. So we decided just to use issues and just better communication within the issues.

PIPPIN: Yeah, we have the same issue with EDD development. So I don’t ever do pull requests for code changes. I used to. I used to do the same thing that you do, basically, at least for major changes. But some of the other developers will still do pull request. Most of the time it’s because they don’t have full commit access to the repository, or because they’re not sure if something should go in as-is yet. So they’ll submit a pull request. And it does create that fragmentation, and it can be a little irritating, or confusing, or any other adjective.

BRAD: Mm-hmm, yeah.

PIPPIN: So I definitely get that.

BRAD: Yeah.

PIPPIN: It’s also, if you think about it, if your developer, whether it’s you and one other person or you and ten other people, if you all have access to read and write to the repository, like there’s really no reason for pull requests for code review because you can still test it inside of its original branch.

BRAD: Yeah, exactly. Yeah.

PIPPIN: There’s no reason it has to be in a pull request by any means.

BRAD: Yeah, exactly, and that’s what we realized is that the pull request was just adding unnecessary overhead and management that we didn’t need. So we’re just using, you know, GitHub issues, and we’ll just like, you know, use an @, like I’d go @pippin to reference you in a comment and ask you to review it.

PIPPIN: Say, “Review my code. Tell me what I broke.”

BRAD: Exactly. Exactly. So, yeah, it works quite well. So I think we’ve kind of

PIPPIN: I think another, for anybody who’s not yet familiar with branches, or you’re not sure if you should use them, I want to give you a scenario that I ran into a couple of time before I started avidly using branches for everything. I mean, I will use branches for every single piece of development I do now. Aside from, like, minor bug fixes, even if it’s a little, tiny feature, I will use a feature branch for it. And it’s because I had an issue one time, or not just one time, this definitely happened at least four or five times.

I had a new version that I was ready to push out or getting close to being ready to push out. And then I realized, oh, this feature is not complete, but this feature is in my code base already. I can’t push out a not-ready-to-go feature, but I also can’t rip it out very easily. So you’re kind of stuck with: do you delay a release for, say, five days, two weeks, whatever to finish the feature, or do you work to backtrack and take it out? And if you have everything in feature branches and release branches, that problem goes away completely.

The other issue, and this is something that I ran into the other day, is let’s say that you’re working on a new release, and so you’ve got a whole bunch of new features you’ve put in. You’ve got bug fixes, et cetera. And then, all of a sudden, you have a major bug report, something that has to go out today or tomorrow. You have to fix it. It’s an urgent fix.

Well, your release is two weeks away, so do you ignore that urgent bug and wait two weeks, or do you go and push out a fix? Well, hopefully you push out a fix right away. But if you have your not-ready-to-go code yet in your main branch, and you don’t have a way to separate it, you’re kind of stuck.

BRAD: Mm-hmm, yeah. I mean that’s exactly the kind of issue we’re trying to solve as well. So the policy — I wrote a document and shared it with the team to say, you know, like, “This is the policy.” And what I’ve said is, “You have to be absolutely certain that this is going in this release if you’re going to merge it into that release branch. You have to be completely confident that it’s going in,” because otherwise you’re just wasting time because, if we have to rip it out, it’s a huge pain. Right?

PIPPIN: Absolutely.

BRAD: And a bunch of time that we don’t need to waste. So, yeah, it’s really interesting that we’re both — we’ve never talked about this before and we’re using the same methodology.

PIPPIN: Well, I think it’s a methodology that a lot of people use, and it’s one that has become more tried and true. I definitely didn’t come up with it on my own. I know there are a couple of people that influenced my decision to move to that method. And when I first did, I was actually against it because I decided it was more complicated and was unnecessary. And now that I’ve been using it for six to eight months, there’s no way I’d ever go back.

BRAD: Did you — I mean, you came from an SVN background, right, subversion?

PIPPIN: Kind of. I learned version control — my first introduction to version control was SVN.

BRAD: Right.

PIPPIN: But I really learned version control with Git. The only thing that I did with SVN was simply committing plugins to the repository, which, if you’ve ever done that, you know that you don’t necessarily truly need to understand SVN to submit a plugin to the repository.

BRAD: Right.

PIPPIN: All you need to know is how to follow the guide to make a commit.

BRAD: Right. It’s funny though because SVN, you know, you kind of shy away from branching in SVN because it’s hard.

PIPPIN: Right.

BRAD: It’s a real — and painful. It can be very painful. But with Git, it’s —

PIPPIN: I’ve never even tried.

BRAD: — you know, you see this, you know, if you read a few articles on Git, it’s rare that you wouldn’t see the phrase, “Branches are cheap with Git,” because they are. You create them. You merge them. You delete them like all day long. Right? And it’s not hard, and it’s not painful like it has been in the past with other version control systems. So yeah, I think probably a lot of people could probably use branches a little bit better if they’ve come from a previous system.

PIPPIN: Certainly. With branches, do you want to talk a little bit about merging? Merging is something that I think can definitely discourage a lot of people because sometimes merging can be hard.

BRAD: Yeah.

PIPPIN: Like resolving merge conflicts. The first time that I saw a merge conflict, I kind of like threw up my arms like, oh, I have no clue what to do.

BRAD: Yeah.

PIPPIN: How do I fix this?

BRAD: Yeah.

PIPPIN: What are your experiences with merging feature branches and release branches and things like that?

BRAD: Yeah, I mean —

PIPPIN: Do you have any certain methodology for how you do it to ensure that it has a good merge?

BRAD: Yeah, so I use a visual tool. I don’t know why, but I find editing, like the kind of, just the text file, and like trying to figure out stuff that way, I find a lot more difficult than using just a visual. So, I don’t know if you’ve ever used this. There’s an app called Versions App.

PIPPIN: I haven’t used it. I’ve seen it though. I used to use one called….

BRAD: Oh, sorry, not — yeah, not Version. It’s Kaleidoscope I’m thinking of.

PIPPIN: Oh, no. I’ve never used Kaleidoscope.

BRAD: I think they’re made by the same company. Anyhow, Kaleidoscope is a diff tool and a visual merge tool. So it allows you to, you know, see the changes between the two files, and also see exactly what the conflicts are, and just simply choose which one you want from the left or the right.

PIPPIN: That’s cool. That’s definitely easier than managing it through a text editor.

BRAD: Oh, yeah. I find, especially if you end up with kind of a hairy merge, or one that’s complicated, I find the diff tool is essential because it could save you a lot of time.

PIPPIN: Sure. So do you have a certain methodology for merging branches that helps avoid conflicts? I got one put together — and by methodology, I just mean like a certain way that you —

BRAD: Yes.

PIPPIN: — do your merges when you merge, et cetera. And so what did you do?

BRAD: Well, usually we — I always say you should keep your branch, like if you’re working on a feature branch that was based on a certain release, so say — let’s use concrete examples.

So say we’ve got a Release 1.9 branch, and feature X branch, and I’ve created the feature X branch using the Release 1.9. But I’m working on feature X. And then, while I’m working on it, you know, people are adding bug fixes, et cetera, to Release 1.9, and probably folding in other code into it. While that’s happening, I should always be updating my feature X branch, merging from 1.9 into feature X to keep it as up to date as possible while I’m developing feature X.

PIPPIN: Great. That is exactly the same thing that I do.

BRAD: Yeah. And that really prevents conflicts. I think, if you don’t do that, you’re going to end up with conflicts. Every once in a while, you might end up with a conflict, but it will just be a small one, right?

PIPPIN: Sure.

BRAD: Instead of massive.

PIPPIN: I know, when I first started doing feature branches, I didn’t realize that I needed to be updating my feature and release branches consistently. And I remember I tried to merge in a feature that had been in development for like two or three months. And it just, like, died totally. I broke down in tears practically. It just was like, no, there’s no way this is going to merge in.

But then, once I realized that if you keep the feature branch or the release branch up to date with whatever you’re going to merge it into, it’ll merge cleanly almost every single time at the end.

BRAD: Right.

PIPPIN: And so then the only conflicts that you end up having to take care of is when — let’s say that you’re merging master into Release 1.9 to get Release 1.9 up to date. Generally, you’ll only have really, really small conflicts because there have been very minimal changes. So then you get those minimal conflicts taken care of, so then when you merge the 10,000-line Release 1.9 into master, all of those work perfectly.

BRAD: Exactly. They’re already resolved; you’ve already dealt with them.

PIPPIN: Right.

BRAD: Yeah, definitely.

PIPPIN: Yeah. I found it to work really, really well.

BRAD: Cool.

PIPPIN: What about tagging? Or do we want to–? How about, before we go to tagging, you know, take a quick break. I guess we forgot to talk about what we’ve been working on.

BRAD: Yeah, sure thing. I just launched the affiliate program, so I was working on that for Migrate —

PIPPIN: For WP Migrate DB Pro?

BRAD: Yeah.

PIPPIN: Awesome.

BRAD: Yeah, I was working on that a little bit. But, you know, I haven’t been doing a ton of work over the break. I’ve tried to, you know, keep it light. Just today though I started, you know, doing a little bit of learning because I feel like I haven’t been learning very much, and I’ve just been looking at Backbone.js. And I was looking at the Slim framework. I was looking at all kinds of stuff. Have you heard of Render? It’s a Node.js, Backbone.js kind of framework that Airbnb has released has released recently.

PIPPIN: Sounds cool.

BRAD: It’s very cool because it allows you to use Backbone on the server side, as well as the client side, so you don’t have to duplicate all your views. So it allows Node.js to serve up like a full Web page, like a fully rendered Web page.

PIPPIN: That’s cool

BRAD: Which you couldn’t do before. I don’t know if you noticed this, but you know on Twitter, like when you load a Twitter page, it kind of jumps?

PIPPIN: Mm-hmm.

BRAD: Like it loads all the stuff, like all the assets, and then it loads the interface. Well, it kind of takes care of that kind of a problem.

PIPPIN: Nice.

BRAD: So it’s — yeah, it’s really cool.

PIPPIN: I always love learning about new tools or libraries, whatever they are.

BRAD: Yeah.

PIPPIN: It’s a nice break. Even if you don’t end up using them, just being able to play with something new that is perhaps completely unrelated to, like, your day-to-day work, it’s really refreshing.

BRAD: Yeah, totally. I like learning about that stuff, but I often don’t play with it too much because —

PIPPIN: Sure.

BRAD: — I don’t know, I just never — I feel like if I commit to it and then something else comes along and someone, you know, and then that thing takes a backseat or it goes away.

PIPPIN: Right.

BRAD: You know what I mean? Like it’s —

PIPPIN: For me, there are things I really like learning about, though won’t necessarily use them in a real application unless I decide to change gears and start working in that particular system or something like that.

BRAD: Yeah, yeah, yeah. I even feel like Node.js is still very early to be using in a production app.

PIPPIN: Sure.

BRAD: But, you know, lots of — you know, Airbnb is using it heavily, so I don’t know. It might be mature enough now. I don’t know. What have you been working on?

PIPPIN: Oh, I’ve been working on the same thing that I’ve been doing for the last two months or so, which is EDD 1.9, getting it up to date. We’re pushing out the final release for 1.9 on Wednesday, so that’s been a big thing. It’s the largest release I’ve ever done, aside from like a 1.0. We have 112 bugs and enhancements in this version that are logged on GitHub at least, so it’s pretty large.

BRAD: Yeah.

PIPPIN: And then the other thing that I’ve been working on, which I’m sure I will talk about in future episodes more is, I decided to start writing an affiliate plugin just for simple affiliate tracking, referrals, et cetera, because I really have never been happy with any of the current solutions out there. So I decided to start writing my own.

BRAD: Yeah, that’s awesome.

PIPPIN: It’s called affiliatewp.com. It hasn’t gone very far yet. I’ve only written a few of the classes for the plugin, but it’s kind of my side project just to have something else to work on and eventually get released.

BRAD: I feel like every time I have an opportunity to use your stuff, it’s always like, I’m always like just a little bit too far ahead of where you are starting out. It’s like when I started building my site for Migrate DB Pro; EDD didn’t quite have the maturity like some of the add-ons —

PIPPIN: Sure, it was still really new.

BRAD: It was really new, and so I wasn’t really comfortable using it at that point. And then I had just set up Affiliate program, and you’re starting to build a plugin. It’s like, ugh, one of these days it’s all going to line up —

PIPPIN: See, one of these days you’ll realize that what I’m actually doing is just watching to see what Brad Touesnard is working on and decide to build whatever he’s using. That’s my development methodology.

BRAD: Oh, nice. Well, I guess we’ll never —

PIPPIN: You will never get to use it!

BRAD: Oh, well.

PIPPIN: Cool.

BRAD: I’m sure I will. I’m sure I’ll be moving to EDD before long. But —

PIPPIN: Well, that’s cool. Well, I’ll be here if you ever decide to.

BRAD: Yeah, awesome.

PIPPIN: Should we jump back into Git? I know we’ve got a couple more things to talk about.

BRAD: Yeah. Let’s do it.

PIPPIN: Cool. How about tagging? Do you tag all of your releases?

BRAD: I do, yeah.

PIPPIN: Awesome.

BRAD: Even the betas, actually. And I think — I can’t really — I guess the reason I do that is just to have kind of a record of here’s the commit —

PIPPIN: Sure.

BRAD: — where we stopped and released something.

PIPPIN: I have, I think I have two big reasons to do it.

BRAD: Yeah.

PIPPIN: One is that so that you have that snapshot of Version 1.8.5 or 1.8.7 or whatever the version number is. Two, it’s also kind of cool because GitHub does releases now, like, tracks your releases as tags. So you can actually go in and see all of your releases, which is pretty cool.

BRAD: Yeah.

PIPPIN: I like that a lot. So for example, if I go into EDD, we have 56 releases on GitHub.

BRAD: Wow.

PIPPIN: Which it’s a really nice way of just quickly seeing: how many versions have we pushed out over time? In terms of the snapshot, the snapshot is super important for, like, if you want to compare something. Like, let’s say you want to know what changed between 1.8.7 and 1.8.6. Maybe you introduced a bug, and you’re not sure where it is, so you want to just go and create a diff for the two versions. You can do that with tagging. There’s other ways to do it too, but I think that tagging is probably one of the easier ways.

BRAD: Yeah. Tagging is also important for people that are using your Git repo in their project as a sub-module. So for instance, I’m using WordPress as a sub-module for deliciousbrains.com. And when I update, I just do, you know, a Git update, just Git pull, and then the version number or, well, the tag name, I guess. So depending on what it is, if it’s V 3.9 or whatever, I would just do that, and it just updates from GitHub.

PIPPIN: Yeah, that’s cool.

BRAD: And I also do it for other projects as well. I think I have WooCommerce as a sub-module and a couple others.

PIPPIN: I learned a new trick yesterday that I had never used before. Have you ever used the — let’ say that you — okay, let me tell you the scenario first. We had released EDD 1.8.5, and we we’ve been working on 1.8.9, and I realized that we had a bug that we needed fixed right now. So we had to push out an immediate update it, for 1.8.6.

I discovered that I had not tagged 1.8.5, which was kind of a: “Crap! What do I do? Like, how do I go back to 1.8.5 and apply my fix?”

BRAD: Yeah.

PIPPIN: Well, previously I always thought you couldn’t do that. I thought you had to have a tag. That’s not true at all. It turns out you can actually check out a specific commit number, and it will take you back to the code base at that time of the commit.

BRAD: Mm-hmm, yep.

PIPPIN: I had no idea you could do that!

BRAD: Yeah.

PIPPIN: I thought that was so — that was like — that was like a revelation to me. So I went back and found my commit where, like, my version bump, which is always the last commit of a release. And I was like, all right, check out whatever that version, that commit number is, and voila, I have 1.8.5!

BRAD: Nice. I’m pretty sure also —

PIPPIN: That was amazing!

BRAD: I’m pretty the Git tag command also will allow you to input a hash, the commit hash, so that you can actually tag any commit in your history. I’m pretty sure.

PIPPIN: Oh, I didn’t know that. Oh, that’s cool.

BRAD: I’m pretty sure that’s the case, but I’m not 100%.

PIPPIN: Sure.

BRAD: So check the boxes.

PIPPIN: Yeah, so then it was nice because then I could go back and actually retag 1.8.5, so then I actually had an official tag for it.

BRAD: Yeah, absolutely.

PIPPIN: And then, in that same instance, so we needed to push out this fix for 1.8.6. We had already fixed the bug in 1.9, and I really didn’t want to manually apply my patch. I didn’t want to have to generate a patch or apply that, or even manually just change the code in 1.8.6. Have you ever used the cherry pick command?

BRAD: Oh, yeah, yeah. Cherry pick is a lifesaver.

PIPPIN: Oh, man! It is so awesome! It was the first time I’d ever used cherry pick.

BRAD: Yeah.

PIPPIN: But it was so cool. So I had 1.8.5, and I had that snapshot, and then I had this commit that’s technically in the future from 1.8.5.

BRAD: Yeah.

PIPPIN: I’m like, I want to just bring this back. I want to retroactively apply this. And so, like, Git cherry pick and then the commit number, and it just puts in the patch. I guess it’s really just like applying a patch.

BRAD: Mm-hmm, yeah.

PIPPIN: But I had never used that before, and that was so cool.

BRAD: Yeah. I mean, the alternative would be to, like, copy your changes manually, right, which would be really annoying.

PIPPIN: Well, there’s two main ways. You could copy the changes manually, which I have done before, which I always feel really dirty doing it.

BRAD: Well, it’s….

PIPPIN: It’s like … version control system that I know should be able to handle this, yet somehow I’m still copying, I’m like copy and pasting between diff files.

BRAD: It can result in conflicts, right?

PIPPIN: Oh, yeah.

BRAD: If you do that, so it’s bad from that perspective as well.

PIPPIN: And I guess the other way then would be to generate an actual patch file from your commit and then apply that.

BRAD: Right.

PIPPIN: But cherry pick was way cooler, and way better.

BRAD: Yep.

PIPPIN: So that was a new one for me that I really enjoyed working with.

BRAD: Cool. Have you ever used Git add, and then -P?

PIPPIN: Git add -P.

BRAD: Yeah.

PIPPIN: Yep. I bet you you’ve seen the video on that.

BRAD: I’m not sure I have.

PIPPIN: From a guy named John Kary.

BRAD: Maybe.

PIPPIN: Okay. If you go look it up, John Kary recorded a video that is called: The most powerful Git feature you’re not using.

BRAD: Yeah.

PIPPIN: Yeah. I learned about it. He’s my old roommate.

BRAD: Oh, is that right?

PIPPIN: Uh-huh. This video went viral on Hacker News and a couple other places. It’s a fantastic video. If anybody who is not familiar with Git add -P, go search for this video, and you’ll find it. Yeah, he’s my old roommate. He’s actually the one that taught me Php to start with.

BRAD: Yeah. I’ll give a little, just a little summary of what it is just so people might —

PIPPIN: Go for it.

BRAD: So it allows you — so Git add just adds, you know, an entire file or all the files in a directory or whatever you’re referencing. But Git add P will allow you to select which lines that have changed or which changes in a file you want to include in your commit. So for example, you could, you know, leave out — maybe you deleted a line from the file as kind of a cleanup, but it wasn’t related to the other commits in the file or the other changes in the file. And so you could split those into two commits just doing Git add P and doing two separate commits.

PIPPIN: Yeah. It’s super cool. I like using it a lot for — you get into the zone. You’re writing something. You’re writing a feature, or you’re writing a bug fix, and all of a sudden you realize — crud; I have changed like five different files that are unrelated to each other, and I really don’t want to put them all into one commit because it would be a meaningless commit. I mean, because the idea with commits is you really want them to be meaningful in that the only changes in a commit are the ones that are directly related to that fix or that improvement.

BRAD: Yeah.

PIPPIN: But suddenly you just get into the zone, and you’re writing code. You’re doing whatever. And suddenly you’re like, crap, I haven’t committed anything. So you can use Git add -P and go select the exact changes that you want to put in your commit.

BRAD: Yeah.

PIPPIN: So cool.

BRAD: You’ve got to like, you know, it’s for your own benefit to split out those commits because later on, if you’re going through your commit log and you see this one giant commit, and the commit message is like “stuff” or something.

PIPPIN: Stuff: awesome commit.

BRAD: That’s not going to be helpful.

PIPPIN: Well, not just that for like commit logs, but also like go back to our previous example where we were talking about Git cherry pick. Let’s say that there’s part of that commit I need. I need to apply that somewhere else.

BRAD: Yeah.

PIPPIN: If I cherry pick it, or check out that commit, I’m going to get all those changes.

BRAD: Yeah.

PIPPIN: Which is another, I think, good reason why commits should always contain only relevant changes.

BRAD: Yeah. Or another reason, since we’re adding reasons, what if you’re submitting for me, to me for code review, and I go there, and your commit is one commit. It’s five files, tons of changes, and the comment log is “stuff”. I’m going to be furious because I don’t know even where to start. I have to start line-by-line trying to figure out why you’re doing any of this stuff, right?

PIPPIN: Absolutely.

BRAD: And no context, so you really need to give your reviewers a break by making small commits that are concisely described in the commit log.

PIPPIN: Yep. Couldn’t agree more. And, I mean, in a multi-developer team, that’s super important. But I discover, even in my own development, like when I am the sole developer on a project, if I go back through my commit logs, I always get mad at myself when I see new changes or changes for 1.9, or this is fixing some dumb problem — without meaningful commit messages, without separate commits for each change. It drives me crazy because I can’t actually accurately figure out what I did.

Anything else we want to throw in about Git?

BRAD: I don’t think so. I think one thing I should mention is a diff app. I mentioned one that’s Mac only. So if you’re on Windows, you can check out a diff program called CSDiff. It used to be awesome. I’m pretty sure it still is.

PIPPIN: Cool.

BRAD: And it’s not like the flashiest app, but the algorithm that they use to do the diff is just really good. Component Software is the company that makes that, so check that out.

PIPPIN: Nice. I haven’t used it, but if you are a Linux person, then there’s one called Meld Diff Viewer. And I have no idea if it’s good or bad. It has a lot of really great ratings on it, so that’s something to check out if you’re a Linux user and you want a graphical app to use as opposed to just a command line.

BRAD: Cool.

PIPPIN: Awesome.

BRAD: Should we wrap it up?

PIPPIN: Yeah, I think that pretty much does it for us. If anybody has any questions about Git, tagging, branches, merging, cherry pick, you have other tips you want to share, feel free to leave them in the comments. Thanks, everyone.

BRAD: Thanks, everybody.