And there we go. Hello, everyone, and welcome to I&E's bootcamp series, GitHub for everyone. My name is Brooke Seahorn, and this is actually going to be a really cool. I know you've always heard people say, I couldn't be more excited. You think, yeah, whatever. This is actually going to be very cool. In this particular series, what we're going to do is we're going to be diving into GitHub, looking at some of the features. And the main thing I want you to remember about this is is GitHub for everyone. One of the things that a lot of people miss out on GitHub is, it's not just for developers. It's not just for infrastructure people. You can use it in so many different ways. It's really creative. But the problem is most of us don't or are not even aware of the technical capabilities that are there. So with that said, again, hi, my name is Brooke Seahorn. First of all, welcome to everyone who's showing up. I'm seeing several people, Aziz, Baron, Matt, Varyn. Hey, everybody, Keith. Hey, man, Keith Bogart. The amazing instructor we have here at I&E is also going to be sitting in the attendees room. And there's actually a lot of people from inside I&E who are going to be watching this because GitHub is just such a powerful tool that we want to let everyone, even the folks working in I&E, know about it. Now, for a little bit of a switch up here, there's something I need to tell you. A little bit of a bait and switch. I'm not the instructor. Remember at I&E, we're all about experts making experts. And even though I'm learning a lot about GitHub, I think what I'm learning more and more is that I've been doing some things wrong. And the person I've been learning from is the person who is going to be leading this and in fact came to I&E from GitHub. And I'd like to introduce him down, Mr. Matt Davis. Hey, Matt, jump in, man. Hi, everyone. Thanks for showing up. This should be an absolute blast. Great segue, Brooks. Couldn't appreciate you more. Let's jump in and talk about you and I real quick before we get started. As Brooks spilled the beans a little bit prior to I&E, I did kind of do a little time over at GitHub. And it was an absolute blast. And one of the best things that I learned while I was there is that GitHub has so much more to offer than what we realize from the outside looking in. We're used to developers using it or students using it to use or to source code their actual or version control their source code, right? So we're used to them using it for development projects. What we're not used to is the HR team using it for documentation. What we're not used to is using it to give all of our managers a view of work in progress. What we're not used to is making the work that we're working on available to the rest of our organization in case they have something they can chip in. And then we're also giving them a guide on how to do that. And that's something that really opened my eyes when I was at GitHub to the capabilities that this platform has.  And that's kind of weird, right? You're probably used to going through a system like Just Works or some sort of HR management tool to request your time off. For us or for them at GitHub, not us anymore, we would open issues to request our time off. And what was really cool about it is it wasn't just an issue. When we opened that, an entire series of automation would kick off and add that time off information to Google calendars, to HR spreadsheets. It would put it in wherever the visibility was needed. And the employee had to do nothing other than open an issue. It was really cool. So what we're hoping to do is expand your horizon on what GitHub has to offer you. Some of you might be developers. Some of you might not be developers. I hope there's more non-developers than developers in this session because I think you're going to get a lot of insight on how you can enable your developers. So hopefully we can teach you a thing or two. Prior to GitHub, I traveled all over doing DevOps consulting. And prior to that, I worked at a college. And prior to that, I did network and stuff. So I've been all around the block. And my most current is here at ID. And what's really cool is I get to bring all of that expertise to the table and talk about a tool that I just truly firmly believe in. And that's the big thing is I could sit on any high horse from a third party that said, hey, will you promote our tool? That is the exact opposite of what's happening here. This bootcamp, although it's about GitHub, this isn't a sponsored thing from GitHub or anything. We at I&E saw the power of GitHub. And we couldn't help but share it with you. So it's just something that we really believe in and believe can make your workflows a little better. Absolutely, absolutely. I'll kick it over to Brooks. If you want to throw a little bit of your background out and then we'll do that. Absolutely, yeah. I've been in I&E coming up on one year as an instructor here for AWS. Prior to coming here, I was at AWS, the mighty AWS, where I taught all sorts of facets of cloud. And I can tell you that, you know, the things that Matt just talked about, the collaboration, looking back, there were situations where we really should have been using GitHub. One of the most, I don't know if you've ever run in this sort of situation, Matt, where, you know, you're having teams collaborate just on documents, but these are big, big, big documents. And there was a real push on inside about getting rid of some certain types of language inside our public facing documentation or at that time AWS's public facing documentation. The challenge was, Matt, was that you're talking about, you know, a document that can have typically hundreds of pages in it, making sure that when it goes to legal, legal can see just what changed when you're passing around Word documents. Wow, that was a real challenge. Absolutely. That was, dude, the solution was right at our fingertips the whole time with things like GitHub. So I think that's really cool. And by the way, I hope y'all heard the thing that Matt said there about requesting time. That's the flexibility of this tool that even things like that and become such a great single source of truth for what's out there. So anyway, yes, I was at AWS, I was there for several years. Prior to that, it's been many, many, many years working within the national defense architecture, particularly for the DOD, the different branches of service, implementing cloud architectures. And then of course, back before that as a software developer, still a software developer today, Matt and I have great conversations about Go and Rust, it's actually fighting at one another about which one's better. So goes the better language. Yeah, we'll, I'll straighten you out, man. Don't worry, we'll get you straightened out. So that's my background right there.  And the thing about it is the sucker is free, absolutely free to individual users. There's some higher levels that Matt will teach us about, but it's just, it's free for the using. So we really do need to take advantage of it. So that's a little bit about me. Excellent, thanks for that Brooks. Yeah, man. So we'd like to know a little about you and we know that you guys can't jump on the mic or do any kind of screen sharing but I see one of you has posted in chat, it looks like VJ says that he worked, or works as a network engineer, no prior GitHub experience. I would love to hear about some of the rest of you guys that are in attendance. You go ahead and post that in chat.  And what we're really curious about is one, like your GitHub experience, like that's super helpful just to know, like if you've messed with the platform, under what capacity you've played with the tool, whatever that might be, but the most important piece is tell us about a collaboration challenge that either you currently face or have faced in the past. And I wanna prompt you a little bit, consider all the possibilities of collaboration. There's collaboration in your immediate team. Brooks and I have to work together every day, we don't tell anybody, but we have to. And that means that we have to communicate, or at least our work is better when we do. So we have that inter-team, or that intra-team collaboration, but we also have to work with the production team, don't tell them what we're forced to, again. And that's inter-team. So how do we help other teams collaborate with us? And then on occasion, we might have to work with other organizations. And you're probably in one of these buckets, many times throughout your career. So I'm curious to know like, what are some of those challenges that maybe you faced? And we'll give you like 30 seconds to type them out. Yeah, just a little short blurb, absolutely. Cool, so it looks like Barron says that he's also a network engineer working on DevOps and Ansible. High five, what up? I love Ansible. That is my configuration management utility of choice, absolute favorite tool. I got my DevOps start. And you're just now learning about Git and GitHub.  I think that you're gonna leave the next three days. Not only are we gonna show you how to version control all your Ansible playbooks, we're not gonna dive into Ansible specifically, but all of the concepts are gonna apply. You're also gonna learn how to pipeline those. I've done some really cool stuff with Ansible and GitHub Actions, where I used GitHub Actions to take, the playbook files and provision the infrastructure and just automate all these pipelines. And we're gonna talk about that pipeline automation. We're gonna do a little bit for the quote unquote developer. And then it's mostly gonna be around like how you can apply this to things that aren't exactly dev or DevOps related, but much more like people management related. All of this stuff is gonna apply. And I think you're gonna walk away feeling real good, real good. Cool. So Keith says demystifying concepts of repositories, branches and stuff like that. Yeah. You're in good hands. That's a horse that we will be sure to tenderize thoroughly as we go through this bootcamp. Another network engineer, let's see your prior experience. Okay. I don't know how it might help with Cisco DevNet, but it might. What I can tell you is that any type of note taking you're ever gonna do, GitHub is a wonderful, wonderful place for that. And on that token, all of the files that we work on are gonna be shared with you through GitHub. So that's the super cool like magical review. I know a lot of you are probably gonna want a copy of the bootcamp itself, which again, just check INE in a couple of weeks, the editing team, the production team, they're gonna be awesome. They're gonna put that up there. But maybe you wanna leave something on Friday or leave with something on Friday. We got you covered. All of you will know exactly how to interact with the repository that we used through this bootcamp. And you're gonna get to take a copy of it with you. And that's gonna be super cool. Absolutely. I'm gonna be all set. So if we go fast, right? If we go fast and if you feel like you skipped something and you really want us to share those files and those notes, just know it's coming. You're gonna get absolutely everything. And you might even have visibility on all of our commit history along the way too. Yep. Without it being cool. And we'll talk about that. And one thing I wanna add in there real quick, Matt, because I'm looking at Matt and Brian, some of the stuff they posted into the chat. One of the best things about having Matt here to take us through this is the fact that if you've got a little bit of experience, you may have some events like when you go, cause I've been doing that work and I go, oh, I was doing that wrong. Or there was a better approach to it. For example, are we gonna talk about issues, Matt, in this particular bootcamp? I might have an issue with issues that we'll discuss. Yeah. See? And the proper use of issues really, I could not believe I had missed something that was right in front of me as an absolutely game-changing tool in terms of improving the flow of work, improving the flow of communication. It really does change the game. Also when it incorporates with things like the board, which I think we're gonna talk about that too, aren't we, Matt? About what? I'm sorry, I didn't hear that. The board. Oh, absolutely. Yeah, yeah. So- We are gonna do quite the deep dive into a lot of the service level features. Yeah, so as you guys are going through this, not only is it a learning experience, but for those of you who have a little bit of experience, I would open your mind to the possibility that maybe we're doing it wrong, because I know I have been and Matt can show us the right way. This looks like we have a question. How does GitHub provide us all of this? Is some of it free? Yeah, so there is no catch. Like that's the craziest thing. Yeah. And I'll dive into that in the next section. So just hold that question for a second. Let me set these expectations. And that's actually what we're gonna start with, because I totally agree with you. Such a great question. How can it be so great? Yep. If there's no catch. If there's no catch, Matt, and the catch is there's no catch. Like that's the craziest thing about it. Again, I'm gonna get overly excited because I'm just passionate about this tool because of that right there, the fact that there's no catch. It makes no sense. It makes no sense that this is free. Right. So here's the expectations for the bootcamp. Let's set a couple of things up. First and foremost, we are gonna hound on GitHub. It is gonna be the focus of the next three days. Most of the stuff we talk about, brand strategies, issues, version control, collaboration, it does apply to other platforms, right? Other platforms are like Bitbucket and GitLab. This isn't to say that they don't solve this problem either, right? This is just to say that this is Matt's tool of choice to solve this problem. Feel free to use your tool of choice. A lot of what we're gonna talk about will transfer, okay? So if your company uses GitLab, don't think, oh shucks, I'm not gonna get anything from this. Same principle, right? It's just like Azure and AWS. They all offer kind of the same thing. Same thing here. Just a different name. There's different company, different tool. Okay. The next expectation is if you're looking for a specific recipe on how to solve some very niche problem, I apologize ahead of time. You are in the wrong place. We are gonna talk about leveraging this tool largely in the sense of collaboration and automating some of that collaboration. We're not gonna talk about how this tool fits into the DevOps pipeline in depth. We're not gonna talk about how GitHub provides you with this super rich history that allows you to roll back bugs that made it into production in depth. We'll touch on it, but you're not gonna leave with how to solve my specific problem. You're gonna leave with how to start thinking about using this tool to solve your problem.  We might do a little bit of that, but the focal point is not that. Does it help you understand Tanzu, Kubernetes? It's gonna help you understand keeping the version control for your manifest in order. It's gonna help you understand working with other DevOps engineers to write those manifests. You're gonna be able to do code reviews on those manifests. Again, it's gonna help you understand the collaboration part behind it. Are you gonna learn anything about Kubernetes in this? Nope, not at all. Nope, but it's going to help you do Kubernetes better. Absolutely. With those manifest, Matt, that is such a big deal because the collaboration with a worldwide team, that's the sort of stuff that we had at AWS, you can easily and quickly share. You can look at the differences and you can make suggestions. It's just fantastic, Vijay. I think you'll really enjoy it and learn a lot. Again, we're not gonna be diving into Tanzu, Kubernetes, obviously, but you will have the foundation of going, ah, I see a better way. Exactly. There's a lot of things you would get from GitHub that we'll talk about along the way. The security features can help with those manifests. You may have been in a situation, you wouldn't be unique if you were, where a sensitive API key or password kind of got stored in a file somewhere. I know someone that could be guilty of that at some point. GitHub helps with that type of stuff. Yeah, it does. So those are the major, major expectations. The last one that I wanna hit on is that this is a 100% participation kind of thing. We're gonna build in some time for you to be able to do some of the stuff that we're working on. And because of that, there are a couple prerequisites that come along with this. One, I'm assuming is a bad assumption, but I'm assuming you got a web browser. You have access to Chrome, Safari, Brave, you should probably be using Brave, personal opinion, whatever it might be. You have access to a web browser and here's the catch. You're on a network that can reach github.com, okay? So if you're VPN through work, you can't get to the GitHub website. You're gonna have a bad time getting it fixed. Let's make sure you can get to github.com. Outside of that, those are your only prerequisites.  Just be told, you don't even need to have git installed, okay?  Again, this guy, but that's okay. Again, we're driving home different concepts. All right, the last thing is if I go too quick because I get crazy excited in chat, say, Matt, you're crazy, slow down. You've had too much coffee. Let Brooks talk.  Whatever you need to say, throw that out there so I know to slow down, okay? Oh yeah, because I talk slow. Absolutely, man. Exactly, exactly. So are you gonna show how to do stuff with both Windows and Mac, respect to just one plot twist? I'm gonna use Linux. So, everything I do is gonna be on Linux and I can give you from the stuff we're gonna cover, it does not matter what operating system you use to truth be told, if you wanna be fancy, go grab GitHub Mobile and do all this from your phone because you can do that too. So the operating system is not a factor, right? It's all on github.com. So it's gonna be all through your web browser. So your operating system doesn't come into play at all for this. But that being said, if you wanted to do certain things locally, you could use Windows, you could use Mac, you could use Linux. I use all three depending on what I'm doing in my daily life and I use GitHub for pretty much virtually everything all the time. And hopefully you'll see why along the way. So don't feel like I'm on a Mac, I can't participate. Don't feel like, oh, I'm a Linux user, I can't participate. Again, if you have a web browser, you are good to go and it's that simple. Good questions though, I appreciate them and you're thinking in the right position here. What's really cool though, before we jump too far, when we get to this GitHub action section, you'll learn that GitHub actually supports all of these operating systems for its automation, right? So some of you might be deploying infrastructure on Mac or that is Mac-based infrastructure. Others might be having using Linux-based infrastructure. Some of you might be writing applications for all these different operating systems and GitHub is built to handle all of that. So I know when Brooks and I collaborate, he often uses a Mac and I use my Windows machine and we make commits to each other and you'll see throughout the interactions we have in this bootcamp, it might be helpful for you to know this, just based on this question. I'm gonna be on a Linux machine and Brooks is using his Mac. So as you see us interact with one another, that's kind of the ecosystem that we're working within. And you'll see that he can collaborate with me just fine through this.  No, we are driving a tight ship. We will never, ever take a break. So... No, we will be having breaks at the top. Yeah, we'll be having breaks at the top of the hierarchy. Sorry, that was on everyone. My fault too. Always breaks, always breaks. We will be having breaks and what we'll be doing is either at the top of the hour or just whatever is opportune, we'll be doing in there. So yeah, expect those everyone. Yep, absolutely. We gotta step away from these lights a little bit as the time goes on because it's a little warm. Oh yeah. All right, so now in order to request a break though, you're gonna need to submit an issue. That sounds gonna work for breaks. Okay, so we're gonna start, I'm gonna throw up a quick poll, right? Before we really dive into this, I have just a couple of true, false questions for you guys that I kind of just want everybody's, again, participation on. So let's take a look at this statement. GitHub provides developers a place to store project source code. You think that's true? Go ahead and hit true. If you think it's false or you're unsure, go ahead and hit false. And as soon as we, yeah, that's great. Awesome. We got 12, how many other people? We got 29 people. Nobody disagrees that this is true, huh? Oh, some people, we got maybe unsure, okay. We're gonna call it unsure rather than false, right? Because that's important too. Cool. So you're right, right? This is how GitHub is known. It's known as this tool used for, here I'll share these. Everybody can see the results. This is known for hosting billions, if not trillions of lines of source code, right? From developers. And that was its primary purpose when it was first developed. It is now not the case thanks to things like DevOps, right? The push for DevOps said, we need our tooling to do much more than just be a simple version control interface. Let's jump to the next one and take a look at what that has to say. I'll launch this poll for you. GitHub users need extensive command line knowledge. This is something I hear quite a bit. So let's see. See what people think. I wouldn't be surprised. Yup, yup, there we go. Making a little more sense exactly, right? There's this idea that this is true, but some of you might've thought this before this question came up, but if you tuned in just a tad while we were talking throughout this intro, I said we're not gonna use a command line at all. We're gonna go all through that web interface, right? So that's the awesome thing. Think about this when you're trying to talk to your teams. Let's say you have your production team, okay? We love them. They're not developers and that's okay. So GitHub is foreign. It's a foreign tool. It's as foreign to them as Adobe Premiere Pro is to me, okay? They might, your HR people, same situation, right? They might be intimidated to jump into a tool like this because the assumption is that they're gonna be in a terminal using all these command line commands to get any work done and they don't wanna star in the next hacker movie, which they should, because that's a good movie. However, this is a common misconception. So I'm glad that a lot of you seem to have picked up on that or knew that prior. So here's the next one. We're gonna do this for an hour, okay? So get comfy. Placing code on GitHub means my project is open source. Let's see where we land with this one. That's a big one right there because there's a lot of managers if you go to and say, can we put this on GitHub to try to do collaboration? They're real quick if they've been misinformed or if they don't understand or gonna say, wait a minute, anybody in the world can see that. Exactly. And this is just a judging thing for me, not to judge you but to just talk about how this is affected. All right. So this one is a little more split, okay? And this is a very common misconception, right? And there's a reason for it. You'll see when we get to the GitHub webpage, it prides itself on being the home of open source projects. So you see that and it's really easy to immediately think that anything I put on GitHub automatically becomes open source. The actual answer to this is that that's not true at all. Not at all. You can have completely proprietary stuff on GitHub and you can keep it 100% private to your organization. Why does this matter? Well, think of the context we're talking about GitHub in, using it for non-code things like your hiring policies, your job descriptions, right? If let's say your team is hiring and you post the job roles, responsibilities, all that in a file on GitHub that everybody in your organization can see. You've now made it easy for all of your employees to know exactly what the company is looking for and somebody can jump in and say, hey, you said that you want a DevOps engineer, but you're expecting them to have 35 years of Ansible experience, that's impossible. Can let me just edit this and fix this for you to something that's more realistic, right? And these things can happen. And that has nothing to do with open source versus closed source, right? So that's gonna stay 100% proprietary to your company. It's not a code project by any means. And that's a huge misconception that hopefully we can clear up for you. And Matt, if I can just jump in here real quick, that is a major sore point for me working with different companies, particularly HR, the HR departments who've been doing exactly what you said, they put together these descriptions for like a DevOps engineer for AWS. I look at what they've posted and it makes no sense whatsoever. It's not their fault, okay? They're in HR, they're not, they don't particularly care to know about AWS, how long it's been around. So when somebody says, and I've seen this before, somebody said, must have 20 years of AWS experience. So I was like, okay, that's neat. I know of no human being on the planet, including Andy Jazzy, who helped lead the whole thing, who's got that much experience. So when you get into a collaborative environment, and this is why we call this GitHub for everyone, this could be the place where HR puts the wreck out and reaches out to everyone and says, hey, does this make sense? And you can collaborate real-time and really put together a tight document and it's so easy to do. It's actually to the point of, I think, Matt, maybe you can agree or disagree with this, where it's almost to the point of, it was a mistake not to use it. Yeah, well, I would absolutely agree, but I, again, super passionate about GitHub itself. And honestly, that statement of it's a mistake not to use it is not a GitHub-specific statement. It is a version control kind of specific statement. So you should be using something like GitLab, Bitbucket, GitHub. There's others out there. Those are just the major three players in the space. Your teams are gonna benefit exponentially from the ability to collaborate on stuff like that. It's a super easy fix, right? And let's face it, maybe that person that drafted that job requirement for 20 years of AWS experience, maybe they meant to say two and they accidentally bumped a zero on the keyboard. The fact that you had 100 pairs of eyes on it means that you caught that before it went out and it took all of five seconds to fix, which you'll see, it'll be awesome. All right, on to the next one. It is difficult to navigate the GitHub website.  If you've never been, we can go with true. Here's the kicker behind this question, it's kind of a gotcha in that the GitHub website, so GitHub, fun fact, GitHub builds GitHub using GitHub. So what I mean by that is all of the source code for GitHub is on GitHub. It's closed source, by the way, at least part of it is. So all of the source code for GitHub is on GitHub, which uses GitHub to then deploy GitHub to its cloud environments, okay? And there are DevOps product, and there's DevOps all throughout GitHub, which does many, many, many, many deploys a day. I'd say on average, probably 50 deploys a day to all sorts of stuff. And that causes this website, the actual web application itself, to change very frequently. One of the best things about being on staff is I got to see all of those changes really early because I had what was called a staff view. So I could see the features come and go, but it also made work really hard sometimes because buttons would move, they would disappear, I would get super cool new features that were useful, and then they'd take them away for some reason, but expect this to be very fluid, exactly, getception. It's gonna be fluid, so if you find it hard today, it might not be hard tomorrow. And if you find it easy today, your time's coming, don't get comfy, your time's coming. All right, we got just a couple more of these, and then this is really gonna help us, and then we'll stop beating this poll horse. GitHub helps project managers view work in progress. I like this question, Matt. I know you do, Brux. I know you do. I like it. I know. Yeah, that's awesome that everybody agrees on this. Now, my follow-up question would be, do we know how? And I bet that's where some really cool mind-blowing stuff is gonna show up. When we talk about how project managers can view this work in progress, because it's much more than just being able to see what changed or what's in the process of changing. Some through insights, we'll take a look at insights, mostly through projects. It's kind of a collection of all of it, right? And if you know where and how to look, using tools like insights, projects, poll requests, issues, the whole thing, you'll see, you'll start to form like this entire map in your head about exactly how fast and how on pace a project is, how behind it is, who is taking on what responsibilities for that project. As a project manager, you'll know who to ping and slack and say, hey, Brooks, I need you to do that review, man. It's been sitting there for two weeks, what's taking you so long? And Brooks is like, I just forgot about it. How about that? And then he goes and he checks it and he takes care of it. And as a project manager, instead of chasing Brooks down for four days, trying to get something done, it was one ping and slack and your job is now easy because Brooks went ahead and took care of that really quickly because he had the right tools. I like the converse argument on that one, do what they called me up and then say, hey, why haven't you done that yet? And I can say, did you not go check GitHub? Exactly. Did you not go check? All right, two more. GitHub is a tool for development teams. It's another check question, isn't it? Exactly. Yes, it is a tool for development teams. It's not a tool limited to development teams though. And that's a huge misconception. This comes every time you look at something on the internet for a course on GitHub or you're in college or whatever, it really seems like this is only for devs, right? Or maybe dev option engineers at this point. And honestly, it's just unfair. I would, when I used to travel, I would use GitHub project boards to build my packing list on what I needed to take with me. And I would just slide the cards over as I packed. So I've used this for all sorts of things. And that's when I say firmly believe in it. It's because I've thought of very creative ways to use the platform and it really helps keep me organized. All right, last one. And then we'll get on to talking about some of these accounts and we'll get back to that catch. Knowing how to write code is necessary to use GitHub. He's a little bit of a trick question, but not much. I can very easily divide the room with how I do it. Now that's gonna say, you did put some tricky ones together, man. This is tricky. Yeah. Well, you know, it's graded, so get it right. And then we'll be fine. Cool. Majority of you say false, which is great. Oh, we switched. Yeah, no, we didn't. Okay, sorry. Which is great, most of you say false. It is not necessary. We have a couple unshers, most likely. I could easily divide the room by saying GitHub has its own language. It's not really a language. It's a markup format for writing awesome documentation. And we're gonna spend some time doing it. And it's gonna, at first you might be like, man, why am I doing this? But once you start using it, you're gonna realize that you can make documentation that is intuitive and has all the cross-linking you could ever want into it and examples and everything really, really quickly. It's, I've used it so much now that I find it really hard to write Word documents or Google Docs documents. I can't use regular Word processors because it takes too long to format them. When, if I use Markdown, it's really, really fast for me. I think I'll go a step beyond that, Matt. I would actually go as far as to say is that I think it's gonna become a required skill. I hope it does. I hope it does too, because at the end of the day, when we're talking about comparing very large documents, again, something like HR where they're setting some sort of legal precedence that's gonna go throughout the organization. And this is a multi-page dense document and somebody wants to make a change to it. Being able to quickly find that change, Markdown set up for it perfectly inside things like GitHub. And so then why am I dealing with this giant document with embedded control characters that I can't even see that when I try to do a diff it's just gonna go nuts. So with that said, Markdown, just everybody, it gives you so much more capability. I don't, let me get off the soapbox on that one. It's a skill you need. We'll touch upon it here. Yeah, we're gonna do some cool stuff with it too. So it might seem a little drab at first, but we're gonna do some really cool things, at least in my opinion. Absolutely. All right, so what is GitHub, right? We've kind of answered this along the way. So I won't beat this horse too much. It is the industry leading tool for source code management, right? And it is becoming, or it's trying to become an industry leader in all things collaboration and project management, right? To include the source code that goes along with that. It really wants to be your entire DevOps one-stop shop. And it's working hard to do that, it has a long way to go. And that's okay, that's our space we constantly iterate, right? GitHub is so important to the world that it is ready for a disaster recovery situation. Fun fact, okay? Wow, that's true. GitHub has more source code on it than any other platform, right? So most of the world's open source projects are on GitHub. So much so that GitHub believes in a disaster scenario they could recover most of the code that is in existence today. They actually purchased, you could look this up. They purchased space in what is called the Arctic Code Vault, right? It's in the Arctic Circle next to the seed bank. We're probably all familiar with the seeds that are stored up there so that we could replant the earth if we needed to. Well, about a year ago they took a snapshot of all of the public repositories on GitHub. So all of the code in the public repositories and they stored that on a drive in the Arctic right now and they updated every now and then but it's stored and ready to go in case of a disaster recovery scenario where we need to restore a bulk of the world's programs. And that's how critical good version control and actually keeping track of this stuff is and that's how widely popular this tool is that there's not much code that we could probably rebuild the world which is mind blowing to me. What's really fun is if you had a GitHub account prior to this, now have a really cool little badge on your GitHub account that says that you're an Arctic Code Vault contributor. So that's super cool. So that's look, that's a little about GitHub, right? We're gonna dig more into it with the Arctic Shows Rapidly Nothing. Should I be concerned that my strawberry seeds will be lost?  Right, if you're 70, you don't need, you don't care about those seeds, right? If you're 20, strawberry shortcake might be off the plate later on in the future here. So- Oh my gosh, how did we get on that subject so quick? What strawberry shortcake? How do you not get on that subject? I don't know, man, but we swerved right into it. All right, so that's the GitHub, right? We need to expand this thing to be much more collaborative in our regular work because if we're doing that with source code, like what if we did that with hiring processes? What if we did that with inner team connectivity processes? What if we could recover that in a disaster recovery scenario, right? That's kind of cool. All right, so let's jump into these GitHub accounts.  We're gonna talk about GitHub accounts as a whole, okay? Hey, enough of the slides. So if you've ever been to github.com, you're greeted with this super cool screen, changes all the time, right? This is just one of those things they do. They give you some really cool stats and you're prompted to sign up, okay? I already have an account so I'm not gonna go ahead and sign up again. And this is kind of a teaching point. One of the things that comes with GitHub accounts is that you shouldn't have five of them, right? Ideally, you use the same GitHub account for your personal projects as you do for your work projects. GitHub is like built for that. There are plenty of checks and balances in place that ensure that I can't accidentally merge the two where they can't see each other or whatever it might be. There's no harm in using the same account for those things. As a matter of fact, like you can be a part of many groups with the same account. But if we look at some of the pricing, right? This is the gotcha going back to that question. Look at this for, ah, compare features, right? For an individual account, just a user, a regular you and me, it's free, zero dollars. What do you get? Well, unlimited public storage, which is great. Public means Brooks and I can collaborate with you. Public means somebody across the world can collaborate with you. Maybe the DevOps engineers that you were talking to in Discord want to help you with your Kubernetes manifest. So you send them a link to your public repository. And guess what? They help you. But what if it's work related? Or what if I have a super secret Tony Stark project that I'm working on, go Ironman? Well, I can also have private repositories, which means only me or who I allow can see these things. And all of this is free, but this is where the gotcha comes. Look at this, no access to code spaces, right? So what code spaces is, I'll show you, it's an online editor, a text editor. You don't need it at all. It's not something you need in order to use GitHub. It also, there's a reason why it's not on free accounts. It doesn't really benefit the individual user. It really benefits the team or the organization or the enterprise. The reason for that is your developers or whoever's working on your stuff would never need to put a local copy on their machine. They could do all of their work on GitHub without ever having a local file on their machine. If you're just you, that's totally fine, right? You're not running away with company secrets unless it's your company, right? So that's one of the advantages and that's why it's not included. This stuff, this actions minutes. Hey, look, you get a little bit less. This is the catch, this is the gotcha. The free account gets 2,000 minutes. The enterprise gets a whole lot more. But look at this. I don't know how well we can see that, so I'll zoom in. Free to public, free for public repos. How about that? Free for public, right? Because GitHub does focus on open source in collaboration, the more stuff you do publicly, the more features you get. That's the catch for free. You're gonna get more stuff to do it publicly. Same thing with packages. You want to store Docker images on GitHub? What? Might not even know you could do that, but you can, right? You want to store Docker images on GitHub or NPM packages or some of the other artifacts that you're building? That's great. You get 500 megabytes of storage for free in private repositories. Public, unlimited, it's free. It's great. Yeah. Can you take a second real quick here, Patrick has a question and just briefly, because I know we're gonna talk more about later, what exactly is actions? What does that do for us? Actions is an automation tool set that's built into repositories and they execute over time on virtual machines. So when it says actions minutes, it genuinely means that let's make this, hopefully bring it back to something we all maybe understand a little differently is, let's think of an AWS EC2 instance, a virtual machine in the cloud, right? We turn on that virtual machine and we start paying for it by the minute, right? For every minute the virtual machine is on, we get a little bit of charge. GitHub actions is the same thing. For every minute, what's called a workflow, which we'll dive into, for every minute that workflow runs, it's accumulating those minutes. So if you hit more than 2000 minutes, you won't be able to trigger another workflow for that repository. What's crazy is this is a repository basis, okay? So like, let's say you had one private repository. Well, you get 2000 of these action minutes before you have to pay for them. There's the catch, right? Like you could buy more minutes. You could also just create a second private repository and get 2000 more minutes or a third private repository and now you have 6,000 minutes. And if you're slick, you can kind of link all those things together and have unlimited private repository minutes if you did some finangling. And I say that, and I don't know if it's against the terms of service, I haven't dug into it that much. I do know that I've done that for like a lot of proof of concept things for GitHub themselves and nobody's ever like scolded me for that. So unlimited though for public. So this is just quite literally how long your automation process takes. And to kind of put a button on it for you, Patrick, when we're talking and for everyone who's watching about what actions is, one of the things I've used Actions Forged personally is I like to use a framework called Pulumi to create AWS architecture. And basically you write it in Python. And then what I can do is I can push that code up to GitHub and then via GitHub actions, that is the compute time. That actually reads my code. It will create my architecture for me in AWS. And there's a lot of examples of things like that, for, you know, particularly with containerization, deploying containers, the time that it takes for their servers to kind of crunch what you've done and put it out there, those are those minutes that Matt was just showing us. And I think it kind of, I mean, for me personally, Matt, it's one of those moments where I cut my jaw drops a little bit more, because I realized that was free. I did that at no cost. What's so flipping ever? If you went to go hook up Azure Pipelines, you're paying for that. Oh my gosh, AWS y'all? You better buckle up. It's so nuts that it's free as long as you're willing to be public. Like that's like, okay, how many of us have learning experiences when we're trying to figure these things out? Like just set that stuff up for free in a public repository. It doesn't look bad on you if you learn something, right? Like that's why you're here. Like you're not ashamed to be in this bootcamp maybe because you're hanging out with Brooks, but for the most part like you're here so you embrace learning. So why not make that public and get it done for free? And it's not free like Google offers you. Here's $300 in credit. No, it's just free. Like I can't unfree it, it's that free. Well, not to mention this whole thing that you and I have talked about so much when we talk about this engineering stuff that we're working towards. It's the idea that when you're sitting in anything including our videos where we're teaching you something use GitHub, create yourself a little repo based on what you're learning and put your notes in there because of two reasons. One, obviously it's gonna be your notes but two, when you get to that job where you need to remember, wait a minute, Matt, tell me how to do that in GitHub. You can just go to your GitHub repo and look at your notes right there. And this is again why I'm talking about markdown is such a big deal because GitHub will render your markdown very beautifully. So you've always got that stuff available and as bonus points, when you go into that job interview and back me up on this one, Matt when you go into that job interview like we were talking about Kubernetes and they say to you, how would you do that? Nothing, I'm gonna pound the desk nothing will win the day like you're going, well, actually, if you want to let's take a look at my GitHub repo I've actually got some code like that. You've just won the interview. Exactly. And then when you start, you might run into a problem you're like, man, didn't Brooks teach me how to do that with a script in that course? Like you have that script. Just take it to work with you, right? It's a toolbox. So again, what's the catch? Let's go back to that. We'll circle back to that. Well, if it's public, that means everybody can see it. That's the catch. What does GitHub get from this? More code to put into the Arctic Code Vault. There's also this thing that we're not gonna dive too much into detail. It's called GitHub co-pilot. It's a programming bot that you can tie in to like Visual Studio Code and it uses AI to suggest code snippets for you, right? You can actually write a whole lot of code without ever writing code. The data in the code used to train co-pilot comes from public repositories. So what does GitHub get from that? They get to make their stuff better because they can analyze the things that are taking place in the community, right? So that's the catch. GitHub gets to use your public stuff to make GitHub better for your public stuff. It's like that's the catch. So the other catch is there's tiers, right? You see zero, 40 to 10, this isn't exactly accurate. And again, this changes all the time so we're not gonna harp on the price. But what you do need to know is that this is for free, but what if I want some of these things to exist? Let's see if I can find one. Like what if I wanted required reviews on a private repository and I'm an individual user? I can sign up for something called GitHub Pro and it's not listed here, but it does exist, I promise. If for a whopping $4 a month, so what a third, maybe a quarter of the cost of Netflix at this point, you can enable a lot of these features in an unlimited fashion for your private repositories, okay? So like that's what you get out of the upgrade is all the stuff you can do in public repositories, like you get in the private ones. You're also not gonna get support, but that's okay. You're not gonna need it. That support is for like the enterprise servers and stuff like that. It's not for .com. So GitHub has like a lot of different things like product skews, right? So there's .com, which we all use, but there's also enterprise server, which if you're an enterprise admin, maybe you care about, but for this bootcamp, we're not gonna dig into the enterprise side all that much. So then there's team, which is also called organization. They go back and forth between these terms. It looks like it's team today. This is where you want to have like a core group of people you wanna work with. So I'll give you an example. I have a small group of people that I typically work on projects with. We try to launch startup ideas on a regular basis and we use a team or an organization to do that. So all the repositories for our stuff exist inside of this team realm.  And I'll show you what that looks like once I log in. I'll show you an organization that I'm a part of and I'll show you how we can all see that stuff. And I might even, I don't know if I can create another one. The limit is if you don't wanna pay for organizations, so here's the other thing. It says team is 40 bucks, but it's not. Like it is, but it isn't. Like you can create a free organization that kind of inherits all this free stuff that we have, oh, sorry, from this column of free stuff here, it kind of inherits that. But as a team, if you want to upgrade your team to do more intense private kind of collaboration then you can do that for a fee. There is no such thing as a free tier on the enterprise, okay? That's the catch is there's these free tiers that are offered that offer you pretty much all of the functionality on public repositories. There is a small fee for the quote unquote pro versions of those account types that give you the access to the advanced stuff on private repositories. And then there's this outlier that's enterprise, which that's probably a decision that's a little higher up on the chain than us. But that allows you to run GitHub on-prem, right? So you're in that situation, maybe you're working with a DOD, finance health, something highly regulatory that says, we can't use a cloud product, well, we can get you GitHub on-premise, you just need enterprise to do it. So we're not gonna harp on that, but that's a huge thing about the account differences in the account types. So I'm gonna log in really quick to my account for you guys. And look, this is my username and I'm perfectly okay with you having that. It doesn't hurt me, it's public. You guys should absolutely go look at some of the repositories that I have, excuse me, I have to authenticate, which we're gonna talk about, which is why I'm logging in. So I'm gonna use my two-factor authentication code. If you steal this, it's okay, it's about to expire in a whopping 10 seconds. And here we go. Okay, so same screen, but if I come over to my profile, you can see I have a user account. It's no different than what you would have when you first sign up. This is the Arctic Code Vault contributor stuff, which is really cool. But at quick glance, so this is the individual user account, right? This is a personal account, not an organization account. Let me ask you about that, Matt, real quick, because I think this is interesting. This is your personal account. Yeah, absolutely. This is the exact same account that you use to interact with me all the time inside the INE space or anything else that we're working on, correct? Absolutely, and yep, and I'll show you exactly that. So that's a great question, actually. I only have this account. This is my only GitHub account, period. I use this for learning, I use this for work, I use this for personal projects. I use this for notes. I genuinely use this for everything. Well, the reason I ask is, and I think it's probably been about two years ago, I worked with an organization up in the Boston area. They actually had separate logins. When you came to work, they had their work-based GitHub account. And I remember looking at that thinking, I think that's a bit inefficient. I think that may not need to be the case. It is 100% in contradiction with what GitHub recommends as the best practice. The best practice recommended by GitHub is you just use one account. It's easier for them to gather the right metrics to help the community if you're doing that. It makes it easier on you. You don't have to manage different logins. Like I just had the two factor my way in. That's one security feature. There's like, what if I had access tokens, another security feature, which we're gonna dive into in a second, for all these different accounts, and I forgot to roll my tokens or whatever it might be. It's just better for me and better for GitHub if I have that one account. It's also better for your organization because like INE, for example, has an organization in GitHub. They didn't create me a brand new INE GitHub account. They said, what is your GitHub handle? And we invited me into the organization as me, okay? So what's really cool about this at first glance, right? Public, first and foremost, 143 repositories. Now, if you think that I have 143 software development projects that I've worked on and deployed, you'd be sorely mistaken, okay? Public, public, public, public, wait a minute, we see a theme. The guy with 143 repositories that spends some time at GitHub as an employee has a lot of public repositories, okay? But it's not limited to that. If I'm sure, if we look through here, look, private, private, private template, right? These are different repository types which we're gonna jump into so don't get hung up on that right now. Don't try to steal my Harry Potter voice react app either. So there's that. I'm kidding, you can't steal it, I don't think. If it's public, it's open source. And you can get it. Yeah, and it's not even a remotely complete project. I was teaching somebody how to do some react stuff. So again, collaboration, right? I do a lot of mentoring with people that are like going through like web development boot camps and oftentimes I will create a repository and we will collaborate in my repository, hence the Harry Potter react voice app thingy. So this is my profile. It's just like anything else, anything else social. Like I can have followers so people can follow the work that I do. I can follow other people. I can have like these are Docker images. This is an MPM package, whatever it might be. I can have all these things and they're all associated with me to a degree. If I come down here though, we see organizations and if we go and we click on this one, this is an organization that myself and these other people are part of, okay? So this is an organization account and we can see that this is private and this is private and this is private and this is public or whatever it might be. And this is at the organization level. This is where we can do fancy things like manage teams, right? So I can create a new team. If I wanted to, I could come in here and I give it its name, its visibility. I can create secret teams. I can't do these things as an individual. It doesn't make sense for me to create a secret team in my name space. So that's the big difference between organizations and users is you get like this name space where you can do people management, right? So I can say, hey, like here are all the people in this, right? And what their permissions are and who and what they can see, okay? So we're gonna pop out of here and we'll go back to my personal account so now we're back to the personal account and you'll see I don't have the ability to manage people. Just don't because I don't need to. This is my individual account. So if we look at I and E, I hope we can look at I and E. I think we can look at I and E. We just won't click into anything. We can see, here's this. We can typically see who's a part of it, right? We see there's 18 different teams and that's because I and E is an organization account and it also contains stuff like this. If you were to go to the URL github.com forward slash internet work expert, you would land on like a public splash page that you probably wouldn't even see that this exists. You would never know that this repository is real because it's listed as private. Same thing with my individual user account. If you go to github.com forward slash Matt Davis 0351 I'll even copy this for you and I'll put it in chat just in case anybody wants to. You're not gonna see any of the private repositories I have and why is that? Well, it's because that's one of the security features is I can decide the visibility both at the organization level and at the user level. I give more control at the organization level. I can set up when I create my teams, I can say, Hey, Brooks is just a member or he's an admin or he's an owner or he's a maintainer and all of these give different levels of rewrite permissions, okay? So if you wanna go there, you can. Another quick thing on your profile is you get this really cool contribution graph. I think it's safe to say I use github just a little bit. There's been a lot of contributions in the last year in 2022 already. I think it might go for the whole year, but whatever. And I can see where those contributions are going, what they're coming from. I can even scroll down and see my contribution history, okay? So let's pause for two seconds and think about this from that project manager point of view. I need to know if Brooks has been working on something or what can I do? I can just go look at his profile. I can scroll down and I can see, oh, Brooks created four repositories, Matt created four repositories, right? Oh, look, there's open pull requests. Not only did this person open three of them in two different repositories, I can quickly see their status. Two of them have been merged, one of them is currently open. What's a pull request? You gotta wait a little later for that. Yep, but immediately on just me, I have very quick, like a 30,000 foot view on what my activity looks like. There's something missing here though that we're gonna work on, it's gonna be kind of cool. Let me jump in here with a question real quick, Matt. Go ahead, Matt, I'd love you. Before we go to break. So if I create a GitHub account and I create a public repo, boom, it's out there for everybody to see. What about if a situation comes up? Well, let's say I want to show off, let's say I've been working on my skills with Rust. And so I want to show off some Rust code. Can I take a private repo and move it to public? Okay, everybody, welcome back. Before we get started, I actually want to ask everybody a question. We don't have this ready as a poll question. It's just something I'm interested in to see if anybody's noticing this. So over in the chat window, if you want to answer yes, no, true, false, one, zero, don't care how you want to do it. I've got a question. Has anybody caught because I didn't know Matt was gonna do this for us? Honestly, I did not know he was gonna do this. Has anybody caught onto the fact that he's been giving us inside info? And I'm not talking about things that you can't find out. It's just things that are hard to find out about GitHub. I'm just curious if anybody else has noticed that that's going on. Because to be honest with you, I didn't catch it until just a moment ago.  Yeah. Giving you all the secrets. Yeah, I know, right? Didn't notice. Patrick didn't notice. I didn't either. Exactly. Oh, okay. Oh, Brian. Outstanding. Remember what I said when I started that this is my VM. My personal computers went like, so I only use this VM to teach. Like when I use things regularly, I am in dark mode. Hands down. No excuse. No excuse. I think it shows better on video. We'll play, Brian. I don't like the way it looks. What's really cool is you mentioned dark mode, but I had dark mode on GitHub before it was cool. Oh. I had that staff hookup, right? So I've used like five different, five different dark mode versions for GitHub. Matt doing wheelies in the parking lot. Making us look bad. Yup. So cool. Yeah, I just want to make sure everybody was aware of that. There are things that Matt's teaching us about GitHub, things that he's taught me as well, that it's out there in the documentation. You can find it, but it's just gonna be hard for you to do. So you're getting a little bit of insight, although public info about how we can use GitHub really, really effectively. You might be able to quickly see, I get like feature preview still. Let's see if they quickly have dark mode enabled. See, there's just too many. There's just too many. You want dimmed, you want default. See default's kind of harsh, right? It's like really black. We'll switch it to dimmed. Ah, Dracula. There we go. All right, let me come back to my profile. All right, awesome. I don't think that shows better, but we'll take your word for it. All right, so let's talk about security around the user account. And then we'll talk about security in organizations, okay? So before we move forward on that though, take the time if you didn't do it during the break and create a GitHub account. Just go create a free individual user account. We're about to get into some interactive stuff that you're just gonna get so much more out of this if you have an account ready to go. Like if you don't have two-factor authentication enabled, I'm about to show you that. If you don't have scoped personal access tokens, I'm about to show you that. And these are things that you can apply right here, right now to your GitHub account. Hold on, Matt. We have reached a teachable moment that I have to slam on the brakes and ask you about. Now, this is what it is. Everybody, please pay attention to this one. This is something. One of the discussions you and I had very early about GitHub was talking about sort of the professionalism of what your account looked like. I was really concerned about the idea that I could have some goofball account over here. And I didn't really wanna show it because it's got like, I used a goofy icon for myself. I didn't use like a personal picture or anything like that. Or I didn't use my name. I used something like just whatever I made up. Talk to me, and this is really insider stuff here. Culturally, when we're talking about GitHub, does that even matter? It matters in the sense that you shouldn't think about it. You, like when we had that conversation, you had overthought that. So for example, if we're looking at my profile quickly, this is my name, right? Like in that form of like setting up your profile, like this, I could change this to Bobby Boverson. I'm probably actually gonna change it to my crypto domain name is probably what I'll change it to. However, this is what's called my handle.  For example, I tried to get the handle MD, but like EMDE when I got hired at GitHub. Because everybody is referred to as their handle and MD sounded cool and it would look a little cool. It could have just been a goofy little thing. A lot of the people I knew have fun handles like Hector Sector. That's a handle of somebody I know that very professional still, Beard of EDU. This guy, big, bushy beard and he runs around doing enterprise level enablement. So Beard of EDU. And you just kind of get known is these handles. So you don't have to be super clean and proper with it. Like I went and I had to throw some numbers on there that are sentimental to me, but they just does a lot of Matt Davis is in the world. I'm not very unique in that sense. But I had to do that to get something unique. And then hindsight, if I could do it all over again, I would have a much cooler GitHub handle. Same here. Than what I have. The other thing is like, you're gonna find in the documentation and all over the place with GitHub, emojis exist everywhere, right? And it's just this culture that exists for this tool that says loosen up a little bit.  As long as you don't have something obscene or offensive as a handle, you're good to go.  I know very few people that within GitHub specifically that use anything related to their name. I know an Admiral Ackbar who clearly is not Admiral Ackbar. That's his handle. Like you're gonna find a ton of really awesome stuff out there. So as they're creating these accounts, if they're really fretting about something like that, it's not that big a deal, I think is what we could say to them. Make it cool. Make it slick. Don't worry about, oh, I've got to really button this up and make it look exactly a certain way. That's not how this culturally in tech, in the cyber world, this is actually viewed. This is a little bit looser, a little more creative. So yeah, don't worry about that. If you're creating your account as part of this bootcamp or if you're in the future watching this as a recording and you're creating one, don't sweat that. Create something cool. And here's the thing is you can change this later too. But the more organizations you become a part of and like let's say it's a work related account and it's all like federated login and everything, that change could cause a lot of problems. But if it's just you on an individual user account like I am right now and I'm not, in some single sign-on situation with work or anything like that, I could change my username right now and I'd be fine. The problem is now everybody knows me as this. And like I don't want to change it. Hey, Benjamin's got a question for you Matt. Bad in your handle. Notice some problem using actions, pushing something to Docker, using the handle. The Docker does not allow uppercase letters. Yeah, so that's a Docker problem, right? It's not a GitHub problem. There's a lot of weird little stuff like that that you have to consider. What you could do, and this is a little off topic but I'll give you a quick way to do this. In that workflow file that you have for actions, leverage the GitHub actor environment variable to get your username, turn it into lowercase and then send that over to Docker. That's the actual fix for that. We're not gonna dive much deeper in it than that, but you could force lowercase so that Docker does things the way it's supposed to. The other thing is, is it doesn't matter. I don't think like when you type it into the URL, I don't think it matters if it's uppercase, lowercase. But what does matter is spaces. What you'll notice in all of my repository names, there's dashes where there's spaces and they're all lowercase. This is not a requirement. This is just experience bubbling to the surface and me having countless problems mixing case and not including dashes for spaces because plot twist, GitHub adds the dash anyway. So every time I need a space, I use a dash when it comes to naming branches, everything. And I always just do stuff lowercase. There's no like best practice for that. That is just, I've been beaten up by not doing it. So that's how I do it. So that's the quick fix to your problem. And then there's the potential fix is just trust everything in lowercase and question everything with next case. Exactly, exactly. Okay, so if you have an account, then all this will make sense. When you go to github.com forward slash your username, okay, you're gonna see this little profile icon on the top, right? If we click on that, we get all of this stuff. My profile, my repositories, my code spaces, my organizations, my enterprises, you'll see that I kind of fit in all of these, my projects, my discussions. Discussions is new, we'll get to that. My stars, my gist, these are all just different features and the most important piece is the settings, okay? In the settings, we can come down here to this whole access side of things, right? We can look at our password and our authentication. So if I want to change my password, I can hear and right here is what is important, right? I can enable two-factor authentication. Now, there are lots of two-factor authways. The way I signed in earlier was with the Microsoft Authenticator app. Why Microsoft? Well, that's with Microsoft owns github, there's your answer. Am I limited to that? No, that's just the app that I used. You can find the supported authenticator apps in the documentation for github. I can tell you right now, the Microsoft one works, it's easy. The second way is using something like a UB key or you Mac people with the touch bar. That little fingerprint reader also works as your two-factor to get in if you enable it. It's really slick, kind of cool. I don't know if the new Macs with their Apple chips like have any impact on that, but I know the old ones, I used to always use my security key. The security key that's configured is not a UB key, but this is where I would configure that UB key. You can also use the github app on your phone. It's another guest suggested way to log in to github and you can have them text you, right? So as you can see, I have a couple of different two-factor things enabled. And this is simply because if the authenticator app breaks, I can still get in through the mobile app. Or if I'm not on my Mac and I can't use the touch bar because I'm on a Windows machine, I can use the authenticator app to get in, right? Because I work in a lot of different environments, I have multiple two-factor authentication methods set up. These are really easy. This isn't configured. All I do is hit edit. You're about to change this, right? You get all of this stuff. I say set up using this, it will send you my authentication code. I hit continue. I go through these steps and I'm good to go. Now for me, I don't feel like doing the SMS one. I have enough, okay? But pick one, right now would be great. You could use the SMS one if you want, set up your two-factor. It takes two seconds, right? You also have these recovery codes. When you set up two-factor, you're gonna be given a set of recovery codes. Treat them like a secret, keep them safe. You can roll new recovery codes, but this is just helpful if for some reason you don't have access to any of your two-factor authentication methods, you can enter your recovery codes and get into your account, okay? So that is the huge thing. The other thing is like, maybe you're curious, uh-oh. Dang it, y'all know where I am. How about that? You can see what sessions are logged in and what devices, yes, I'm in freezing Las Vegas, Nevada at the moment. That's very cold today, all right? So that was obvious. If I have SSH keys and stuff, like they're here, but you'll notice I don't. I don't have any SSH or GPG keys. I don't have any of this set up, but I don't actually authenticate with a password. Time out.  On the website, I need to put in my password and then I'm prompted for two-factor. When I use automated tooling like GitHub Actions or Git from the terminal, I don't use a password at all. I use an access token, okay? So that is the next piece that I think is really important to set up. That exists under the developer settings. Such a strange place for it to be. It isn't, it isn't, right? Because it's typically for application or programmatic access, but it's still, I would like to see it with the other. Yeah, yeah, just give me something there, it says create this, because for those of you who ever want to start using this from the command line, the first time you try to do it and it says, give me your username and password, you're very quickly gonna get a message that says, we're not using passwords anymore. You need a personal access token. And that's the thing that Matt's showing us right here. Yes, yeah, if you try to use this from the terminal, you will absolutely get that message. So when you come to dev settings, you're gonna end up with three choices, GitHub apps. Like these are applications that you can write that act on your behalf and they interact with the GitHub API, okay? This is not the token that you're gonna paste in at that message. But if we look at what one of these might look like, is you can come in here and this is where you get like your client secrets, your information about the app, like where it's hosted, any type of callback URLs. If you're a developer, all of this stuff kind of make, a web developer specifically, all of this kind of makes sense to you. But if you're not, what you might care about is this, this permissions and events situation. If you're not a developer that doesn't mean you cannot use GitHub apps. GitHub apps are everywhere and they're really helpful. Some of them do things like add badges to pull requests. What's a pull request? We'll get there. But they add badges to it. Some of them interact with JIRA. They might like have a JIRA integration to help move your JIRA issues around based on what happens in GitHub. These are apps and they need specific permissions to do this. And this is where you can come in to deny or accept the different permissions for the application. There's some default permissions those apps need. Developers are gonna say, hey, I need these permissions. They actually build that into a small schema in the app that's outside of the scope. It's there. The second major piece to this is OAuth apps. And these are things that you build that do some OAuth stuff. I don't have anything of like super awesome example in here, but they're very similar to GitHub apps. The only difference is they authenticate a user through OAuth. Kind of simple. So I can get information about my user account. Again, if you're a developer, that makes sense to you. If you're not, it's okay that it doesn't. I just want you to be aware that this exists. This is the one that you should be aware of regardless of who you are. Okay. So these are your personal access tokens. When you tried to do something using Git or if you're trying to do something with GitHub actions, you might be prompted to enter a token. You might see something that says token authentication is required. In the event that you see that, this is what it's talking about. And it basically gives you a token that you can set to have an expiration date. You see this one doesn't expire. Bad. Make sure your tokens expire. This one does expire, okay? When it expires, I need to come in and create a new one. This is the one I'm using today. There's a reason why it expires because you guys are seeing stuff on my account and like whatever, it's part of this VM that I just recycle all the time. And you'll see if you're on an old version of a token, like this one is, you can regenerate it to take advantage of the new token format. This is another thing that changes in GitHub all the time. They're constantly beefing up the security of their personal access tokens, okay? So to create one of these, it's really simple. You create it. You hit generate a new one. You give it a note for boot camp, not boot camp, boot camp. I can set the expiration and then I can scope all of these permissions. And if you want to know more about the details of those is a link right here. But basically, if I just want to be able to use this token to manage stuff in a repository, I can do this. If I never need to use packages, I just don't use packages. If I'm not talking about an org, I don't check org, right? And we talked about what an org was to a small degree. We're gonna get into organization security in a second, right? We might, if I don't want to ever be able to accidentally remove a repo with this token, I don't check this. So all of these permissions get built in. It's not just a password. And then I hit generate and now I have this token. If you go ahead and you log in and use it, you can read and write to my repos. You can't actually delete anything, right? I just limited the scope on this thing. You're only ever gonna see this once and then it goes away. I hope you had it. Guess what? It doesn't work anymore, okay? Try to use it now, it's gone. So that's how you can revoke tokens. How easy was that? I revoked it right here in front of you. So basically the idea I'm at is, this token that we're talking about, it's just a little text string. It's something we're just gonna paste in when it's re-asked for. We can delete them quickly. We can put, and most of all, we can put limits on them. Would you ever recommend somebody like turning on all those check boxes? Yeah, like this one. Would I recommend it? No. Is there a use case for it? Yes. If I'm doing something like developing specific GitHub integrations where I don't know the exact scope of the permissions I'm gonna need, oftentimes I will over-privilege first. This is just my way of doing it and getting adopted. I will over-privilege first and then trim privileges as you go. You could under-privilege first and add them, but some of the debugging is a little bit cryptic if you do it that way. So because I understand the debugging messages for these things in a specific way, I like to over-privilege and then scope backwards. But you'll see like this one, I haven't used it in six months. So like, that's another cool thing. Your security people might need to know. And from the organization point of view, like you could audit this. This one I used just this last week. I used it today, plot twist, right? This one I used in the last three weeks. This is kind of a bad indicator because I used it much sooner than that. I think I used it in the last week to be honest with you. So since this one hasn't been used in six months and this takes two seconds to roll a new one, I'm just gonna go ahead and delete this one too. So as there's actually starting to use GitHub, if when they start running into like problems, it's not working, I have found that like the thing that's always gotten me, man, once I set up the Pat wrong, okay? I'd set up my personal access token. I'm just getting some sort of problem there. And like everybody, I hope everybody saw just how easy that was to do. You generate new token, give it a name, set an expiration on it. Don't let it go forever, okay? In fact, the principle you should always have in mind is least privilege. Like give that token just the privileges it needs. So as you're learning GitHub, if you're finding you're getting permission errors, well, maybe you need to regenerate a new token with a few more permissions and then start using that. But you can find your way to that least, our least permissive token that applies for that particular situation. You can get that. Exactly, and that can be like role-based for like if you're HR, then you don't need packages permissions, right?  So once tokens are created, if you just click on them, you can edit them. You can never see that string again. Like the actual string is gone forever. I'll never see it again after that page. But what I can do is I can rename this. Whoa, this one's over scoped. Why is that? Because it's a developer token for me. But you know what I never use on GitHub? I just don't. So I'll come in here and I'll do that. And I could regenerate it to set an expiration date. You can't edit the expiration date, but I can update the token as quick as that. And you'll notice it doesn't show it to me again. Right, now that token has changed its permissions. So your users don't have to roll a new token just because you need them to change their permissions or you want to change the permissions. You just go change them and they work real time. And that's going to change as soon as we do it, right? So we make the change, we rerun the command that was failing because of security, boom, fixed. Yep. Very cool. So that is from the user account point of view. Organizations in depth, we're going to show you how to add some people to those organizations. And we are also going to take a look at some of the additional security features for organizations that take place, okay? So let's go ahead and jump over and do that. What's really fun is now it's going to start getting interactive. If you follow along with this and you create an organization, which costs how much money again? What was that price again? I couldn't remember. 190 free, something like that. Something like that, yeah. Yeah. So if you create an organization, which I encourage you to do, feel free to post your GitHub handles right in the chat and invite each other and follow along with some of the stuff we're doing. Absolutely. Get a feel for it. When we move forward and stuff and you see the repos that we're going to be using, feel free to interact with us too. It'll be super sweet if you do that. So don't hesitate. I'm going to come back over to an org that is pretty empty, but one that I own personally. So we're not going to work in a work org of any kind. We'll go to this one. Okay. Doesn't have any public repositories yet. So if you tried to go to this, this site's not up, so don't even bother trying to go there. We were working on some educational content. This is all just empty. None of this has anything. There are no commits. The whole point is that it's super empty. And I think I'm the only people. Yeah. I'm the only people. So organizations like user accounts. Have repositories as we could expect. They have packages just like a user account did, but then they get these cool things, people and teams.  Okay. So in their settings, we can jump down to the security section and we get some other awesome things, which we'll jump to in a second, but the first one we're going to talk about is authentication. If you're a part of this, this org, I can force you to have to two factor in, right? So if I'm managing an organization, I can ensure that everybody that's a part of it has to two factor in. I can also set up a loud list to figure out what IP addresses are allowed into this organization. Now this isn't super in depth, but when we start layering that with things like member privileges, right? The base membership of everybody that can see this org and the people that are a part of it only have read permissions. You can limit the types of repositories that can be created. Right. You can decide what forks and who can use pages and there is a plethora of options in here for you to craft. That very specific use case for you and your teams and how they interact with this. So. Is there a risk? And the answer is there's always a risk, but there are a lot of built in features that you can use to mitigate and scope everything you need from that organization level. And that is the moment. When you realize you need to use an org. When do I use a personal account? When do I use an organization? If it's me. And I'm accepting outside people's contributions. That's my personal account. If I'm forming a team and I need to have administrators in that team, or I need to have in groups of instructors or groups of people that I'm using an organization. And it's very easy to create an organization. I think you just come into these setting, maybe your orgs. It's been a while. Yeah. And you click new organization. And it will take you through this process of setting up an account, just like an account for an org. Okay. That's that. I'm not going to create a new one because we're already here. So what's, what's, what's again, Matt? What's, what is that point at which, what is that thing I'm looking for? What is that thought that goes through my head? What is that requirement that I have that says, I need a new organization. What is that? And like in a pithy, like, what are the things, what is the thing I'm looking for? I use organizations to bundle tasks. So let's say I cloud college, for example, this was a some, some offline in person meet space mentoring that we were going to be doing me in a handful of friends of mine. We're going to set this up and so we created an organization and we never ended up pushing it farther because we got sidetracked on something else, but I needed collaboration with them. I needed them to be able to see more than one repo associated with this bigger idea. So if we scope this bigger idea even bigger and we did something like this, github.com slash github. This is the github organization. Right. So this is everything that is about github. You can see there's 400 repositories. There's all of these people. There's these projects, whatever. This is what they show publicly. These numbers aren't accurate. There's tons of private stuff. Right. And you get this whole read me on what they are and you'll see what they are. So github.com. Going back to our emoji discussion. It's fun. It's playful. It's, this is marked down. Right. And I did this really easily. So github is the idea. Right. It's, it's the product that, that is going out there. Now, if we look at the repositories, there's not 406 github. You know, code bases. You know, you know, you can't drive the idea of github. Or there's some projects that github has worked on, like providing COVID-19 stats to the world health organization. I got to work around with them on that. That was pretty cool. Wow. That's cool. Right. So. From our perspective of I and E, like, I and E is the idea. It's the name of the business. It's the idea. I mean, I know we're in a lot of different spaces, but we need teams and people to work towards that idea with us. So that is the, the, the D mark for me. Okay. A personal project or is this an idea that. He's going to benefit from a team that is a standalone idea. If it's, Hey, I would like to build a course on. Ethereum. I'm not going to create a new org. I might put it in cloud college. I got you. So if it's like a civic project or something like that, we're going to work with part of your community to do something. We're going to build out something that could help say you're, you know, your local area. That sounds like an org type situation right there. Correct? Yes. And it's because there's limitations on personal repositories. So if I go to a personal repository and I pick this one, that's private. This is another one of those gotchas for like, why use a free account? Well. I don't have a people tab. Mm hmm. I don't have a teams tab. That doesn't mean that I can't. Have collaborators. Mm hmm. But the amount of collaborators I have are much, it's much smaller. Right. I think I have like six or something like that. So maybe. If I have six people and we're working on one, like one off project, we won't create an order for that. But if it's a much bigger deal. And we need more than six people in a private repo that, and I need them to be teams because here's the other thing is I'm just going to add people. For example, if I add. If I look for Brooks and I add this. I can only like put you here. Like you're just a collaborator. You're not grouped as an instructor or you're not grouped as a developer or you're not grouped as a project manager. You're just a collaborator. Whereas if we come back over to the organization side of things. Let me do that. We come back here. And I go to people. I now have different kind of tiers of people. I have members. I have outside collaborators. I have invitations. I can see who I failed to invite. I can see these seats. And I don't think this is a pro account. Or whatever it is. Yeah. So team plan charges you a little bit. This is a free org. So like keep that in mind as we show you this stuff. Like this is what you're getting for free. So I can add people to this. No problem. Now I'm not inviting a collaborator. I'm inviting a member. And it's the same thing. I grab Brooks. I can hit invite. And now I can say, well, is Brooks just a member? Or is he a decider? Is he somebody that can have full administrative rights of this project? There's another demarcation point for you. Do you need more than one person to manage what the heck's going on with this project? If so. Maybe I add him as an owner. So we don't trust Brooks. So we're going to add him as a member. We're going to hit send invite. And now he gets this member tag. All right. To this token, I can come in here and do the same thing with teams. I can create a new team and say, Hey, like this is going to be a team of devs. Um, description, build stuff. And I can say. Other members. So other people in the org can find this team or I can have a secret team. Right. So like maybe we have a super secret ninja team that talks junk about Brooks behind his back. And we want to have that team hidden. We can't do that. No, not. No, keep it visible. It's too much fun. That way I can, I can collaborate with the haters. Dang it. Guess what? We'll make it secret anyway. And he'll never know. Right. Or you can make it visible. And Brooks would find out that we're talking about him. Oh, see. You'll be careful with that. I mean, that is the thing right there. The thing where you accidentally not thinking it through, make it visible when you should. And, you know, Matt and I are having fun here, but this could seriously be something where you've come up with a great idea. Like something really, really cool. And you set the Dern visibility wrong. So as you're worried, I know a lot of you are just setting your accounts up for the first time. And so, by the way, hey, Matt, thanks for popping in your share in there for us. That is something you've got to think about y'all when you're doing this again, think make security job zero. And it means not only protecting access, but protecting the data itself. How sensitive is it? I hate to use the word classified because it makes it sound like something from the Department of Defense. But if you've come up with the next great idea, that's some pretty sensitive data. And you're going to want to make sure you've got that thing set to secret. So don't just rush through, think it through. And you can really leverage a lot of these capabilities here to create safe, controlled secret projects. Exactly. So we're going to go with visible. We hit create team. And now if I want to add, I can start a discussion here. First step to collaboration. I don't get this unless they've added it, which honestly, they may have added this to our private namespaces. Let's see. I don't think they did though. Yeah, you'll notice that Brooks has a pending invite, but there's no discussion. He's a collaborator. So our discussion takes place a little different, which again, it's coming, I promise. But in an org, you get like this forum called discussions where we can have a conversation within our team. And only within our team. I can also add those members to it. So now it's just like adding Brooks as a collaborator. I follow him. He's here. He's invited to this organization. We can also invite him to the team, whatever we have limited seats because this is a free org. I have some orgs that aren't free that, that have much more seating that, that goes into them. Okay. So then we can change role. Right. And we, he can be a maintainer. He could be a member and we can further scope that out in the settings. So organizations grant us this. The team management and membership aspect. Also, or they also afford us some really cool stuff in the settings for our repositories. And this kind of goes on to the security side of things. What you'll notice is that orgs. Can enforce things like two factor authentication. Users. Cannot. I don't have the authentication box in a personal repository. I have an organization repository. I have the authentication option. What I do have in an organization are these security features. And you get more. Especially with public repositories, all the stuff is enabled by default with private repositories. We have to do some stuff around here to enable them. And if we're free, we're limited. That's the catch, right? So we can. Enable this dependency graph. What this does is it shows us all the dependencies that are in our source code. If you're not a developer, you don't really care about this. We can enable something called dependable.  That'd be a good thing for me to catch, man. It would. The good news is, is GitHub will do that for free automatically for you. You can click in this little check box and every time your users create a new repository, because this is an org level. This is an organization. It is enforcing the rules throughout all of your members. This will automatically be enabled in the moment that that JavaScript library has a, a CVE published. GitHub will aggregate that to its database and a bot will send an alert to you saying we found a vulnerability in your source code. Oh, by the way, here's the fix for it. Just merge it in. Hold up, man. Hold up. Stop right there. Hold up. So what we're saying now is, is that we've gone from, Hey, there's this thing called GitHub that you can put code into. Hey, there's this thing called GitHub. We can create projects and we can collaborate. We can talk to something like this where I've got automated security alerts so that when people are putting code up there, maybe they're good.  I may have somebody I ran into that says, Hey, I know how to code. No, they don't. And they're starting to put all sorts of garbage in there. This thing will actually catch it for us. Yep. Let me see if I can find one really quick. Here we go. What is this in? Ha. So here is an app that I have. This is a repository. Right. And right here. I didn't do this. This is that depend about feature. We found a potential security vulnerability in my dependency. Okay. I can click on see that dependent bottler. We got some new features and it tells me, Hey, this is a high priority problem that you have in this repository is 17 security vulnerabilities in this code base. Wow. We can click into each one and we get detailed information. We can see all the metrics for it. And we can see what package it's a part of and so on and so forth. We can see the ID of the CVD. So we can dig into it and go from there. Now, because this is a personal repository and I can tell because it's my username and then repository, not cloud college or INE or GitHub or Microsoft and then a repository. It didn't do the automatic fix for me. Okay. But there's a catch. It doesn't do the automatic effect of the fix for me. However, if it was an org and I had this box checked easily upgrade to non vulnerable dependencies, it would apply the fix. So this is a situation where not only as we as developers creating code, trying to work towards a project, but if we have somebody who stays working as the community manager, or if it's actually at a company where there's a project manager because it is all of this available to them just to look at at any time. Yep. And some to a degree, right? If you're only a member, you might not see some of these settings. If you're an owner or an administrator or a maintainer, you might see some of these settings that it's hard to say what GitHub's going to show you because again, it's a rapidly moving project and one week, everybody might be able to see what's enabled, but not change them in the next week, they might hide it. So I can't tell you for certain exactly what your view is going to be when you do go click into this. Sure. What I can tell you for certain is that we can manage these things. And this is enforced to all of our team members, whereas in order to get dependabot set up for this repository, it's public. I didn't have to do anything because it's a public repository in my own namespace. It's just there. But again, I don't get the cool automated fixes for me, but I can jump right in here and read all about the, the CVE, but look, they even, they did this. They said, Hey, like we're not going to automatically fix it for you because you're, you're a free loader in everything. But if you just click this button, here you go. We have everything we need. It's, it's starting this automated process to where it's going to go update our code for us. So even though I'm free, I could just click that button really quickly and bam. Yeah. But I mean, this gets to the point, Matt. And I hope everybody's, I'm, I'm, I'm trying, I'm making a point here because I'm such a, just a absolute hawk when it comes to security that even for situations where you have security teams that are needing to go in and check repos, they basically are getting it handed to them. Here's the latest CVEs. Here's code. This non-compliant to the point of they can really take ownership of that process where I've been in Oregon. I know you have two, Matt, where, you know, typically security has been that team sitting over there. They let you know there's a seat and afterthought. Yeah. They're sitting over there. The thing's already out there. They're not proactive. They're coming out and saying, oh, there's been four CVEs published this week.  Where if you have something like this, you can update your source code, push it back out through automation. Again, talking about things like actions that we'll look at more. And I'm hoping everybody's seeing this is a huge time saver. It's a worry saver. And so there's a worry, a worry denier because it can deny you from worrying, but also because of the visibility. And this is something Matt and I spoke about earlier today. When those questions come up from the management and from project managers about where is this at? I like the answer saying, did you go look and get him? Go look. You can see what's the problem, what we're doing, how it's being resolved. This is an awesome tool for things like that. Now it's not going to give you 100% coverage. Please don't think that y'all know. There's no such thing. You're going to have to get your hands dirty. But as a way to get those low hanging vulnerabilities out of the way, as Matt just showed you, I mean, it was just click, click, click. And he's done. Yeah. And that's on a, on a personal account, right? And to that point, like DevOps, right? What's the big mantra? Shift left, shift left, shift left. Well, what's more left than the source code? Maybe the planning and the schematic, right? Like, yeah, yeah. This is, this is pretty left as far as that goes. So this isn't deployed. This isn't out to the public. And we knew there was a vulnerability in the dependency. Now that's just the dependency. That's not static code analysis. That's not, you know, runtime analysis. It's not some other stuff that you, you could do to check the security of the applications, not a penetration test, right? It is quite simply dependency analysis. There are other things though with GitHub actions that you could enable to do static code analysis. And it's not exactly static code analysis. It's kind of a new thing they're trying to do where they're trying to detect vulnerable patterns and stuff in a specific way. I don't know that the nitty gritty about it, but you can tie that in and have that happen as well. So this personal account on a personal repo has these security features. I can set up a security policy. I don't have one set up. Now what this is, it's just a text document that tells users how to report vulnerabilities. Right? Now we're in collaboration. This is a public repo. Brooks happens to stumble upon it and he's like, Hey man, you're really bad at writing code. And I'm like, yeah, I know. And he's like, I need to report a vulnerability. How do I do it? And instead of saying, well, let's jump on a zoom call Brooks and I'll tell you how to interact. I can just say, read the security policy and it'll tell you exactly how to collaborate with me. So the second thing you'll see is that this code scanning. Right. This is static code analysis. It's not set up for this. And if I click on this, I can configure code QL and some other code scanning tools. Right. It's not configured by default for me and that's okay. Again, personal namespace. We have our advisories. So I can also disclose a new vulnerability. Maybe I find it in a public because I'm doing some bug bounty stuff and I find it in an open source project. I can draft a new advisory to tell everybody about a vulnerability that I just found. So the collaboration about security exists right here. Coming back to the org. We get similar things. The difference is really that it's forced upon the membership and the repos of the org. It's not enabled on a per repository basis. The other thing you can set up is approved domains. And we can then also do some secret management stuff. So we can store encrypted secrets and credentials that we might need for automation pipelines. We can do that in the personal space too. It's just a little different. It's not applied to every repo in the personal space. It's on a per repo basis in the organization space. These settings exist for everything that takes place within our organization. These are blanket. Rules that come into place. Yes. That does not though. That does not eliminate our ability. See cloud college organization. Repository. It does not limit our ability to come in here and have access to the same features. I was going to ask. Very cool. Very cool. So now we're layering it. We're saying by default you look like this and you'll see these were enabled by default and that's an org level rule. This has not been enabled. I could enable that. Right now that's enabled. So I would get automatic fixes for my dependencies that are out of date, which. Scary sometimes. Right. Broken dependency or dependency fixes can break things. So double check everything, but you do get a chance to do that. I get all of these alert and I can say, Hey, like. If you're an admin or I need this security professional to know when something goes wrong, like let me set them up with alerts so that they get everything they know. Or let me make sure the main painter of this repository knows when there's vulnerable dependencies. I can also do fancier things like configuring any type of deployment keys I might need. And I can manage the secrets a little bit different. And I can. Right. But because this isn't a repo in an org. This is just the general security that, that kind of exists for us. And then I can also see the differences in roles here, which I don't get in the personal namespace. I just get collaborators in the organization namespace. I get these fine grain controls over what that means. The other piece of this is in a personal namespace. I invited Brooks to a repository. And he will never be the owner of this repository. I will always be the owner of this repository because it's under my user account. In an organization, if Brooks creates a new repository, he is now the owner of that repository. He can assign that team ownership of a repository. He can decide who gets to see what. He can decide who gets to see what. As far as what teams have visibility on that repository, even though it's within the org. So you can still fire off private repositories that only the people you want to see can see. And manage that without. Eyes that shouldn't see a senior. Okay. Even though you're in an organization together. Exactly. I'm going to go back to that. I'm going to go back to that. I'm going to go back to that again because there's a point I want to make to everybody. And this is not a little point. I'm about to throw something really big at you. I want you to grab on to this. If you look at the research has been done over the past three to four years on DevOps. Cultures inside major corporations. Something kind of scary is happening. The space or the grouping between. Companies that are falling behind. And there's a lot of people that are doing well. And normally it's like. These folks are doing terrible. There's like a nice big bell curve. This is most of the people that over here. Are the people that are really doing well. The thing flips upside down. There's a whole lot of people not doing well. And there's a pretty good amount of people that are doing. Fantastic. So you've got awful and not well in that group. Those groups are spreading right now. I can dig more into the numbers. I don't want to bore you with it is a huge research paper. But I think that's just some of the things that Matt just hit you with about, let's do 10 minutes on this one. Matt. The stuff that Matt just hit you about, about the collaboration, the ability of a security team to quickly see what's going on. The ability of PMs to quickly jump in there and see where a project is to see if something's gone off track. Because they've lost members. Members have been sick. Members have been retasked and they didn't know about it. All those sorts of things that seems so just. What's the point? It's just the lack of a sense of responsibility and the lack of responsibility that we're going to have. The lack of a sense of responsibility that we're going to have in the House community have latched onto and allows them and Matt can back me up on this. This is a critical metric. They can generally, and we'll talk more about Maine and branching later. I don't know if we're going to get to it today or maybe tomorrow. But from the time a change has been pushed to Maine. To its, you know, it shows up on my phone here. Is about an hour. And the only way you're going to do that, y'all, is if you have a tool like this and you understand how to use it. So your team can collaborate real time. Quickly see what's going on and be able to address those issues. So even though we're just kind of showing you what looks like, oh, that's kind of nice. That's kind of nice. No, it's not kind of nice. It's going to be thing that's going to be critical for any organization going forward to be super successful. With what you're seeing happening in the space over the next coming two to three years. And that's going to be critical. And that's going to be critical for any organization going forward. And that's going to be critical for any organization going forward. With what you're seeing happening in the space over the next coming two to three years. Yep. And a lot of that seems like it's only. For source code, right? Dependency management. You're not going to have that in documentation. However. All of the access in the roles and the collaboration pieces behind that are not. And in documentation, people could commit secrets on accident. And get hub scans for those. Yep. So we're going to take a break.  Now moving into the afternoon. What are we going to be looking at next, Matt? After a break. Oh, repo features. Yes, we are going to jump into the different features of GitHub repositories. And again, follow along. We are going to create a repository that at the end of the day is going to be a little bit of quote unquote fun to work within. And it's going to be one that we build upon. For the remaining days of this boot camp. So it's really important that you do get this set up. If you want to play along with us. And I think this is the one, if I'm not mistaken, they really want to do this one. This is a cool one. Well, the good news is last time I checked, you want to do all of them. But yes, this one is, this one is really, no, I wasn't suggesting that. No, no, but everybody listen. I know we're mad. It's going with this one. This is a cool one to do because it'll get you on your way to having a really cool repo that you want to show off. Absolutely. So if you go to get hub.com and you click your little profile icon or yeah, in the right corner and then click your profile. It looks like this. And this is cool, but it's kind of boring. Like there's a lot of things we can do to this that personalized this a little bit more. And we could have like a welcome page. We could have like a resume. We can have a lot of stuff show up right here. But we have to use a repository to do that. And so the first thing we're going to do is actually start that repository. And then once we have that repository created, we're going to talk about all the different features of a repository and kind of demystify some of the stuff. And this goes back to a question that Brooks had asked earlier about issues and what they're for. And I will tell you my issue with issues as it pertains to discussions. And that's a very telling and foreshadowing statement. So the first thing is you can, if you're at regular the github.com landing page, you'll see a green button here that says new. You can click that. If you're on your profile page. And again, we're not in an organization. This is just our, our namespace. Okay. You can click this repositories tab right here. And you can click new from here either way. You can do that. And you'll be greeted with this screen when it chooses to load. Okay. This is creating a new repository. This exists in your namespace. I recommend that you make this public. It's up to you. You're only going to be able to leverage its coolness if you make it public. Okay. The first thing you're greeted with. Is this, if you already have a project somewhere else and you want to put it on github, follow this guide. Maybe you have a bit bucket repository. Maybe you have a Git lab repository.  And you have a local repository that you need to move up to GitHub. This is your section for that kind of tells you how to do that. We do not have that situation. So we're going to create one from scratch. The next thing we have is a template. And we'll talk about templates as we get into this. But for this case, we're going to use no template. Okay. And what's cool is if I'm an organization, I can set up templates for people to use. So there's some learn code templates. There's some GitHub training templates. And there's even some templates I have on my own namespace. So maybe I have a structure that is very common for repositories. I can create a template for that so that my users, when they create them, it goes really quick. And we'll show you. Is that something I set up because Matt was just asking, and so is Patrick, they don't have any templates. So that's that's something that's automatically populated. Or is that something I know what that is. Okay. That's a catch. I'm on a pro account. I'm willing to bet that it had, that's probably a feature that I get for having a pro account. So that's something that might be worth the four bucks a month to you. I don't know. To put it in perspective to you or for you. I never use this. It's such a rare feature for me to use. I have used it in the past, but very rarely really. You have a pro account and no repository template. Interesting. I don't know what's giving me the ability to see this then. I might have something set in my settings. That allow me to use templates. Let's see. Repositories. That's just showing me a bunch of stuff I'm connected to. I might have something set up in my settings. That's interesting that you can't see it. I thought that was a pretty standard thing to see. So it's weird to me that. Oh, so somebody has it and they're not on pro. Yep. Yep. Yeah. I've got the same sort of thing because I've actually got one project. It's pal faucet. And a pal faucet is actually set up as a template. So when I hit my drop down to my own personal account, boom, pal faucet shows up, but that's the only thing that I have. Here's the other thing I could think of and it wouldn't surprise me if this is the case. And that is. If you have templates available for you to use, you might see this. And if there aren't any templates available to you due to organization membership or the fact that you don't have them set up. It might not even show up, right? Cause at the end of the day, it's a dynamic app, right? We can just render that component. Yep. So that's what I would guess it looks like there's something in the docs about creating a template repo, which we'll get to. Yep. Matt B beat me to it. Nice work, Matt. I was going to try to go. Yeah. Duck duck go that one. But before I could get there, Matt B beat me to it. So yeah, if everybody will look any questions about that, Matt's got a great link down there over to creating template repositories in your account. It will explain how. Yeah. So creating the template repository is really easy. I'll show you how to do that. It's a check box, but I'm guessing that's why this doesn't show up right now is you just don't have any available to you. Right. I can think of some really simple react logic that would do that. So we can give it a name and like, let's go back to that fun culture stuff. You have to give your repository a name, but notice if you can't think of one, good hub suggests one. And you can just click on that and it'll populate it. Nice. But these are all goofy. It's just like, if you're familiar with doctor, all the container names for doctor are all goofy. So these are just goofy names, but you'll see they're all in the case and they all have a dash. And this helps because they become URLs. You don't see spaces in URLs. You see dashes to reflect those spaces. So what is actually going to happen is it's going to be GitHub.com slash Matt Davis 0351 slash studio journey. Okay.  Hey, and you'll see that we get something interesting that pops up. This is a special repository in this repository creates this added piece to your GitHub profile. And it's really cool. So go ahead and create it with the same name as yours. You can give it a description if you want is optional. Okay. I'm not going to do it. We're going to overwrite it anyway. You can make this public or private. I'm going to make mine public. I have no fear here. We're not going to put anything crazy. So this is what you were talking about a moment ago when you said, let's make this thing public because this is going to be like our resume in GitHub sitting out there. I hate to use the word resume because of all the connotation. Y'all, that's not what I mean, but it's like your public facing piece of GitHub. Is that right, Matt? Yeah, exactly. And you'll see how it ties in once we build it now. It's for teaching point. Earlier Brooks, you asked me if I have a private repository, can I make it public? Right. I think we should find out. So I'm going to set mine as private. And I'm going to try to change it later. Don't do it. Don't do it. We're going to do it. You don't have to follow this. You can set yours as public at the end of the day. Set y'alls to public. Mine's going to be public. We'll spill that spoiler now. Yeah. So the next thing you can initialize it with some files. Okay. Since this one says if we add a read me. It's going to go to our profile. Let's go ahead and add a read me. Now what's the extension on that read me file? Good, sir. It'll automatically be put in, but it's not MD, which is a markdown file. Markdown. Here it comes again. So here's the best practice for you. Every repo should have a read me. It is the thing that shows up when we first click it right here. What gets rendered. You'll see this one. For some reason doesn't like this. This is at a read me. Maybe it's in the wrong spot. Maybe I did something wrong with this repo, whatever. It should render just fine. It's probably empty as a matter of fact. That's, I would bet you a diamond doesn't. Yeah, it's empty. Yep. Yep. So let me go back to a different repository that I have and I'll show you this. Some of you might know this. It could also just be new to everybody. So in here, here's a read me. That's what gets rendered right when I first land in any repository. Honestly, it's what gets rendered when I land in any folder within a repository. See, welcome to oranges. Yeah, whatever. Okay. That's coming from the read me. So always initialize a read me. This again, let's shift our documentation left. Just like we shifted our security left. And we'll give us a landing page for anybody that comes to that repository. Okay. The second thing we have the option to add a get ignore. We don't need to worry about this today. You're using the terminal and you're using like get the tool. Get fun fact. Get is not get hub. They are not associated in any way, shape or form different companies. Then you might want to add a dot get ignore file. I'll show you one later. Okay. So don't, don't fret about that. We actually are going to set one up as we do a little devop stuff with a small web app later. We're going to have to ignore some files. In fact, that's for those of you that are on a Mac. Get push of shame right there. So get that store, huh? The DS store. Exactly. So we'll be looking at that everybody. Definitely. And for those of you who are on a Mac, you're going to want to see that. Yeah.  Exactly. Thanks. The next thing is choosing a license. Hmm. Hmm. Why does this matter? Well, if I'm going to make a project open source, that means I'm probably okay with contributions and other people using it and adding to it and modifying it. So I can add a license to protect that property. It's that simple. Wow. Nice. If you choose add a license, like you pick, like it's not hard. If I want to set up an MIT license, bam, it's going to be set up. I'm not going to do this. I don't need a license on my profile. Read me. It doesn't apply to me. But let's stop there for a second because then this again, y'all, this is one of those things we, Matt and I drive by real fast. We don't make a big deal out of, I'm going to stop them. If I were to have said to you, create an open source project and apply the MIT license to it. How many of you would have gone like, okay, yeah, whatever. Or how many of you have been gone like, um, I don't even know what that means right there. Click, click, and it would be done. That's again, one of these really, it's almost a superpower of GitHub to move your project down the line faster by allowing you to left shift those sorts of things like that. Yep. And if you don't know what license to choose, click, learn more. Wow. There it is. Here's all the information about the different types of licenses. And you can get all sorts of helpful information again, like get hubs that home for open source, right? So anything about open source is going to be at your fingertips. You can also add this later. So you don't have to decide are we open source right now. We can decide that later. We got some default branching, which we're about to talk about branches. And then you probably don't see this. This is a marketplace GitHub app that I have in my name space. So every time I go to create a repository, I can select which GitHub apps I want to apply to that repository as well. At the organization level, you can have these show up and say like Jira, like you can have Jira and you can force that app to be a part of every repository too. Just saying. So when you're ready, hit create. And we wait. And the magic happens. Hey, look at that. Look, I have a read me. It's rendered. It says, hi there. What up? It even has an emoji. Now. Why does this matter? If I come back over to my profile, I get this really cool thing not showing up. We'll see why in a minute, I guess it should show up here. It probably takes a minute to propagate to be honest. Oh, ha. I know why mine doesn't show up. And look at that. It even told us what the problem is. Isn't that nice? Exactly. Remember, I made mine private. Oh, shucks. Let's go ahead and go to the settings. And on this general tab, if I just scroll all the way down, you can see all the different stuff. Oh, let's enable discussions too. While we're here. Let's enable. Danger zone. Oh, change visibility. We're going to click that. We're going to say make it public. And it's going to warn you what you can do. And then it's going to ask you to type the name into the box and hit change. Wasn't that easy. So now it's public and I enabled this thing called discussions. So if you don't see this tab. Code issues, performance discussions. Go into your settings. Scroll down until you find discussions and click that checkbox. And just as easy as you can turn it on. If you're like, Oh, should have never done that. Turn it off. Exactly. So now if we come back to my handy dandy profile. Look at this. Look at that. This renders. So this is really cool because you can say you don't have many of those options.  Which options do you have? If you can tell me the options you have, I can help a little easier. I think. Right. So this is really cool. Maybe I've seen a lot of cool ideas with this. I've seen guest books to where you can come to somebody's profile and they have a button in there. Read me that says, click this to sign the guest book and it adds your name to a list of all the people that have visited their profile. I've seen people put their resumes up here. I've seen people put their top five projects up here. And I have a cool task to show you a little bit of automation for hours, but I encourage you to come up with something and be creative. If you do a little bit of Google foo here, I'll go back to mine in just a second and you'll be able to see the tabs. If you do a little bit of Google foo about GitHub profile, read me's, you're going to see a lot of really awesome ideas that you can set up and have as a GitHub profile, steal them. Yeah. This is bad though. Like we don't want this. So we're going to end up changing ours as we go over these features. So this is now changed and says, if you want to edit it, you can edit it. So these are the tags I have. Oh, you mean in the settings, you don't have those. Yeah. You should. You got to be under the general tab. I almost guarantee you have the danger zone because that's where the leading a repository is. Yeah, Patrick, you should have that danger zone at the very bottom because you've got to have that delete repo. Take another look and take another peak. Yeah. In all circumstances, you have the delete repo. Problem. Yeah. So it's under the general time. Yep. He found it. Cool. Thanks for looking at it. Cool. All right. So let's start and we're just going to go top to bottom left to right. Okay. We're going to talk about all the features that exist here at a very high level. And then tomorrow and the following day, we're going to get hands on dirty with those features. And then we're going to make sure that you ask the questions about them today so that we can just drive and do and interact with them tomorrow and the next day. Okay. The goldfish memory feature. Yeah, it is a good memory feature. No, it's not because I was like, wait, what was I doing? Yeah, but you can never be upset because you never remember why you're upset. So it works out. So first things first, this, this left hand thing, the first part of this locator, I guess is your name space. So is it an org or is it a personal account? And the second one is the name of the repo. Right. This is all appended to the end of github.com. If you look at your URL up here, it's github.com slash namespace slash repository name. Right. This is why we put dashes and not spaces. So it's not a problem. It's simply, okay. If your repo name has uppercase letters, it just gets squashed into lowercase letters anyway. So it's not a problem. At least in the URL. I'm pretty positive. Okay, second to that is we have this, this little pill that tells us the visibility. If you ever try to go to a repository and you get a 404 air, like if Brooks sent me a link that I didn't have access to because it was private, but if you ever try to go to a repository and you get a 404, immediately double check that you're a collaborator or that you have read access at a minimum to that repository. You probably didn't 404 because there was an error. You most likely 404 because you're unauthorized. We get this pin button. This is new. Never seen this before. My best guess is that it pins this to your popular repositories tab. Because this automatically shows up. Watching and unwatching. This is really cool. If I go to, let's say I'm really interested in pandas.  And I'm going to go to the pandas dev, not pandas, the animal, but no, no. Python pandas, the other animal. Yep. And I want to know when they do stuff. I want to get notified when pull requests go in or whatever. I can click this button. And I can watch and I can set what type of alerts I'm going to get, but this is going to tell me like how I'm going to get alerted when repository actions happen here. That is a huge deal y'all. That is the sort of stuff that somebody in your organization pops up one day and says, Hey, we need to take a look at something because it looks like they just updated the pandas code. And everybody's looking like, how did they know about this? It's just that simple. They are not that smart. They don't work harder than you. No, no, no, no. They just got features like this that are taking advantage of. So in a project where you're watching, you know, and again, we're talking about code here, but this could be documentation. So it could be the, you know, again, some civic project where you're setting up the requirements and rules for how the community is going to contribute to something. If there's ever a change, let me know.   So I'm hoping that don't get too close to the action here ago. This is just a thing for developers or this is just a thing for code. It applies to anything and that really can empower an organization to keep a tab on what's going on in terms of documentation, code and so forth and so on. Exactly. That's a great point. Another example just to take it away from code is let's say you have an organization, MyCorp, and it has a hiring manager team. You're a part of that team and you have a repository that says job postings and you need to know when a new job is created or new role is created. You can watch that repo and you will get an email alert that a new job posting has been added. You need to go collaborate on that to make sure you're not getting an AWS candidate with 200 years of experience. Exactly. By the way, speaking of that, I'm not going to name the company, but there's a company that I know something about that has the worst hiring practices that I've ever seen. It's not the one I'm at right now. They do it slick, but it's some other company and their hiring process is a hot mess and one of the problems is the amount of documentation that's generated for any candidate whatsoever. When you hear things like that or you're experiencing things like that, y'all, think of things like this, like saying, hey, why aren't we creating repos for this stuff? Everybody just dumps their documents in. We all watch it. When there's a change, we can see what happens. This isn't an enabling tool in that aspect and that's one of the powers. I know we're sitting on watch for a second, but we've got to make a big deal out of it so you don't miss the opportunity of what this tool can do for you and your organization. So opposite to that, maybe things are too noisy. If I click on watch, I will, I can say, hey, never notify me and I will never get a notification on this repository. Or I can say only notify me if I get an app mentioned. Now, the extra cool thing about that is, oh, that didn't, why didn't you watch? Watch. Okay, whatever. The other cool thing about this is this button can trigger automation. Okay. Let's think from a non code point of view. What if I had this repository and Brooks lands in my name space and he's like, man, Matt, this project's really cool. And I'm like, I know, Brooks, I made it. And he's like, I want to keep track of it. And I want to, you know, make sure I see all the updates. So he clicks watch. Well, I could manually find out who all of my watchers are and send them a thank you email. But I think that I'm not paid to do that and I have better things to do. What I could do is when he clicks watch, I could tie automation into this that automatically mentions Brooks in a comment and says, Hey, Brooks, thanks for watching the repo. Really interested in the project. If you ever want to contribute, consider checking out this documentation and how to contribute to the project. By the way, contributions are welcome. And I could automate that. Yep. So that's another new code has everything to do with community management and shifting quality to the left again, because quality isn't just product quality, it's experience quality. So you'll, you may have noticed, mine says pen, but pandas is sponsor. If for some reason you do have an open source project, you can set up a sponsorship program to where people can like tip you for using your project. That's what that is. So like if you used pandas a lot and you're like, man, I really want to pay the maintainers, like give them a tip for like maintaining this giant library, you can do that here. Which means if you have the idea in your head for giants open source project, but you don't want to waste time on it because you're not going to make any money, you can also set that up to where people can tip you just saying. The next thing it's great out right here because forking is not enabled and this repository is locked. It's most likely because it's this very special repository. If I go to a different repo in my namespace, like glowing aqua umbrella, you can see the fork button exists. If you click fork, it will create a copy of this repo in your namespace. For example, now we'll dive deeper into fork