 We're gonna talk about Git and GitHub and secrets today. I'm Zach Holman. I'm Holman on Twitter, Holman on GitHub. You can do the needful there. And I work for GitHub Incorporated. We host source code. If you don't know what GitHub is, this talk is gonna be really confusing for you. First thing I wanna let you know is I'm not a smart guy. I'm really kind of dim-witted, not a bright dude, but I hang around lots of smart people. These are all my coworkers at GitHub. A lot of them now, kind of weird. But there's a lot of people here. And just by hanging out with them, just by being in chat rooms with them, I end up learning a whole bunch of valuable stuff. Unfortunately, this is mostly the valuable stuff I learn as we post things in a campfire. So I'm really good at tacos and eating, I guess. Sometimes I just go to sleep with this on my screen because it's just, it really gets me going. But also we talk about Git. I like to read a lot of the tweets you guys send to GitHub, support requests, blog posts, discussions. And just sort of, by reading all this stuff, I end up learning a lot about Git, about GitHub, about problems people end up facing. And I think there's a lot of stuff I can talk about. So we're gonna talk about that today. And that's gonna be the goal. I'm gonna throw a whole bunch of stuff at you. Sometimes my talks are much more higher level, philosophical, blah, blah, blah. That's not this talk. I'm gonna be going quickly past a bunch of different information. You can take notes if you want. I'll throw these slides up online afterwards. So if you wanna track something down, some weird arcane Git command, besides all of them, you can go back and check them out later. So first, what is a secret? For Git, basically everything is a secret because the UI of Git is ridiculous. So we'll talk a little bit about that. For GitHub, for us it's sort of features that don't make it into the UI is what I'll call a secret for this sort of thing. And that's a bunch of stuff for us. We have hidden HTML, dip tools, email hacks. We have a whole bunch of different things we put inside the website that we don't necessarily make a big deal about. We don't announce. We may not add buttons to these things, but we still have them in the product. The whole reason behind all of this is so we can experiment with different things. And I know by the end of this talk, you're gonna say, you know, that looks really cool. I like that feature. Why don't you just add a button and add to the UI? That'll be so awesome. So I decided to mock that up, what would happen? And this would basically what GitHub would look like if we did all of that stuff. With the exception of Hasselhoff, all the other stuff can go. But what we try to do is aim for simplicity and we try to be flexible. So we're gonna try and make the most simple product we can, but if it's possible we can add like a URL parameter to do something cool on the website for those power users. We wanna make it flexible enough to do that. So I'm sort of talking about the flexible in this talk. So it'll be two parts, get and GitHub. Let's start out with GitHub and then we'll just dive right into it. You can take breasts in between slides. It'll be quick. Diff and patch, if you add .diff or .patch to any sort of diff URL online, we'll end up generating the text only output of that command through git. So if you're ever dealing with anything like the command line, if you wanna do a quick script just to get like the, you know, what actually changed this commit, you'll get the diff output that way. Just add .diff or .patch to any URL. This works not just on diff pages, but also on compare views, pull requests, commit pages, anything that has a diff, it has a textual representation that you can access just by adding those, the file names to the URL. Also, if you ever have those people on your team, I like to call them dicks who don't control their white space and they just commit like, you know, trailing white space and all these other white spaces. After you fire them, you can go in and add w equals one to the URL and then we'll just truncate all of those white spaces. So we'll actually show you what actually changed rather than these 40 lines are just like now different and it's very confusing. Also subversion, obviously I like git. I think git is okay. Subversion is, exists. But the cool thing with GitHub that not a lot of people know about is we're the largest git host online, but we're also the largest subversion host online because every single git repository on GitHub is also a subversion repository. We do this via a special SVN git service layer on our side of things. And so when you send a subversion call to GitHub, we translate those calls on our side into git calls on our servers and then do the corresponding action on the git repo on our servers. So you can do stuff like SVN checkout and then pass it a repository on GitHub and then it'll do everything that subversion does. And we support almost all of the subversion commands at this point. And the code to do that is just black magic and I'm just amazed, but you guys can use the effects pretty easily if you're into subversion. Also I want to talk about HTTP and SSH for a little bit. A little bit ago, a couple of months ago we did some stealth changes to the site you may or may not have noticed. Previously we used to have this on every repository page. The SSH would default as the protocol you would pull down to clone a repository. We switched this to be HTTP a little bit ago. And then by default you'll have the HTTP URL up on the page that you can clone down. You may be asking yourself, why? Why would they do this? There's a bunch of different reasons that we're doing this. One, we're using smart HTTP here rather than the old dumb HTTP which is really slow. Basically this just means we have efficient server-side pack file generation so we can send those packets back to you really quickly. If you're ever in a corporate environment maybe not a lot of you in this room, but firewalls are horrible and this is kind of a big barrier to a lot of people using SSH for all their good stuff. Also key generation which is really good for people on Windows or if you're not a neckbeard. For every single person in this room that may be able to set up an SSH key easily, I can show you 50 people who have no idea how that works. So all of this stuff is a lot harder for SSH for most people. Most of you are probably still like, I don't care. None of those things are really relevant to me. The problem which again you guys may have run into is if you pull down an HTTP URL clone by accident when you wanted SSH, that's all fine but you'll get the username prompt and then your password prompt to GitHub which is obviously nobody wants to type the same username and password over and over and over again. This was remedied in Git 179 with something called credential caching. If you, this URL will help you set it up on your particular distribution. If you're on a Mac, the newest homebrew installs this by default and then it'll store all of your credentials inside of Keychain really securely which is really nice so we're gonna have to keep typing all of that stuff over and over again. If you still don't care, just click SSH and we're gonna remember that forever. So that's the TLDR on that one. Cloning without the .git. Yeah, you can just clone the URL, that's cool. I like that. We like to call something called GitHub HD sort of which is kind of everyone's been doing this lately. Everyone loves our new icon sets obviously. No arguments there, right? But if you command plus on a Mac or whatever it is on Windows or you pinch to zoom on iOS, you'll get like the nice page and then we'll zoom in. All the icons are nice crisp and you can zoom in and zoom in and zoom in and it looks really nice. This is obviously a big deal with the whole retina Macs which I have one and it's awesome. You should get one and if you like pixels I guess. So that's kind of a fun thing. I suggest you guys looking into icon sets on your own sites. It's kind of a nice way to get this crisp and clear for everything. Also, auditing. Some organizations are a lot more paranoid about security, rightfully so. So sort of a lesser known tab in your settings is the security tab and it'll show you public keys that get created or edited or added to your account and also repositories that may get deleted. So you can go in and say, oh somebody added this public key to my account two weeks ago, maybe I should go investigate that. It's just kind of a nice way to make sure that nobody else is prying at your code that you don't want them to. Everybody here knows the Octocat? I have stickers by the way later if you need it, the Octocat. But the story of the Octocat is hilarious to me because it's so boring. It was a cheap stock art. We grabbed an iStock photo because we wanted something cute on our error pages because the error page tends to make people angry but you can't really be angry at this cute cat because it's standing in a puddle of water. I don't know why. So this is cool. We used the Stock Photo for a while and then people started liking the Octocat which is a problem because we didn't own the rights to them so then we got the rights and we kind of a GitHub mascot for us and that's the story of the Octocat. The secret here, if you go to octodex.github.com that's where we put all of our crazy Octocat animations and clip art and stuff like that. I don't know, I just love Octocats. They're cute. GitHub.io is our URL shortener. The easiest way to sort of use this is this is an example of shell scripts you can hit if you just go to that URL and the usage here is basically, it'll just give you a command line program that you can just run git.io and then the URL and then an optional name and then you can convert any sort of GitHub URL into a git.io shortener. So if you ever do stuff like I use this in these slides just because it's easier than doing the whole repository URL on the slides or if you're on Twitter or anything like that you can use our URL shortener. We have a Mac app. We have a Windows app. Just wanna let you know. Some people don't know these things. It's amazing. The Mac app is awesome. What about the Windows app? Does not like the Windows app. Just kidding. It's okay, cool. Linguist is also really cool. Linguist is our open source project to handle all of our language specific stuff on GitHub. So anything that involves detection of a URL or detection of a repository, syntax highlighting, vendor files, all of those things are different ways that linguists can determine what a language, what language a particular file is in. This generates that nice language graph on your repositories so you can see it quickly at a glance like what is involved in this repository. This is also good if you wanna check this out and run it yourself. Back when, I'm forgetting the dude's name. I don't know. We've had a bunch of program languages get released over the last couple of months and because all of this stuff is open source we could have syntax highlighting all of this stuff really quickly on github.com. And if you ever run into stuff where we're misclassifying your project we may think that something is ruby when it's something else entirely. This is where you go to and try and figure out how you can help out and make us better for everyone else using their projects. Email replies, you can reply to any email that we send you and we'll just put it in the site. So if you get like an issue notification somebody create an issue, just reply back to it and then we'll add your comment as a comment on the thread. We'll add a nice little icon saying this is an email reply. Kind of nice thing, I do this all the time on my phone if I don't wanna load up the site and just send a quick email and then get involved in the discussion. If you guys know about gist it's kind of our tech snippet as a service. It's kind of nice, it's kind of been taken away for a long time but there's a lot of cool stuff you can do to abuse gist basically. It's not just for snippets and there's a couple cool ways to do this. Oh yeah, I was putting embarrassing photos of Julie in here. So Julie is one of our designers at GitHub and she was doing some cool stuff on gist for design related stuff which I'm really kind of stoked about. This is a bunch of like weird CSS with like Mozilla conditionals and WebKit and all this stuff. I'm a human, I don't know how to read that stuff so it's cool that she's sharing this but I have no idea what she's trying to say here. So in her comments of her gist she'll say oh I'm making this curled corner effect in CSS and then she can add all of this stuff. She also links to an actual website that you can play around with this in real time and zoom in, like pick around in the source code. It's just kind of a nice way to use gist as a very simple prototyping tool. You don't have to do some crazy repository or anything like that to get people discussing it. You put screenshots directly in. It's kind of a nice way to sort of abuse gist. It's not just about boring XML that you may put up there. Don't put a XML up there, that'd be really boring. Developers are a lot of cool. There's a lot of ways for developers to abuse gist as well. Gists in fact are full repositories so you can clone them down like anything else. This is, the URL is on any particular gist. Just clone that down as you would normally. One cool way to deal with this, this one guy, Jeff, wrote a blog post about micro gems which is basically a gem and a gist. All you have to do is include a gem spec in your gist and you can very quickly just put an entire sort of gem and host it on a gist rather than doing a full project on GitHub and dealing with all of the overhead with that. I do this a lot. I do this with something called TechSpec Mini which is, Chris Wandsroth wrote this. It's like a quick way to add context and stuff to your tests in like 30 lines of code. So in my project I just specify to use this gem and I point it to this particular gist and then I get all of the benefits of using Bundler to deal with all this stuff and I don't have to do a really complicated release for any of this stuff. Is that how you specify get anymore? Did that change? Terrence? Nope, whatever. So don't listen to what I said if that changed. If it didn't, listen to what I said. Quick example, just look at git.io slash mini and that's the easiest way to figure this stuff out. Just look at the gem spec, how it's set up and it's a nice sort of easy way to do these things. One off projects, quick disposable projects. We have a bunch of image view modes which is all done client side which is really cool. So if you have an image and then you push up a new version of that image, we'll have all these different ways of figuring out what has actually changed between those images. This will show up in the diff page. So in this one it's just the overlay and you can swipe back and forth to see the very minute detail changes between those two images right there and you can just swipe along. It's really helpful in the cases of designers like to change those couple of pixels for some reason. You're like, what did you actually do here? This is how you can actually figure out whether something actually legitimately changed or to designers just trying to be cool. Hub, you guys ever use hub? You should, that's all I got. No, hub is really cool. If you're on homebrew, just install with brew install hub. There's also just a one liner install you can do. Used to be a gem I think. Hub is basically a superset of git installs next to your git wrapper and you can say stuff like hub clone, home and boom and that will go to git hub and just clone this down without having to type the whole thing. You can do multi remote pushes so if you wanna push to multiple places at once, you can just add a comma and then it'll just do subsequent pushes to each other. And then you can also attach a pull request to an issue which is really kinda cool. A lot of the times stuff will start out as an issue and you'll say, okay, this is broken and then later on somebody will want it to create a pull request and saying, oh, this issue started out this way and now I wanna make this into a pull request with actual code and we'll go from there. With hub you can just do this on a command line just tell it which issue to do and it'll just create a pull request out of that issue. Actually turn it into a pull request. And the reason this is so cool is that you can just alias this to your git binary. And if something doesn't happen to be in hub, it'll just fall back to your git so you can just use git for all of these things and it's just like a super set of everything. That's all open source, gitup.com slash defunct slash hub. Nice little thing. I mentioned earlier, the Octocad is now on our error pages and four or four pages and all that stuff. What you may not know is it's got accelerometer support on your phone so if you shake your phone around, you'll see all of the Octocad stuff changing around. This is really beneficial for your work so you can explain to your boss that you're playing with your phone to, I don't know, give work benefit analysis stuff. Yeah, press T on a repo page, you can get a quick file finder. This is amazing. It's one of those things that if you don't know about and you accidentally press T and you see this and you're like holy crap, I wish I would have known this about this earlier. So if you don't know this, check this out, just hit T. It's sort of like command T in TextMate and you can just quickly type out a file anywhere in your repository and then quickly jump to that. W will hit the branch selector on a page. It's again sort of like that fuzzy finder where you just hit W and you can quickly jump to a branch. I do this a lot if I'm working on a branch for a long time or I know that I'm never gonna be a master for the next week or so so I can just quickly go to that page and then just hit W and then jump back and forth between branches really quickly. S is for quick search. This is just our search form. We've since upgraded this to our command bar which is also sort of like a, I don't know, sort of like an Alfred quick silver thing which lets you jump quickly to different projects, issues. Search is a whole bunch of your data which is really cool. And then all of these things just hit question mark on any page and you can see all of the list of commands for that particular page. We really like keyboard shortcuts and there's a bunch of different things that you can do to just sort of quickly get the command line interface to a website basically. So something we do a lot at GitHub internally is to sort of subscribe people to a particular issue. So if I know something is broken and Ryan is the problem behind all of this, I can say like CC are to make go to this thread and he's now subscribed to that thread. So almost every issue at this point to GitHub, GitHub, our own repository, we have these CCs to particular people because we want people to be able to see like you should really pay attention to this issue because it's related to what you're working on. And then they get subscribed to all those notifications so they can see the discussion. You know that they're seeing the discussion and it's a nice way to sort of get communication without actively going over and like shaking them and making them do your bidding like that. You can also do Teams directly. If you're on an organization at GitHub just hit at org and then the slash team. So for us, if I wanted to ping all of the designers in our company, I could just hit at GitHub slash designers and then they'll all get subscribed to that particular thread. In general, we do a bunch of different things to commits as well. We just auto link all of the shaws. So if you ever mention a shaw, we'll trinket all of the other characters because you don't visually need to see the whole shaw but we'll hyperlink it so you can quickly jump to that particular commit. In this case, I revert a commit and then you can link straight to that commit that I reverted so you can sort of navigate between the two. You can also do this across different repositories. So you can say user add a particular shaw if you want to talk to about somebody else's fork of that repo. You can also specifically mention a different repository, user slash repo add a particular shaw. If you ever get into those positions, it's kind of nice to just be able to link between things really easily. We also do this in issues where we'll auto link specific issue numbers. In this case, you just hit pound sign and then the number and then we'll just auto link it to that repository's issue. You can also do that the same sort of way as the auto linking shaws, just user or user slash repo and then you'll link to that repository's issue that you mentioned in the comment body itself. I hate seeing readme's like this where like you just can't, between that part, it's just not syntax highlighting. Syntax highlighting is the best thing ever. So if you specify the language like that, you'll get nice syntax highlighting in your readme's. Just do triple back tick and then say the specific language that you're looking for. Okay, so it's Ruby and then we'll give you a nice highlighted thing in your readme. Just makes things much more readable and more awesome. You can also auto close issues straight from a commit. So if you ever commit something and you know that's fixing the issue number one, just hit closes, close, close, any sort of syntax of close and we'll automatically close it, same thing with fix. And we'll go in and it'll say, okay, he closed this from this particular commit. It's a nice way to just doing things all at once rather than going back and doing it manually. You've probably all seen the commit listings on a particular project. If you go through the histories, you can also do this by author. So if you go to the URL, it looks something like this slash commit slash master. If you add the URL parameter author equals and then a particular username or email address, I think also works, we'll filter that to show only that particular person's contributions to that project. This is really cool if you contribute to Rails and you wanna sort of put on your resume or boast about it. You can quickly link to this page and we'll show you just your contributions to Rails, for example. There's also a bunch of stuff about pull requests that I still, a lot of people use pull requests not optimally, I think. For GitHub, we use them branch to branch a lot. You don't have to have pull requests between two separate forks or two separate organizations or anything like that. So we do pull requests on the same repository and because we only really work off branches, there's only one GitHub repository. Nobody really forks GitHub internally. We just work on the same branch and we push it up and this is just great because we don't have to do separate permissions for forks. You don't have to add more remotes to Git which is really complicated. You can just push the branch and then do the pull request between branches. Pull requests, also our pull requests kind of look crazy. This is one from a few months ago when we redid our about page. We use screenshots all over the place inside of pull requests and this is just a standard markdown function. If you use the syntax on the bottom, exclamation point, brackets, and then in the parentheses, the URL, you can embed the images inside of GitHub and we cache all of these too. So if you put them on some host that's horrible like Skitch and then Skitch goes down, we'll cache it and you can still see it regardless. As I mentioned earlier, Hub has that cool way to convert issues to pull requests. The reason that exists is because it's in our API so you can just hit a post to that particular URL and you can do it yourself if you don't want to go through Hub. Again, it's kind of a nice thing if you want to deal with the issues, pull requests and not duplicating data like that. Emoji, if you don't know emoji, I don't know you, that's not cool. Emoji are the greatest thing ever. Just hit colon and then you put your particular emoji and that's how everyone will know when I put colon poo that I think their pull request is poo. It's really endearing for the person who opened the pull request. All of this stuff, the easiest place to check this out is just emoji-cheat-sheet.com and then there's a whole long list of all the emoji that we support in GitHub. Most of these also work in Campfire. We actually have a 37 signals GitHub collaboration emoji repository where we deal with all this stuff. Standardization in emoji is really important for us. So check those out. Sometimes you can do a lot of crazy things with emoji that words are just pedestrian at that point. Line linking, you've probably seen this. If you click on a line, you can highlight that line and then it gets added to the URL so you can pass that around and say, hey, check out this line. Well, you may not know, you can also accept ranges. So if you add the dash and then the ending point in the URL, so in this point, pound sign L16, line 16 through 25, we'll just highlight that whole block for you in GitHub itself. Also kind of a nice little thing to pass around code back and forth. Also, you've probably also seen the compare view a bunch. That's what happens when you push stuff up and a lot of the hooks get the compare view URL. If you're dipping between branches, you usually get a URL sort of like this, user slash repo slash compare and then a particular range where range is usually something like master dot dot dot my branch and then you'll see the differences between master and that branch in the compare view. The cool thing about this is that range is smart and this isn't necessarily a GitHub thing. This is strictly Git-based magic. So you can do cool stuff like master at one dot day dot ago dot dot dot master and you'll see the difference between what happened on master today versus what happened a day ago and that has cool different things you can say just yesterday or a particular date and then just compare this to master. I know a lot of people for their particular teams may do stuff like show me everything that happened in the last 12 hours and then they'll just bookmark that page so they can see what's actually happening on their teams page over time. Okay, so that's the GitHub stuff and now we get to get everyone's favorite confusing everything with lots of hidden weird stuff inside of it that I like to talk about. For better or worse, we sometimes do commitless commits at GitHub which is just using dash dash allow dash empty. So you can do a commit without any sort of diff or content in the commit itself add a message and you say allow empty and then you'll actually make the commit. I guess you could troll your coworkers with this if you're that type of person. You can also do other stuff. Sometimes you need some sort of commit to something to test like a hook or something like that and you do the stuff where you make a tiny commit and then you revert it and then you go back and forth and it's stupid. You can just do this instead. It's kind of a nice tricky way to do things. Staging hunks is probably not what you think. You just add get add dash p is really cool. It will sort of show you a whole bunch of different things. So when you're adding all of this if you have a whole bunch of code prepped and ready to be committed it'll show you all of these options like where you can basically say yes I want this line I want this particular group of files I want this stuff added and I want the other stuff still unstaged and so you can stage particular hunks basically and then commit those on their own. It's basically a smart way to do smart logical commit sets where you have very topical stuff and you don't have other weird things that had to be changed for that commit to work but aren't really part of that commit. Sometimes these are really nice if you are on a team that really cares about this stuff a lot. Get show colon slash and then a particular query is really cool. It will search through your Git log for the last thing that you committed that matches that search. So on the GitHub code base if I say get show colon slash stupid it'll just look through and see oh Rails logger was really stupid in April 27th. I do this a lot just because sometimes I know a particular commit happened and I don't care about anything before that I just want the last one. That's a nice quick way to do that and access that. This is really cool CD dash. If you don't know this this just goes back to this previous directory you were in on the command line. Git has this concept too so you can say git checkout dash and it will just go back to the branch that you're currently on and you can just go back and forth between master and next, master and next. This is really cool because I think you are switching back and forth between those two branches obviously. Merge branches you can access via Git with git branch dash dash merged and we'll show all of the branches that something I'm getting confused here. Hold on, it will work out. Yeah, so these are all the branches that have been merged into the branch that you're currently on. The reverse of this is dash dash no dash merged which are the branches that haven't quite been moved merged into the branch that you're currently on. Obviously I'm already confused talking about it but this is really helpful to figure out to reduce that confusion when you're actually working on stuff. Has this branch been merged in? Has it not? If so, merge it in. Along the same lines you can say dash dash contains and then a particular SHA and we'll tell you which branch owns that particular SHA. Sometimes particularly if somebody's sending you some random link to a Git repository and it's just a SHA in the command line in the URL bar and you have no idea where that SHA belongs to this is a nice way to figure out, oh it's on this date fixed branch. Something I learned recently which is actually kinda cool is sort of copying the content of a file to your particular branch. So if you say git checkout and then the branch and then dash dash and then a path to the particular file that you want that basically copies what is in that particular file on that branch into your current working copy without having to check back and forth between those branches. I use this a lot when I'm like, I definitely want the stuff in this other branch but I don't wanna merge that whole branch and I just want that particular file. That's a really quick and easy way to do that. Reachable commits, this is also, there's a lot of just cool things you can do once you learn the weird syntax of git. Git log branch A and then the caret branch B will show you the commits in A that are not in the B branch. So you can again just sort of see what is the difference between branches in terms of the log in this example. Along those same lines, if you run dash dash loss found on this, it will show you the blobs and commits on a particular branch or that aren't on a particular branch, sorry. So if you ever end up like deleting a branch or something like that, it's actually fairly hard to delete content at all in git. Usually it's going to be stashed away somewhere until you garbage collect and this is the way to figure this out. Like this is pre-garbage collecting, you can say, okay, this is the particular commit I'm looking for and then I can pull that commit into the branch that I'm on. It's not actually lost at that point. We are sort of obsessive about diff stats at GitHub. We obviously like to see less code in production than more. And we show this on pull request pages and this is just the same way you can deal with this on the command line yourself if you do git diff and then this basically is saying, show me the stats of the commit before last compared to the current head of master and I'll just show you the stats between those two. This is cool, I've seen some people just build lots of scripts around this, have very pretty scripts that you can just run to see what has actually happened in the last commit type of deal. Git blame obviously has a bunch of different stuff. You've probably used the git blame where it'll show you who changed that line and then the particular lines next to it. Git blame has a bunch of really cool things you can do. The problem is if things are like this particular line, say this has a bunch of like added white space at the end, I don't really care about that because it doesn't change the underlying meaning of that line. So if you add that with git blame dash w, it will show you in the previous example, that particular line, the hell did it go? That particular line, the middle line was a different commit when it really, I just wanna see who originally put that line there without the white space. And then dash w will look back in your history to figure out when did this line meaningfully change, then use that as a blame. Dash m is also pretty cool. Let's see. Yeah, it detects the moves between different files. So if you have two lines of code like a and b, and then you change it to b and a, it ends up, blame is not really smart at figuring out how that stuff works. But if you add dash m, it will blame the original commit not the move commit. So if you have a commit to move those different functions or different methods in the file itself, it will then go back with dash m to figure out when did that actual commit happen? So you can see, again, when did the meaning of the line change, not when did the position of the line change? Git dash c is like m, but it looks at other files in the same commit. So if you're moving stuff between files, if you're saying, okay, I'm extracting this method into a separate helper, if you dash c, it will detect those moves. And again, it won't look at that merge commit. It will look at the original commit that it pulled from. And then you can add dash dash c or dash cc, which we'll look at the commit the file was created in and dash c c c, we'll look at all your commits. Obviously, the more places you're telling get to look at, the slower it's gonna be. But in a lot of cases, you will be fine with waiting because this stuff is really valuable to figure out where did this actually come from. Multi remote fetches is really cool. If you have a bunch of different repositories you're working on for whatever reason, you can set up a group in your git config and then you can fetch that group just by saying fetch my group and that will go in and fetch remote one or remote two in this case. If you're in that situation, get status. There's relatively recently, I guess a couple years at this point, they added a couple new features to get status. This is the normal get status, it's really boring. I never use this because at this point I know how to git add stuff. I don't need to read all that stuff. So I just alias git status to git status dash sb which gives you something like this, it's got a little bit more color, it's to the point, it's directly what you want to see. That's kind of a nice thing to do. Word diffing, I do a bunch of writing on my blog, stuff like that, just personal writing and diffs originally are really kind of horrible at writing, like plain English type of stuff. So in this case, I added one word and git will say, okay, this whole line changed. Now obviously, yes, it changed, but what changed? If you do the same sort of command with dash dash word dash diff, it will show you a separate diff with that particular word. This will show you exactly, oh, this particular word changed and I can make, then I can go from that point forward. This can help with code too, I just use it really a bunch with long form pros. Spelling, I'm a horrible speller as well, git comit. I do that all like every day. And then git says, oh, that's not a command. Did you mean commit? Ta-da, and it doesn't do anything, it's like horrible. He's kind of trolling. So if you do git config dash global help dot auto correct one and then you type git comit again, it will just say, oh, you said comit, it doesn't exist. I'm just gonna assume you mean commit, deal with it if you didn't and then I'll just do it. So if you wanna live dangerously and just assume your misspellings will look like the spellings that you wanted it to look like, whatever, just trust git, that will never go wrong for you. Just kidding. Git re-re-re is hilarious to say, it means re-use recorded resolution. This is sort of, it's one of those things that's really nice in the weird circumstances if you get yourself into this sort of thing. If you turn this on re-re-re dot enabled one, it basically remembers or records merge conflicts. This is beneficial if you're on a really long running project where you're continuously merging back and forth between the two or typically you'd be merging from like master into that long running branch and if you end up running into commits the whole time and you resolve those commits, git won't necessarily remember those commits when you merge back in if it runs into those same sort of problems again. So this basically will say, git remember my actions on this particular merge commit here and then I won't have to do that again in the future. Color is good, just turn on the color UI and obviously color makes everything better, yay. That's all I got there. Git amend, I use a whole bunch if I commit something and I haven't pushed yet and I wanna say, oh crap, I made a misspelling here or something like that. I just have git amend alias to git commit dash amend dash c head and I'll amend it to the latest commit. I think dash c is not even needed here. It just assumes to be head anyway. But that's really cool then you don't, then again you get sort of smart logical commits rather than a string of like oops, forgot this, oops, forgot this, whoops. Yeah, we have a bunch of those people at GitHub too. Git undo is just an alias I have for git reset dash dash soft head, the previous commit to the current header you're on. There's a bunch of different git undoes that depends on what you want. I use this way because it retains your commit as staged rather than just like blowing it all out or anything. Usually I do this in the case of, I didn't wanna like amend it, I wanna still work on it and stuff, I just wanna roll back that commit and still prep it to be committed again. But it's just ready for me to do that. Git count, I have alias to git short log dash SN which is a nice way to just jump in a repository and say who's actually working on this project? Who can I bug to see who's breaking my stuff? And then git credit is just a nice thing that I have. It's a script that basically is just git commit dash dash amend dash dash author. What you're doing is basically saying, I want this guy to be credited for this commit that I'm pushing right now. Because git actually has both an author bit and a commit bit where you can say this person is the author of this commit and then this person, me is the committer. This is really good if you want to remember that like, oh, I didn't actually write this but this is the person I wanna contact if something breaks in the future. In this case, it just sets the head's author as someone else. Okay, that's what I got. One last thing, I just wanna point out the most important thing, the Octocat is four legs and one tail. None of this eight-legged thing, that would be absolutely frightening. Humans don't like eight legs. So that's what I got, thanks. Question time? Kick me off the stage time? I got five. Let's talk about spam. I think that you should be supportive now. I can't find a way. I mean, how can you change the target of a request? Or what do you do then? I don't believe so. I think that did change at some point. I'm gonna actually share the reason why that changed but I don't think you can easily change the target of a request right now. Hi, on the homepage of the Good Hope, when you first log in, if you're a part of many organizations that kind of like, just list all of your repositories, I don't know, to me it's random. So can you tell me how many they use on the people? You're talking about the sidebar? No, it's on the right, I guess. I guess it is on the list of repositories. Like how are they bordered on the main page? Because I find myself going to sort the repositories by organization in order to go to the last, in order to find the repository I'm working on. So the sidebar is organized, I believe, by last pushed at date. Basically more active repos will end up on the top of that list. If you're talking about dealing with different organizational stuff and you want us to see just that organization's one, I'd switch to the context or the context switcher up top. Otherwise, are you talking about just trying to jump to a repository really quickly? Yeah, yeah, I had a, I don't know, I just felt like I didn't know how to organize. Yeah, I mean in that case, if you have a particular repository that you wanna jump to right away, I'd just hit S and then use the new command bar and then just use the user repo syntax. So if I wanna jump to github slash github, just hit S, github slash github, enter, and it'll just jump me right there. It's probably the easiest. Playing back. I'm also a big fan of speaking hunk, but was there a reason for the git ad dash p? Did I just have to point out, oh, git ad. Yeah, git ad has the git ad dash p hunk staging. Git up for Mac also has line by line staging as well. Usually if I'm in a really big commit, like a really nasty one, I don't do that on a command line either because it's confusing. I have to read the options every single time and figure it out. So I just go to some other GUI to do that as well. Yeah. So I need to do it. Yeah, dash i for the interactive as well. I don't have a question, I have a statement. So we're just using the awesome one box, search box, Jenkins or whatever thing, what does it call it? So, S for the little box at the top. Oh, command bar. Yeah, that thing. And if you're a Vim user, you can use control and a control P for, or Emax even for, you know, between it. It actually works in the one box, that's awesome. Yeah, we try to do like Vim bindings for a lot of different things on the site. And we try to show some Emax love sometimes. Just kidding, we love you all. Anybody else? Cool, I'll be around, ask me questions, grab a sticker, party tonight. Cool, thanks.