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.