SPEAKER: Hi, everyone. Thank you for joining me. And today's seminar is going to be called The Wonderful World of GitHub. As I'm sure you all agree, I typically come up with the best titles. So let's jump right in. OK so first of all, what is GitHub? I recently heard GitHub being called the Google Drive of code. And in many ways, I really, really like the description. So let's take a step back. The first thing I want to say is, congratulations. If you've taken CS50, then you already have a GitHub account, so congratulations. And you've already used GitHub. How? Well, you may have not realized this, but every time that you've run check50 or run submit50, what you've been doing is you've been pushing your code that lives on your computer onto GitHub so that it's now living in a GitHub repository, OK. So how does it work? How does code go from your computer onto this Google Drive of code? Well, the way that you ask GitHub to connect with your computer is through a series of git commands. Now, Brian Yu, CS50's current head TF has a really, really great seminar, which is an introduction to GitHub and basic git commands linked right above. And if you are not yet familiar with git commands, I highly, highly, highly recommend watching this video. I know I myself have watched it many, many times. OK so in the seminar we're not going to be talking straight about the nitty gritty of how git works exactly. But instead, I wanted to take a step back and sort of have a conversation about what GitHub can do for your programming experience, how GitHub can connect different computer scientists, and sort of really, really get excited about using GitHub throughout the rest of your CS careers. So the first thing I want to talk about is something that is very, very near and dear to my heart-- commits, and specifically, commit messages. So what I mean by this, let's take a step back. So essentially, every time that you push your code to GitHub-- every time you say, hey, GitHub, I'm about to send some code that I've been working on on my computer locally. Would you please go ahead and save it in my GitHub repository? So again, every time you push your work to GitHub, you have to attach a commit message. Now, when I first started learning how to use GitHub, I didn't really care about what messages I used. Sometimes I'd try to submit it with no message, which GitHub doesn't really like. And then, sometimes I'd just really send random, random messages. Really could have been anything. Could've been, like, elephant or duck or something of the sort. However, now that I'm deeper into my computer science experience, I have realized that commit messages have this incredible power and that they're actually extremely, extremely useful. So I wanted to share some of my learnings about git commit messages. Let's dive right in. So there are a couple of reasons that making commits with really nice messages is really useful. So the first one is, stuff breaks, OK. Stuff breaks all the time. You can have code that you think is working, and you might break it. And you'll likely break it. And you'll likely break it again and again. And it's going to be frustrating. But that's completely, completely OK. So what GitHub lets you do is, it lets you send different versions of your code so that you don't have to be worried about stuff breaking. Because stuff will break. And when it breaks, you can revert to an earlier commit. Essentially say, hey, GitHub, I slightly screwed up. Let's go ahead and change the code that is on my computer to something that I had before that did work, OK. So I've just included some screenshots of some funny recent commit situations I've been in where stuff has broken. And you'll notice that sometimes you try to fix something, and it doesn't work. And you just sort of have to start from a few steps behind. But CS isn't always-- programming isn't always a very linear experience. It's sort of more like jumbled. And progress doesn't always look so straightforward. So that moves on to our next reason, which is that it lets you try different things. So I know that many times I've been coding. And I think I'm, like, 80% of the way there. And I think, just in the corner of my mind, that perhaps-- perhaps-- there is maybe a better way to do it. Or perhaps one of the problems that I have might be fixed by doing a certain thing. But sometimes I'm nervous because I think, I'm 80% of the way there, I think. Not sure that this 20% is worth me potentially ruining everything, OK. So this again brings us back to git, which by saving different versions of your code, you're sort of empowered to really, really try different things. And this has happened to me many times where I will say, OK, again, I think I'm 80% of the way there. And I'm going to try three different strategies. And I'm going to make various commits with great commit messages along the way so that I can track that. And then I can sort of free myself up to trying things that might not work, trying things that very well might have devastating consequences on my project. But that's OK. So again, in this fun little thing I've drawn, it's just to highlight that from a specific starting point, you might go in a bunch of different directions, git really, really letting you do that safely and efficiently. And again, this sort of opens up a whole new world where you can code without the fear of things going so wrong that you won't be able to get back to where you started. This brings me to another really, really, really cool thing about commits and your fun commit messages. So I'm a big reflector. And I like looking back and taking the time to process and think through my different approaches to different problems. And one of the things that I've found in my extensive, extensive commit making is that it's actually really, really, really nice to be able to look back and see, oh, wow, I remember that commit. I remember sitting in the library at 2:00 AM and thinking, will I ever get through this? I remember that moment where I made a change, everything broke, and then I Control Z'd and pushed my code because I was very worried that I was about to go into a really crazy direction. So usually, at the end of a piece at a problem set for a computer science class, or just looking through some personal project I've been working on, I'll often just scroll through those commits and think through, wow, look how far I've come. Look how hard some of those moments were. Look how rewarding a lot of those parts were. And I think it's a really, really, really nice thing that GitHub lets us do. OK so moving on. The last thing is just a small note that another great, great feature of GitHub-- which, again, Brian covers quite extensively-- is collaboration. So GitHub and git commands really allow us to collaborate quite easily with other people that are working on the same project. So in this screenshot, it's actually just me making all the commits. But I was using someone else's slides, so I just wanted to give them sort of a shout out. Which brings me to one very important thing about commit messages. So a metaphor I use for this often is, let's say I wrote an English paper. And I give it to my teacher. And when my teacher returns it, I have a grade, whatever, and then I have a bunch of comments. And I start reading them. And the comments that I'm seeing are small change here, tiny issue here. You should fix something. All these very vague, short messages might not be that useful. Commit messages are really similar. So let's say you're working on a project where a ton of other people are also going to be working on it with you. Well, it's a good idea to be transparent about your progress and about how different things are going. And it's just very useful for other people that are working on the same project to be able to see sort of what's going on. So in fact, I've included these screenshots as poor examples of commit messages. I highly recommend taking the extra 30 seconds to write a commit message that is specific, that is clear so that when you go back-- and especially, especially, especially if someone else is looking at that repository, looking through those commits-- that they can see exactly what's going on and maybe lend a hand if needed. Or at least they'll have a better sense of how the project is going. So now let's move on to my second favorite thing about GitHub, which is the GitHub Explore page. So there are tons of platforms out there where people come together and are sharing and collaborating. And those are typically some of my favorite platforms. GitHub is no exception. So the GitHub Explore page is essentially a page where you can see repositories and projects that people have made public, which is typically the vast majority of them. I know that early on in my GitHub career I mainly focused on my personal GitHub repository, so the personal projects that would show up when I clicked on my GitHub profile. And for a long time, I mainly stayed on those few pages. But what I've since realized is that the GitHub Explore page is phenomenal. It is so, so interesting. You can read about other people's projects. You can read about things that you are using, so tools that you are using. I cannot stress enough how interesting it is to read about how check50 works-- CS50's automated tool for grading the correctness of code. And in fact, many CS50 tools, all of the documentation is on GitHub. And you can go and just look through the code and try to make sense of how everything is fitting together. It's really, really interesting. And last but not least, back to this issue of collaboration. So when you're exploring projects, there is this thing that you can do that's called a pull request, which is essentially someone has a repository project. And you say something like, hey, I think there's a way you could do this better. Or hey, I spotted a bug, and I'm proposing a way to fix it. And essentially, you sort of clone the project, make that change. And then, you create what's called a pull request, which is essentially you tell the owner of that repository, hey, I am proposing something. Might you accept this proposal? And if they do, then that change will merge. And their repository will change in that way. And they could say no if it's maybe not a good solution or not a good change. But, but, but, but, but I've actually heard so many stories of people that randomly made a pull request to some repository of some organization far away in a different country or something of the sort. And they said, hey, listen, love your work. I noticed a small change. Here's a way you could fix it. They create a pull request. That organization accepts the change. And then, now you've made this connection. So something I sort of always like to try to do is sort of go around the GitHub Explore page, read about what other people are up to, see what I can learn, see what I can try to collaborate on. And again, it's a great place to make those connections. Again, especially if you are able to find a way to improve something on someone else's project, or if you find a bug and have a proposal for a way to fix it, you can create a pull request and make that connection in that way. The last thing I want to talk about is static websites through GitHub Pages. So there are so many different aspects of computer science. And I think one that is particularly popular is web development. We all use websites. We're all on the internet all the time. You probably are right now. And a lot of us want to know how to build these things that we spend so much of our time on. So I recently have realized that there is this giant, giant push towards learning a bit of web development. However, if you've looked at HTML or CSS or even JavaScript, you may have realized that it can get a little bit more complicated than you realize. And especially for me when I was just learning how to create web sites, it felt like there was just a lot of moving pieces. And I didn't know where to start. And I didn't want to quite go so far on one extreme of building something sort of from the ground up. And it also seemed not that fun to just sort of input stuff into a template like WordPress or something of the sort. Kind of wanted something in the middle. And I found that something that was really, really, really great to start with was GitHub Pages. So GitHub Pages is essentially a way for you to create static websites that are hosted on your own GitHub repository. So it's essentially a way for you to create simple websites and have them sort of live right away. It's all very clearly in your control. You sort of are coding on your computer. And you can push changes to GitHub. And then they'll sort of be updated on your repository. So the great, great, great, great thing about GitHub Pages, they have phenomenal documentation. Very much step by step walking you through how to create your first simple and static website. This is how I made a couple of my early first websites where I didn't really know, again, where to start. This is a great, great, great place to start. OK so what are the big takeaways of this? Git and GitHub can often sound like big, scary things. But they're not. OK again, if you've taken CD50, you're like 70% of the way there. So just a couple notes that I want to leave you with. As I said before, commit messages matter. Really, commits matter for a bunch of sort of the very small-scale reasons that we talked about like clarity and collaboration, but also bigger picture. It's a great time to reflect on your problem solving process and a good time to sort of reflect on how you are growing as a programmer. And then, the second one is exploring awesome projects. The internet is your oyster. And Google is great. And you can sort of go and Google a bunch of different things. And the great thing about the GitHub Explorer page is that everything that you're going to find is going to be in a format that you know and are comfortable with. And again, pull requests are super, super interesting and super cool because, again, it gives you that chance to connect with an organization, a project, that might be countries or thousands of miles away. And the final thing is that you can jump into simple web development with GitHub Pages. Again, you're 70% of the way there. All you need to do is read a little bit about how to set up your first basic website. And then, you can send that link out to your friends and get everyone really excited about how you're the next Steve Jobs, OK. So last note, I just leave you with this commit message that I made recently, which is by all standards not the best commit message in terms of, doesn't really convey much information. But what it does convey is my excitement about GitHub. What it does convey is how exciting these things can be and how fun. And I promise you, I promise you, I promise you that the second that you dive into GitHub-- start with watching Brian's seminar-- that you're just going to find this wonderful, wonderful world. And you're never going to want to get out of it. OK I'm going to now wait for a few questions. OK looks like no questions at the moment. That's totally OK. I'm probably going to stay here after for a bit if you'd like to chat, or I can show you some of my projects, or something of the sort. But if that is all, then I think we will conclude. Thank you so much for joining. Thank you.