GIT AND GITHUB TUTORIAL - CS50 on Twitch、EP.4 (GIT AND GITHUB TUTORIAL - CS50 on Twitch, EP. 4)

字幕表動画を再生する

COLTON OGDEN: All right.
Hello, Twitch.
My name is Colton Ogden and I'm joined today by Kareem Zidane.
Kareem, want to introduce yourself?
KAREEM ZIDANE: Yeah, hi, everyone.
My name is Kareem ZIdane.
I am a preceptor here at Harvard.
I work here with CS50, mostly doing software development stuff,
DevOps stuff, system administration.
COLTON OGDEN: Nice.
And some folks refer to you as Kareem the dream, is this correct?
Shout out to Spencer [INAUDIBLE].
KAREEM ZIDANE: [INAUDIBLE] yes.
COLTON OGDEN: Today we're doing the Kareem the dream stream.
KAREEM ZIDANE: OK, I did not see that coming.
COLTON OGDEN: And what are we talking about today on the stream?
KAREEM ZIDANE: We are going to be exploring a little bit
of the basics of git and GitHub.
COLTON OGDEN: OK, nice, nice.
For folks unfamiliar, what is git and GitHub sort of in a sentence or two?
KAREEM ZIDANE: So git is a distributed version control system, also known
as source control system, and git is usually
used to track changes in files and directory structures of our project.
And you can imagine this is quite handy for us developers
because we tend to do a lot of changes.
We always add features, fix bugs, refactor, improve stuff, and so on.
So you can imagine this gets quite handy to keep track of these changes,
be able to revert back to some of them, be able to build on top of them.
Git also stores these changes really efficiently.
It only stores the things that are necessary in this case,
so we don't have to worry about duplicating the whole codebase that we
have or duplicating all the files in our product.
It only stores the files that changed.
Another cool feature of git is that it also
allows us to work on different parts of the project, at once if you want to
or different features at once.
And this is also quite handy because, you can imagine,
we try to experiment with something or fix a bug or try to add a feature,
and we're not really sure that that's going to work out well or not.
So git really makes it easy as well to do this kind of thing.
And lastly, git also allows us to collaborate with other people
pretty easily when used, in particular, with a hosting service like GitHub.
COLTON OGDEN: Sure.
And I know we use GitHub all the time in CS50.
But for folks unfamiliar, do we want to show them what GitHub looks like
and maybe just give a couple of sentences of what GitHub itself is?
I'm going to pull up our other view here just so we can see.
That's actually your-- that is your computer?
KAREEM ZIDANE: That's my computer here.
COLTON OGDEN: Perfect.
KAREEM ZIDANE: And this is how GitHub looks like.
GitHub is a hosting service.
We're going to talk a little bit about GitHub later,
but this is what GitHub looks like.
If you don't really have a GitHub account
you should probably go ahead and create one.
Let me sign out of mine here.
And if the internet helps, we go to github.com/join you should be able
to create a new account if you don't have one.
COLTON OGDEN: OK.
And so git is what we use at the command line or whatever.
The actual tool.
And then GitHub is where we can push our code
and store it and let other people see it and work on it, right?
KAREEM ZIDANE: True.
We're going to discuss this in a bit more detail later on.
Git, yes, is mainly a command line tool, but it also
has graphical user interfaces if you'd like to use a graphical user interface.
I personally use it on the command line, which is easier for me.
But you can definitely download a graphical user interface for it
and use it.
COLTON OGDEN: OK, cool.
Well, let's get started.
KAREEM ZIDANE: So the first thing that we need to do
is, of course, get git installed.
COLTON OGDEN: Hi, Kareem and Colton.
Hi, Elias.
Good to see you again from Morocco.
KAREEM ZIDANE: Thank you so much.
COLTON OGDEN: Why don't you read--
I can't see what the--
it's in blue text.
Irene says-- why don't you read Irene's message there too?
KAREEM ZIDANE: If I'm not mistaken, if I recall correctly,
her name should be pronounced as I-re-neh.
COLTON OGDEN: Oh, I-re-neh.
KAREEM ZIDANE: Yeah, but maybe--
please correct me if I'm wrong.
COLTON OGDEN: TIL.
KAREEM ZIDANE: This is really exciting for me
as well because this is actually my first ever livestream.
I've never been on a livestream before, so this is exclusive to you, Colton.
COLTON OGDEN: Oh, yeah.
This is true.
Irene basically said, Kareem the dream stream on screen.
KAREEM ZIDANE: Oh, my god.
COLTON OGDEN: I'm just really building it up.
KAREEM ZIDANE: Why did you start this?
COLTON OGDEN: Hi, Kareem, good to see you here.
Hi, Colton.
Hi, Irene.
Good to see you.
Or I-re-neh, if Kareem's pronunciation is correct.
KAREEM ZIDANE: Yup.
COLTON OGDEN: OK, somebody from Egypt.
KAREEM ZIDANE: Oh, cool.
Great, Hi, good to see you.
I can't see the username quite well.
[INAUDIBLE] I think I know.
I think I know him.
[? Muhammad ?] [INAUDIBLE].
All right, that's great.
Hello from Spain.
We have different people from all around the world.
COLTON OGDEN: And [INAUDIBLE] is as regular as well.
He's been on the game [INAUDIBLE].
Good to see you.
Thanks for coming in again today.
All right.
KAREEM ZIDANE: So the first thing that we
need to do in this case is, of course, download and install git.
Git has installers for at least Mac OS, Windows, and Linux.
I'm going to be using the Linux, specifically Ubuntu 18.10.
I don't know.
Maybe 18.10.
I don't think it should make a difference how you install git
on this, on Ubuntu in general.
So the first thing that you need to do, if you haven't done this already,
is to download and install git.
Maybe follow the documentation here on how to do that.
In my case, I'm just going to apt-get update to make sure that I have
the latest--
to make sure that my package manager knows about the latest versions
of packages that are available.
apt-get install git.
This is how I think you would install git on Linux.
Yes, I'm sure I want to install all these dependencies, excuse me.
And once this is done to verify that git is installed,
you can just to git --version and it should tell you that you have git.
COLTON OGDEN: By the way, just included the chat box.
We ere missing the chat box there in the video.
KAREEM ZIDANE: OK, that's great.
So now that we have git installed, the first thing that we want to do
is create a git repository or initialize a git repository to be specific.
And I think there are two cases here.
The first case is you are starting from scratch
and you have an empty directory.
Let's call this project or my project or whatever.
And you can just go inside of this directory using the cd command.
And the way to initialize this git repository or project--
or in other words say, hey, git, I want you
to track the changes in this project--
is by running git init.
And git should reply, initializing the git repository in root,
workspace, the path to your project.
and then creates this .git directory that we're not going to really worry
about it too much for now.
But this is how we initialize a git project.
This should work pretty much the same if you already
have a project in this case.
So let me try to remove this project first, and I do have a thing froshims.
I'm going to use David's froshims example from lecture.
So I'm just going to copy this recursively here.
Now I'm going to get in it to initialize this project.
And now we have git tracking this project or this folder.
A question that you would find yourself asking pretty frequently
is hey, git, what's the status of this project.
What changed, what didn't change, and so on?
COLTON OGDEN: I lose track, definitely, all the time if I'm making changes
to files over and over again.
KAREEM ZIDANE: Yeah.
So the way to do this is actually literally by running git status.
And in this case, git you tell us what changed and what not in this case.
COLTON OGDEN: So if we installed git, we run git init first,
which basically says, OK, this is a new git project.
I want to be able to start tracking the files.
And then, once I start editing, then it can call git status
and then that will show me basically what I've made changes to.
KAREEM ZIDANE: Yeah, you can pretty much run git status at any point.
You don't have to make a change.
You can just [INAUDIBLE].
I run git status all the time to see if I made a change or not at some point.
COLTON OGDEN: Sure.
We've got a couple of messages in the chat.
It says I-re-neh--
I got to get used to pronouncing that.
Kareem pronounced it perfectly, I-re-neh,
but I'm using the English pronunciation too.
I'll try to remember that.
It's going to take me a little bit of breaking the habit.
And then, [INAUDIBLE] says we can use the [INAUDIBLE] IDE
and not worry about the installation process.
That's true, right?
KAREEM ZIDANE: Yeah, that's a great point.
Git is already preinstalled inside of the CS50 IDE,
so if you want to get started right away without having
to worry about installing this, you can just go to CS50 and login
into your workspace.
COLTON OGDEN: And [INAUDIBLE] I think is maybe alluding to the same thing.
He says, glad to be here.
Downloaded it, yet to install on Windows 10.
He opened the IDE for now.
So I think maybe he's saying he wasn't able to get it all working on Windows
10 and he's using the CS50 IDE.
KAREEM ZIDANE: Yeah, that's great.
If you want to follow along right now and you don't have it installed,
feel free, of course, to log into your CS50 IDE
and you should have git installed there.
COLTON OGDEN: OK, cool.
So we talked about installing it, we talked about git init
and then git status.
So now that we be able to track, I'm guessing it's a--
KAREEM ZIDANE: So the first thing that I wanted
to explain before we go deeper into this is
to understand the difference between these three main parts.
Can we see all this?
COLTON OGDEN: I think we can switch to--
oh, I don't know if we have just a--
I can move us.
I can move us.
KAREEM ZIDANE: I can also resize my window [INAUDIBLE]..
COLTON OGDEN: Let me go to the editor and then just do a little bit of this.
Just move us right off screen.
And then I'll move the chat box as well.
Let's try that.
KAREEM ZIDANE: OK.
This sounds great.
So this image is from the official git documentation,
and it shows us the difference between three areas or three
states in which the files can be in.
The first one of them on the left is the working directory,
and this is pretty much our folder where we make changes to our file.
There is a second place called the staging area,
or the index as it's sometimes called, and this
is where we say mark these changes.
Mark these changes to be committed in the next commit, or save these changes
or mark them.
Hey, I'm going to save a snapshot of this when I do [INAUDIBLE] next time.
And then finally, we have the git repository
is where we have these changes actually saved.
So it's important to understand the difference between these three areas.
So once again, just quickly to recap.
Working directory is where we have our files, where we modify our files when
we work on our project.
Staging area is where we mark changes, and the git repository
is where our changes are saved.
COLTON OGDEN: So we stage the files but they're not actually saved--
git's not saving them permanently.
It's kind of like I'm putting down some files to potentially save later
as being part of my .git folder.
KAREEM ZIDANE: Correct.
Yes.
And in this case, I think one of the things that this allows us to do
is make a whole bunch of changes and only save actually some of them
in history.
I forgot to mention this, but git keeps track of changes
by means of taking snapshots of your project, every time you do git commits,
as we'll see soon.
So in this case, we could have a bunch of changes
and we only want to save some of them in history.
In this case, we only stage these changes and then commit them.
COLTON OGDEN: OK, cool.
That makes sense.
KAREEM ZIDANE: All right.
COLTON OGDEN: Do you want me to move us back into the view?
KAREEM ZIDANE: Actually, let's actually look at this first
as well because it's also important to understand some of this.
You might have noticed earlier when I did git status, git said that hey, I
have these untracked files right here.
COLTON OGDEN: And so those are files that were in the folder already.
And then you called git init and then it was
able to recognize, oh, there's some files in there
that I'm not actually tracking yet.
KAREEM ZIDANE: Correct.
So these are files that exist in your git repository, or project--
we're just going to start calling it repository now--
that git knows they're there but it doesn't track them.
COLTON OGDEN: So it scans the folder and says,
oh, I don't actually have a reference to these files yet.
KAREEM ZIDANE: Right.
COLTON OGDEN: But in case you want to add them or you want to stage them,
here they are.
KAREEM ZIDANE: That's exactly right.
The second state in which a file can be in is unmodified, and in this case,
it's not showing in the git status because this is a file
that we pretty much didn't touch.
The copy that we have is exactly the same as the one in the repository.
COLTON OGDEN: But that's a file that we previously were tracking
and it's saying, oh, you haven't changed this since the last time you tracked--
the last time you basically did whatever.
Committed it or whatnot.
KAREEM ZIDANE: That's true.
And third, we have modified.
And these are files that we made some changes to them.
So modified files.
We're going to see some of these.
And lastly, we have staged, and these are
the files that are in the index area or the staging area in this case.
COLTON OGDEN: OK, that makes sense.
KAREEM ZIDANE: It would be useful to get this visualization in mind
before we start working with things.
So in this case, I have these untracked files,
or specifically I have an untracked file in an untracked folder in this case.
The first thing that I want to do before committing them or saving them
in the history is add them to the staging area.
COLTON OGDEN: He's got a question.
KAREEM ZIDANE: Yeah.
COLTON OGDEN: [INAUDIBLE] says, staged is in our terminal, right?
KAREEM ZIDANE: So git takes care of all this.
You don't have to work on a terminal to have these three areas.
This is how git works.
So this is not related to what environment you're using to access git.
If that answered the question.
COLTON OGDEN: It makes sense.
That would bring us back into the view here.
KAREEM ZIDANE: OK, there we are.
Perfect.
So the first thing that I want to do is presumably run git add,
but the problem is git seems to be complaining.
Nothing specified, nothing added, so it seems that I need to specify something.
And I could definitely git add application.py,
or maybe add templates, or do git add application.py on its own line,
and then git add templates in its own line.
But the good thing is that there is actually
a command line option that allows me to add everything that's
changed or untracked in this case.
And I only know this by looking at the documentation.
If you do git help add--
whoops.
Actually, man git add, is it?
OK, so we don't have man installed, so let me show you on my own terminal.
So if you do git help add, assuming you installed all of git,
you're going to see this manual page.
And it lists what the command does and how
to use it with the different options and how these options change
the behavior of this command.
In this case, I'm really looking to add all the files in this case,
and if I keep searching I can find a- or --all dash in this case.
So it seems to me that if we do git add --all, that would add everything.
We see nothing, which is good.
Previously we saw a complaint.
So if we do git status again, now we see these files in green.
COLTON OGDEN: So now they've gone from the untracked and now they're in the--
KAREEM ZIDANE: Staging area.
COLTON OGDEN: --staging areas.
They're not part of the unmodified because they're new files,
but they are being staged.
KAREEM ZIDANE: So now they've gone from the working directory, to be specific,
to the staging area.
COLTON OGDEN: They basically skipped a couple of those steps of the diagram
effectively.
KAREEM ZIDANE: So we're referring to the first diagram here in this case.
So right now they were in working the working directory in this case.
Actually, I'm not really sure if they would
be considered part of the working directory
if they are initially untracked.
But yes, OK, let's say they are in the working directory.
And once we git add them, they move to the staging area in this case.
COLTON OGDEN: Sure.
I guess I was looking more to that second diagram.
KAREEM ZIDANE: So the second diagram is more about this thing on the left here.
So this said, new file.
Previously, it said that this file was untracked,
or actually, it probably showed it up here.
So these are changes to be committed in the staging area,
and it's saying that, hey, all of these are new files.
We're going to see when it's going to show modified--
it's probably going to show it like here on the left instead of new file.
COLTON OGDEN: So we can use git add and then the name of the file
that we want to add, and this is a file that we aren't tracking yet.
Or we can do git add --all and it will just
add everything that's untracked in the current directory?
KAREEM ZIDANE: Yes, but I believe everything that's untracked or modified
in your working directory.
COLTON OGDEN: OK.
KAREEM ZIDANE: It's going to add it.
COLTON OGDEN: Gotcha.
KAREEM ZIDANE: But again, you can always add specific things.
So if you just want to add certain untracked files or certain modified
files only, you can just do that.
In this case, we just want to add everything so we did that.
And the next thing is--
do you recall what the next step is?
COLTON OGDEN: Well I know that when I have a file that I've just added
and I want to get it ready to push to GitHub and I want to stage it,
I usually use git commit, the function git commit.
KAREEM ZIDANE: That's exactly right.
So now I want to tell git, hey, git, save this
as a snapshot in my repository or as a commit in my repository.
COLTON OGDEN: Sure.
It's kind of like taking a picture of all the files in their current state
that you can then maybe recollect or pull back from GitHub or from someone
else's computer in the future.
[INAUDIBLE]
KAREEM ZIDANE: Yeah, in this case, we don't really
have any connection with GitHub yet, but yes, this saves--
this is actually a perfect analogy.
It saves a picture of the state of your project or repository
right now that we can use later in any number of ways.
COLTON OGDEN: GeekUSA says, hi.
Hi, GeekUSA.
Good to have you with us.
KAREEM ZIDANE: OK, so git commit.
And again, git seems to be complaining about lots of stuff here.
Particularly, it tries to tell me, hey, you want to set your email
and name all of these information.
So the thing is here that git doesn't only keep track of files
and what changed and what not.
Git also keeps track of information about who
changed these files, which you can imagine this is also useful in case
we're working on a big project--
that we are 10 or maybe 100 developers working on the same project.
You want to check which developer changed this particular part
or added this particular part.
COLTON OGDEN: Who to blame for a broken piece of source code.
KAREEM ZIDANE: There is actually git blame command that does this.
So who to blame.
If you just want to maybe email them and ask them about something
or insult them maybe--
I don't know-- in case you don't like the changes.
Please don't do that.
COLTON OGDEN: [INAUDIBLE] question.
Maybe you want to read it off there.
KAREEM ZIDANE: Sure.
If you have lots of files, for example 100 files, and we want to add only 98
of them, in this case git add will add all the files.
This isn't what we want.
And adding every file separately with git add filename with this,
it will be hard to do git filename 100 times.
This is actually a great point.
I don't really see a use case where you'd
have 100 files in the same directory and 98 of them you want to add
and two you don't want add.
But the good thing is that you can actually--
if you don't want to group these files under one directory
and add this as a directory, one thing you can do
is use some of bash features, which is the shell that we're using here,
to actually specify certain patterns for files to add.
So for example, I could tell git, hey, git, git add
all the files that start with the prefix foo, for example.
COLTON OGDEN: [INAUDIBLE] foo star.
KAREEM ZIDANE: Yeah, exactly.
Git add foo star.
You can really play with this logic and customize it however
you want to fit your use case.
COLTON OGDEN: So it's kind of on the developer at that point
to be smart about making sure all the files start with some common identifier
or have a common file type, file suffix.
KAREEM ZIDANE: That's exactly right.
Yeah, I personally imagine it's going to be a pain
to have to manually add like 100 files, of course.
So maybe there is some criteria that you can just match all these files with
and it should be pretty easy to use this criteria to select these
or to add these to the staging area.
COLTON OGDEN: Make sense.
[INAUDIBLE] has a question as well.
Can I get some link of the project for testing?
Do you have this project public [INAUDIBLE] by chance?
KAREEM ZIDANE: So we haven't pushed this to GitHub yet.
We're going to push it at a later point.
And I am probably going to also zip all the source code that we're using here
and maybe upload it if you want.
The point is, you can work on any project you want.
I don't really see anything necessary about using
this specific project because I'm literally starting from scratch.
COLTON OGDEN: Cool.
Makes sense.
Yeah, definitely follow along using the same commands as Kareem does.
And you can even just put in your own dummy files, right?
More or less works.
KAREEM ZIDANE: Yeah, exactly.
But these are a little tweaked versions from the froshims example from
David's lecture, which I believe you can find on cdncs50.net/2018 actually,
[INAUDIBLE] lectures seven.
COLTON OGDEN: So you're getting partially cut off too.
I don't know if you want to maybe come a little bit more this way [INAUDIBLE]
KAREEM ZIDANE: --seven.
I think--
COLTON OGDEN: Move your chair a little bit.
KAREEM ZIDANE: Oh, sorry.
COLTON OGDEN: No, you're good.
There we go.
KAREEM ZIDANE: So if you're curious about using some of these,
there are these and there are many other source code
examples from lectures that you could download and use.
This is part of what I'm using, or I'm using part of this actually.
So we missed the--
COLTON OGDEN: Right.
We were going to talk about git commit because we have the untracked files
and we've added them with git add --all.
And so the next stage, like you said, we're going to take a snapshot--
basically the directory as it is right now.
KAREEM ZIDANE: Correct.
We need to save the changes that we have into the repository in this case,
but before we do that, we need to tell git who we are.
And in this case, specifically, we should at least
configure the email it seems and the name.
So I'm going to do exactly that.
And notice that git is really helpful in giving me the exact commands that I
need to use, so I can just copy these.
In this case, I'm just going to specify an email.
[INAUDIBLE] cs50.harvard.edu.
OK, perfect.
And then, actually, no, the other one-- git config --global user.name.
And notice you have to specify quotes if your name has special characters just
to make sure that it gets it right.
So I just configured my email.
I just configured my name.
It's a little bit ugly because it splits on two different lines, but that's OK.
And now, maybe I should try to do a git commit again.
And this is actually a text editor that I see open right now.
It's Vim, if you're familiar.
And git is basically telling me, hey, what did you change?
I need a description of the changes that you just made.
And this is--
COLTON OGDEN: And they'll be able to tell which snapshot is which
if you're doing 50 a day.
KAREEM ZIDANE: Yeah, exactly.
You need to be able to--
if you're looking at the commit history or the log, as we will soon see,
you're going to see a bunch of different comments.
And it would be really useful to see, just
by a quick look, what this commit did.
COLTON OGDEN: Sure.
That makes sense.
KAREEM ZIDANE: In this case, you should ideally be more descriptive,
but I'm just going to say first commit.
This is my first commit.
And save.
This is how you in Vim if you're curious.
And exit.
And now it tells me that, hey, I had to five
files and all these different information
about the modes for the files.
We don't really have to go into these details right now.
This is permissions of the files and so on, but it seems to have worked.
COLTON OGDEN: Looks like [INAUDIBLE] has a question for you as well.
KAREEM ZIDANE: Sure.
So what's the difference between add and commit?
That's a great question.
Add marks the changes that we have as changes
that we want to commit when we do git commit next, if that makes sense.
So the staging area is an intermediate step
where we mark all the things that we want to save in history
permanently before actually saving them in history, if that makes sense.
COLTON OGDEN: Cool, and commit actually is
like taking the picture of the directory and saving that so that we can then
look at it later and figure out what our repo look like in the past
and then revert back.
KAREEM ZIDANE: Yes, that's exactly what commit does.
Commit looks at the staged changes, in this case that we added by git add,
and then takes all of them and saves them permanently in history.
COLTON OGDEN: Cool, makes sense.
KAREEM ZIDANE: Hey, do you have more questions?
OK, perfect.
What do we want to do next?
COLTON OGDEN: So we've committed everything, right?
KAREEM ZIDANE: Yup.
COLTON OGDEN: So now everything is I guessed saved,
so if we did it again we'd have two snapshots.
If we did it again we'd have three snapshots.
I guess then it'd be a matter of demonstrating either maybe
how we go back to a snapshot or maybe how we'd publish it.
KAREEM ZIDANE: So for that, I think we need more than one snapshot
or more than one commit to be able to go back to the previous commit.
Right now we just have one of them, so this
is going to be a little bit tricky because essentially we tell git
in this case, hey, forget everything.
We didn't do anything.
But we will actually demonstrate this later.
One thing you might be interested in is looking actually at the commit history
so far.
COLTON OGDEN: Sure, yes.
KAREEM ZIDANE: So one way we can do this is
using the git log command in this case.
COLTON OGDEN: Right, OK.
KAREEM ZIDANE: And it shows this long, weird yellow--
COLTON OGDEN: Hide the chat there just for a second
so we can see the full thing.
KAREEM ZIDANE: All right.
So we see this first line this weird, long string,
and this is actually an identifier for this commit.
It's a hash generated using an algorithm--
I think it's SHA-1--
that actually uniquely identifies this commit.
And we could actually use this hash to refer to the commit later.
COLTON OGDEN: [INAUDIBLE] has your author information that you
put in that git config command as well.
KAREEM ZIDANE: Exactly, yes.
So [INAUDIBLE] as the author.
It says this is my email.
It also lists the date and the time in which
these changes happened, and of course, the commit message in the end.
COLTON OGDEN: That seems super useful.
KAREEM ZIDANE: So let's actually make some changes.
So I have all this right now, so let me actually--
I have changes that I pulled from lecture from before.
So let me actually copy from source froshims1, I believe.
Everything here into this directory.
So you can simulate this by essentially opening your file
and making actual changes.
In this case, I actually copied files that are
different into my current directory.
I didn't show you what application.py was initially, so we should probably
take a look at this.
And we're going to learn about this command later,
but let's get clean here.
git checkout application.py.
COLTON OGDEN: So what does git clean do?
KAREEM ZIDANE: This is discard any untracked files in my working area.
We're going to explain this later.
I just want to show you first what application.py
looks like in our previous one.
So if we do git log again, this is the only commit that we have.
And if you do git status nothing's changed.
So I'm opening application.py now and here's what I have.
And this is not really about code specifics,
so we can not really care much about this.
But here's a file.
COLTON OGDEN: Just a super simple flask app
KAREEM ZIDANE: Super simple flask app that
expects to git parameter, [INAUDIBLE] in this case,
and renders a template called failure.html if you don't provide
any of these or render success instead.
So again, not really interesting in this case.
I'm going to copy updated application.py from froshims1.
And again, you don't have to copy stuff.
You can do this directly in application.py in this case
if you just copy everything in this directory in here.
If I do git status now, now it shows that application.py is modified,
and it shows a new untracked file, templates/register.html in this case.
So one question that might come to mind here
is what changed about application.py?
And the way we can do this is literally doing git diff application.py.
And you can see this nice diff view provided
by git coloring the lines that were removed in red
and putting a minus in front of them.
And the lines that were added in green and putting a plus in front of them.
In this case, I specifically changed the first line, the importing stuff,
added this array.
I'm just scrolling down.
Added a few variables and added a function.
COLTON OGDEN: So this is froshim0 before,
and then you copied froshim1 and overrode it
and now it's showing you the changes?
KAREEM ZIDANE: Yup.
This might be a little bit confusing.
I could have done exactly the same thing by actually opening
the application.py in this directory and making the changes to it.
I'm probably going to do this next time.
But in the meantime, we just changed the application.py and git showed me
that application.py was modified.
And when I did git diff application.py it showed me what actually changed.
COLTON OGDEN: OK.
[INAUDIBLE] the green lines are something that you added to the file,
and then red ones are ones that you deleted from the file,
or changed in that file, right?
KAREEM ZIDANE: Correct.
COLTON OGDEN: OK, makes sense.
It's like a nice visual indicator of the changes
that you made if you're exactly sure and you're only at the command line.
And there's other tools.
GitHub will show you differently, right?
KAREEM ZIDANE: Correct.
It's actually going to show a pretty similar view to this.
I'm not really sure if you can show the diff side by side here.
GitHub does allow you to show the diff side by side.
There might be a way to do it using git.
I'd need to look at the documentation for this,
but this is what you see when you do git diff.
COLTON OGDEN: Some text editors even now, like VSCode and Atom,
will show you embedded GitHub views so you can see which files are changed.
Usually they'll have changed being blue and then
they'll have deleted lines being red and new lines being green.
So even text editor's now have built in git integration, which is really cool.
KAREEM ZIDANE: Yeah, I'm sure text editors
and IDEs, if they don't even have this as a built in feature
I'm sure there's some extension or plug-in that adds this feature.
But in case you're not using a text editor
that supports this, or you just want to work directly from the command line,
here's how you do it.
COLTON OGDEN: Awesome.
Looks really cool.
KAREEM ZIDANE: Notice if we do git diff as well.
It still shows us the changes only in application.py
and not anything about templates register.html, which if you recall,
was [INAUDIBLE] untracked file.
And this is because it's literally untracked.
It doesn't know anything about it yet.
COLTON OGDEN: It doesn't have a prior history
snapshot or whatever to compare the new one to tell you what's changed.
KAREEM ZIDANE: Correct, exactly.
So again, the way we add these--
suppose we are ready now and we we'd like to commit all these changes
or save them in our repository.
The way we do this is running git add --l
or in short -A. If I do git status again, it shows me that both files are
staged.
One of them is actually modified and one of them is a new file.
COLTON OGDEN: Yeah, it'll tell you, actually,
whether you haven't tracked it before at all so you can say,
oh, this is the file that I changed and this is a completely new file.
KAREEM ZIDANE: Correct.
COLTON OGDEN: So it's kind of nice.
It gives you that feedback there.
KAREEM ZIDANE: The good thing is when we did git diff earlier,
it actually compared the changes in our working directory
to the changes that are saved in a repository, if I remember.
When we saw this nice diff screen, it was actually
comparing the application.py that were saved in the repository against mine
in the working directory.
COLTON OGDEN: Right, because it had that snapshot from before,
and it saves that in the .git folder, right?
KAREEM ZIDANE: Yes.
Now if you do git diff, it's not going to show you anything.
COLTON OGDEN: Interesting.
KAREEM ZIDANE: And this might be a little bit confusing,
but this is because by default, git diff compares the changes in your working
directory to the changes in the staging area
or through the repository if there are no changes in the staging area,
I think.
So the way to compare the changes in the staging area
to the repository, if you want, is by running git diff --cached or staged.
COLTON OGDEN: OK, that makes sense.
KAREEM ZIDANE: And also, I know this only by looking at the documentation.
There is no way that I could have known this.
COLTON OGDEN: It says we didn't commit those files.
There was no history so it had no diff information to give us, basically.
The files that we have now.
KAREEM ZIDANE: Yes.
In this case, I'm comparing the changes that
are marked as saved in my staging area, or marked as
to be committed in my staging area, to actually the snapshot that's
in the repository, if that makes sense.
COLTON OGDEN: [INAUDIBLE] has another question as well.
KAREEM ZIDANE: Sure, let's take that first.
So we add a file, make changes, and then commit.
Slightly inaccurate.
We make changes, add the file, and then commit, and it gets updated on GitHub.
We haven't gotten yet to the GitHub point,
but we're going to discuss this pretty soon.
But I hope I made these two points clear.
COLTON OGDEN: And GitHub is kind of like--
it doesn't have to necessarily go on GitHub.
There's other places, other websites that git can push too.
KAREEM ZIDANE: Yeah.
So I mentioned in the beginning that git is a distributed version control
system, and what distributed really means
is that if you're more than one developer working
on a particular project, then each of you
is going to have a copy of the project.
And it's like history [INAUDIBLE].
Previously, if you're familiar with other version control systems
like Apache Subversion, SVN for short, that
was actually a centralized version control system.
Which means there was actually one copy on the server,
and all these developers interacting with this copy
are just maintaining references to the files and changes in this copy.
And you can imagine one side of this is that if you're offline then
you're disconnected.
There's no way you can commit changes.
In case of git, that's not the case.
Git is distributed so each one of us is going
to have a copy of the whole project plus the history,
so we can just work completely offline without needing
GitHub or any other service.
COLTON OGDEN: And so a company using Subversion, if their server goes down
everybody is kind of screwed, right?
KAREEM ZIDANE: Yeah, I'm not sure many companies use Subversion right now,
but yes, that was I think one downside.
I'm not an expert in Subversion myself.
I've just used it very, very briefly.
COLTON OGDEN: So the principle is, if you and I have the same project
and we both have a copy of it, if your laptop gets wiped you can at least get
the copy off of my computer because I've maintained
all the references through all the snapshots that have ever taken place up
until the point that I cloned the copy on my computer.
KAREEM ZIDANE: Correct.
COLTON OGDEN: --copy it onto my computer.
KAREEM ZIDANE: Or even better, if we have a third party service like GitHub
or Bitbucket or any number of other services,
I can just fetch a copy from this service immediately as we'll see.
COLTON OGDEN: And even if GitHub goes down,
because thousands or even millions of people
have cloned some big projects or any project,
they can just re-upload it to GitHub.
Any one person can upload that project at the point that they cloned it
and just refresh them.
KAREEM ZIDANE: Well, if GitHub goes down and lost data
that's a bigger issue at this point.
Essentially, yes.
COLTON OGDEN: It's kind of a safe I guess.
KAREEM ZIDANE: You just want to make me go to you to get the copy anyway.
Sure, I can do that.
All right, do we have other questions?
COLTON OGDEN: I'm bringing the chat back because I realized it's not [INAUDIBLE]
little to--
KAREEM ZIDANE: Do you want me to get this closer to you maybe?
COLTON OGDEN: No, that's fine.
I can read it pretty well from there.
KAREEM ZIDANE: All right.
COLTON OGDEN: Here we go.
We got a question from [INAUDIBLE] or [INAUDIBLE]..
GitHub is equal to Bitbucket if you put double equals, not triple equals.
In JavaScript, I believe that's like type equivalence, the type
equivalence operator.
So equal but not quite equal.
KAREEM ZIDANE: I guess that's true-ish.
I mean, GitHub might have features that Bitbucket doesn't have
and the opposite, so it's not necessarily
that they're all equivalent.
You just want to do a little bit of research
and see which one would be best for you.
COLTON OGDEN: So can we see the changes other developers are making when
they make changes to the same file?
KAREEM ZIDANE: We will get to that, yes.
COLTON OGDEN: Awesome.
KAREEM ZIDANE: But good point.
So now, once again, we ran git diff --cached.
This could also, I believe, be --staged.
Yep, it's going to show me the same thing,
and it's going to compare the changes that I have in my staging area
right now to the repository.
And notice now that it's actually also listing
information about templates/registered.
Previously it didn't show anything when you just did git diff
and it was in the working directory.
And this is because now it is in the staging area.
So it's a new file added to the staging area,
and it shows what this new file adds to your repository in this case--
COLTON OGDEN: Nice.
KAREEM ZIDANE: --which is all--
COLTON OGDEN: What command did you run to put it in the staging area again?
KAREEM ZIDANE: Git add.
COLTON OGDEN: OK, [INAUDIBLE].
KAREEM ZIDANE: --all or -a.
COLTON OGDEN: I know plenty about git, however
I want to get better at two things--
solving merge conflicts and knowing how to remove a commit for a certain file
that you have accidentally committed to be pushed to a repo.
How can I do that?
KAREEM ZIDANE: These are two great questions.
We're going to answer them pretty soon when we get to branches and merging.
But long story short, the way you resolve git merge conflicts usually
is by literally opening the file that has a merge conflicts
and removing some symbols from it and removing
the snippets that you don't want in it.
And just to clarify a little bit, a merge conflict
happens when you and I are working on the same file potentially
and we modify the same line or same lines in two different commits
and then we try to merge these changes back together.
The problem is when you merge these changes,
git doesn't know do you need your changes or my changes?
And so we have to resolve these manually.
COLTON OGDEN: Rather than flipping a coin.
KAREEM ZIDANE: Exactly, yes.
So we're going to get to that.
Hopefully we remember these two questions to answer them
when we get to git merging.
Now that I have these, I can commit them.
And previously, I just did git commit and open a text editor.
For me, the good thing is that you can just
pass a commit message on the command line
by specifying -m and then the commit message.
So in this case, I added a students' list.
So this is an example of a commit message.
It should be short and descriptive.
I believe it shouldn't be--
theoretically I think it can be longer than that,
but I think the good practice is that it shouldn't be longer
than 50-ish characters.
But if you find yourself wanting to add more details,
then you can just do git commit, get back to the text editor view,
add a short description on the first line, and then a couple of lines
later you can just add a more detailed description
if that's something that you want.
So in this case, I'm just going to commit the changes.
Git is going to tell me what changed briefly.
So just to verify, I'm going to do git log again,
and now I see these two comments.
COLTON OGDEN: Nice. and it shows the most recent one it looks like on top.
So at a glance you can see immediately what the most recent commit was.
KAREEM ZIDANE: Yeah.
COLTON OGDEN: [INAUDIBLE] says, all we're doing
is staying between our PC and GitHub as in the staging area?
KAREEM ZIDANE: Not quite.
So still we have no connection to GitHub whatsoever.
All these three areas are areas that are used by git completely locally when
you're working within your project.
It just uses it to separate between the different things that we talked about.
So nothing that has to do with GitHub at this point yet.
All right, so we see our git log.
We verified that our latest commit got added.
One thing you might be wondering at this point, hey,
what if I made a stupid change to a file?
I just added foo to application.py here.
I should have probably done this using text editor.
But I just added a stupid line here.
COLTON OGDEN: Would love to have you do a Linux terminal command
tutorial as well for people.
KAREEM ZIDANE: We probably should.
So if you do git status, we can see that application.py changed,
and then if you do git diff, or git diff application.py in this case,
it's just going to show me, hey, this line
got added and here's the line that got added.
But suppose I don't want to do this.
Suppose I want to discard this change.
One way I can do this is using git checkout, so I can do git checkout
and then dash dash, and then the filename-- in this case,
application.py.
And then I hit Enter.
If I do git status again nothing changed.
My working directory matches what's in the repository right now.
And if I open the file again, scroll back to the bottom,
I don't see my line anymore.
COLTON OGDEN: So git checkout just erases any changes that you've staged?
KAREEM ZIDANE: Correct.
Yes, discards the changes in this case.
COLTON OGDEN: OK, cool.
That makes sense.
Looks like Andre from Facebook is in the chat, if you want to read his question.
KAREEM ZIDANE: Sure.
Hi, Kareem.
Great to see you.
Thank you.
Great seeing you here too.
Is there a way to avoid merge conflict symbols being
entered into a file that's been automatically generated?
Removing merge conflicts from auto generated XML can be quite tedious.
Is there a way around this?
I'm not really sure if there is a way to remove these symbols
or even to change them.
What I do know, though, is that I know there
are merge tools that exist that you could use that would help make
the merging process easier for you.
And I also know that there are certain command line
options that you could use to tell Git, hey, Git, use the changes from x
or use the change from y and don't care about the other changes
if a merge conflict happens.
COLTON OGDEN: Makes sense.
KAREEM ZIDANE: I hope that answered your question,
but I should probably look into this more.
COLTON OGDEN: [INAUDIBLE] has a question, or a statement.
Git checkout can be dangerous, meaning it will erase all your work and cannot
be recovered.
KAREEM ZIDANE: That's true.
So you want to be careful when using git checkout.
That's a good point actually, unless you preserve the history in some other way.
For example, if you're text editor preserves history
then they could be recoverable in this case.
But otherwise, you want to be careful using this
because you could literally lose the work that you did.
And this is why, actually-- this is a good point.
This is why committing changes frequently
is a good idea because you can just pretty easily revert back
to the previous version.
OK, what else do we have here?
So you have a bunch of things, actually.
You said this is going to take longer and it seems to be taking longer.
But what if I change my mind?
What if I want to do something like, hey,
update the commit message of the last commit in this case?
And so one way to do this is using git commit --amend -m,
and again, I know this by looking at the documentation.
And then mention the new commit message.
New commit message.
Of course, it should be more descriptive than this.
COLTON OGDEN: I actually didn't know that was a thing.
This is the first brand new thing that I've seen so far.
Git commit amend.
KAREEM ZIDANE: So if you do git log, in this case you
can see that the new message is now new commit message,
instead of added students.
COLTON OGDEN: OK, that's awesome.
I might actually start using that if I screw up.
KAREEM ZIDANE: Another thing.
Actually, take a look at the commit SHA in this case.
I think it's going to change if you do this.
Every time we do commit--
right now It starts with fa14a--
blah, blah, blah.
So if we do git commit --amend -m--
let's go back to our original commit message.
Added students list.
git log.
COLTON OGDEN: Oh, you're right.
It did.
KAREEM ZIDANE: It changed.
So this is actually one of the great features about git
is that it really has a great integrity, or ensures that the data has integrity
in this case.
So it seems to be that the commit message is actually
part of the input or part of the data that's hashed
when calculating or computing this.
COLTON OGDEN: So is it deterministic, such that if you were to do it again,
the git amend with the other message you just
had, would it be the fa14 or whatever?
KAREEM ZIDANE: I thought the time was taken into account too.
COLTON OGDEN: Oh, that makes sense.
KAREEM ZIDANE: But let's actually double check this.
This is a good point.
What?
Commit message?
Is that what you did?
I think it started with F last time.
COLTON OGDEN: Yeah, fa14.
OK, that makes sense.
It would make sense for them to put the time in there
because if it was deterministic people could all write the same file if time
weren't take into consideration.
Then they would get the same commit.
KAREEM ZIDANE: So what I meant by integrity, just to briefly explain,
is that if we're both on the same commit that has the same unique identifier,
then we exactly have the same state in our project.
That's what I meant.
COLTON OGDEN: OK, makes sense.
KAREEM ZIDANE: There's one thing you could do.
Another thing you could do is temporarily or permanently
revert back to a previous snapshot.
I think you alluded or asked about this earlier.
And one way to do this is using the git reset command.
Before using git reset I think we should have explained something
about this weird blue or cyan head on the top right, and master as well.
So these are pointers, or references if you're familiar with these terms,
and head is just a pointer that always points to the commit I'm on right now.
Master in this case happens to be the same thing as head, but in this case,
head and master are both two references that point to the topmost commit.
In this case, which is d615-- blah, blah.
Does that my sense?
COLTON OGDEN: Is head always the topmost commit?
KAREEM ZIDANE: Head is always--
not the topmost commit.
Head is always where you are [INAUDIBLE]..
COLTON OGDEN: OK, I see.
KAREEM ZIDANE: So you could be standing on--
we're going to talk about git branches later, but imagine we have 10 commits.
We could stop on the third one or change our state
to be the same as the third commit as it was in the third commit.
In this case, head is going to be pointing to this commit.
Branches on the other hand, are always point to the tip of this branch.
So in this case.
We have a branch called master, and the reference master
is always pointing to the top commit in the branch master
COLTON OGDEN: OK, that makes sense.
We have a couple of questions in the chat.
KAREEM ZIDANE: How can we change the second commit message?
This is actually a little bit more tricky,
and the reason this is more tricky is because of the same point.
The integrity of data.
So you can't really change the contents of a commit in the middle
without actually changing all history that follows that.
Because I think also part of the information of the commit,
like the commit SHA, whatever, is also taken into account
when calculating or computing this hash.
COLTON OGDEN: So it'd have to propagate to all the commits after that one
basically?
KAREEM ZIDANE: Correct.
The good the good news is that there is actually a relatively easy way
to do this.
We're not really going to talk a little bit about git rebase,
but essentially you could do git rebase -i,
and of course it's not working right now.
I think it's going to be HEAD is it?
Nope, no head.
Let's see.
git log.
Oh, I think we need to get rebase on the first commit, which the SHA starts
with 6facd something, something.
So I think we need to git rebase -i 6f8d, right?
COLTON OGDEN: cd I think.
6facd.
KAREEM ZIDANE: And in this case, it shows us only the commit after this,
in this case.
And notice here there's a bunch of comments
about what we can do with this commit.
So in this case, I want to change the commit message of this,
so I need to change pick to reword or just R for short if I want.
I'll just get rid of this, change it to R, save.
And what do you want to change the commit message to in this case?
COLTON OGDEN: [INAUDIBLE] or who was it?
That was the person that said it.
KAREEM ZIDANE: Like this?
Save, git log.
Notice the commit SHA.
This is not going to be really obvious in this case
because we just have two commits, but in this case
the commit message did change.
Can we change the commit message of the very first commit?
That's interesting.
If I do this, is that going to work?
No.
I'll need to look this up, but I don't know
how to rebase or change the commit message of the first commit
without actually doing something more fancy.
COLTON OGDEN: Deceptively complex thing to do.
KAREEM ZIDANE: It is.
It's really one of the things that are relatively annoying,
but it's good that we have at least a way to do this.
COLTON OGDEN: [INAUDIBLE] had another question.
It says, is there any other way without losing
changes made, but see older version?
I think he's talking about git checkout.
KAREEM ZIDANE: So yes.
So you want to see the older versions in the repository while you have changes,
is that what you're talking about?
I don't know.
COLTON OGDEN: I think that's what he's talking about.
I guess like keeping changes that you currently have
but seeing the file as it used to be.
KAREEM ZIDANE: That's a good point.
I think you can do git show.
So if we git log in this case, suppose we
want to show what changed in the first commit.
Maybe you can do it git show 6facd, and this
shows you the contents of application.py and the other file.
Maybe you can do git show application.py.
Is that possible?
Yep.
COLTON OGDEN: That's pretty cool.
KAREEM ZIDANE: So you can just see the changes.
I think you can also check them out, if you want, to a different file
altogether.
And the way to do this would be git checkout.
Let's see, what was the commit SHA?
So instead of this that would be git checkout, the commit hash, and then
the file name into old.py.
That's wrong, of course.
Maybe I'm missing something, but there is a way to check out the file.
We're going to have to look this up.
6facd.
Yep, there you go.
So the reference that you want should be before the dash dash in this case.
So now if I do cat old.py, I don't see anything because that was empty.
I guess I did something wrong.
Anyway, we're going to look at this later.
This is not the way to do it apparently, but I'm pretty sure
there's a way to concatenate or copy the contents
of the file of a previous commit--
COLTON OGDEN: Powerhouse of the cell--
shoutout to Nick Wong-- says git stash?
KAREEM ZIDANE: Git stash.
That's actually a good point.
Git stash actually temporarily discards the changes in your working directory.
So I guess we could have used actually git stashed.
That's really a good point.
Thanks for bringing that up.
So suppose we do the same stupid thing, echoing foo to application.py.
Now if I tail application.py in this case, I see foo in the end.
If I do git status I see that this changed.
If I do git stash, notice that this is also I
think going to temporarily save the change, even in the staging area,
to some fourth area that we didn't talk about.
The stash in this case.
So if you do git stash, it tells us that, hey, I
saved these changes [INAUDIBLE].
If I go git status again, nothing's here.
So presumably, if you open application.py now
it actually matches what's in the repository.
And the way to get these changes back is using git stash pop like this.
I do git status.
Now I see application.py with the changes that I made.
COLTON OGDEN: That's pretty cool.
[INAUDIBLE] like a sketch pad to work with I guess.
KAREEM ZIDANE: Yeah, that's a good question.
That's a great point.
There are other ways to revert back to a previous point in history,
in this case, using the git reset command.
And I think there are three distinct ways to use git reset.
One of them says, hey, I don't care about anything that I have right now
in the repository.
Just reset the state of my repository to a particular commit,
and this will be git reset --hard the reference to this commit.
The SHA for example, or whatever that we want.
COLTON OGDEN: And this is basically reviving that old snapshot
and making the directory reflect that snapshot.
KAREEM ZIDANE: Exactly.
It's forgetting about any change that you
have right now in the repository and force
resetting the state to the same state as it was.
COLTON OGDEN: And just like checkout this
will erase all current changes, right?
KAREEM ZIDANE: This will erase all current changes, yes.
The good thing is that it allows you to revert
to a completely different commit.
All the files, all the folder structure, is
going to be the same as in this commit.
While with checkout, I guess you can just check out
certain files from that commit.
There should be a way to check out everything,
but I think it's going to be a little bit more complicated to use
than using git reset [INAUDIBLE].
So I referred to head earlier, and the reason I
did that is that head is actually-- right now if I do git log,
head is actually the same as aa7d9 whatever, which
is the SHA or the hash of the first commit.
Not the first.
The top commit, rather, in this case.
And the cool thing about this is that we can actually
refer to commits without necessarily hard coding their SHA or hashes using
simple arithmetic with head.
So for example, if you want to reset back to the commit that's the parent
of the current commit, I could do git reset HEAD^ like this.
And notice that now, if we look at git status,
it shows that application.py is modified.
Templates register as untracked, which was the case when we first
added these files.
If I look git log right now, I see that the commit that I had--
the second commit disappeared and now head is 6facd dot, dot, dot.
COLTON OGDEN: Makes sense.
KAREEM ZIDANE: So this is one way.
I don't want you to get lost, but we mentioned that there
are three ways you can git reset.
You can force reset everything.
You can just do git reset without any flags in this case.
So not hard, not soft.
If [INAUDIBLE] force change back you can do git hard.
If you want to change back but maintain the changes, like in this case,
you can just to git reset.
Or if you want to go back but maintain the changes in the staging area,
that's going to be good.
Reset [INAUDIBLE].
So I guess we could demonstrate each of these.
There's another cool command that--
another cool feature is that when you do that,
git actually doesn't permanently forget about the commit.
You can do git reflog and see where head was before.
And apparently the commit that we lost, which was aa7 something, something,
we could just check this out now.
So git checkout aa7d9 something, something.
And of course, we have changes.
Let's stash these for now.
So let's do this again.
git clean -fd.
Discard any of these changes.
Let's try this one more time.
And now I'm on the [INAUDIBLE] head.
If I do git log now I can see my commit back in this case.
So I haven't lost it permanently in this case.
I believe after a while git might garbage collect this.
I'm not quite sure.
I know for sure that old commits on GitHub, which we'll get to in a while,
are actually--
[INAUDIBLE] commit like abandoned commits--
are erased after a while.
So in this case, we can get to our own commits.
So when we did git reset to the parent commit,
what happened is that our changes were maintained from that commit,
aa7 something something, in our working directory.
If I do git reset--
same command but add --soft to it, [INAUDIBLE] head,
I do [INAUDIBLE] again.
Now our changes are still maintained but instead they're in the staging area.
So you can imagine this is useful because if you change
the same files in your working directly right now,
this is not going to overwrite these changes, if that makes sense.
And finally, let's git reflog.
Let's git stash again for now.
We don't have anything, so let's git checkout, git reflog.
Let's actually do git reflog here and git checkout aa7d9,
and then again, we have the same commit.
Now, if we do git reset --hard to the parent commit of head in this case,
it's actually you're going to force reset, it actually [INAUDIBLE] again.
We don't have any changes.
So this is going to force the state of your repository
to be in the same state of this commit.
COLTON OGDEN: And this is where we are with froshim0 when we committed it.
So it's basically going to be at the very beginning?
KAREEM ZIDANE: Correct.
You can always check where hit is by using git log, and in this case
we're on the first comment.
COLTON OGDEN: Nice.
There's a lot of different ways to reset the [INAUDIBLE]..
To reset head, I should say.
KAREEM ZIDANE: Yeah, do you have any questions so far?
I imagine this is quite a mouthful.
COLTON OGDEN: Haven't gotten any messages in the chat
yet, but if anybody does have any questions,
definitely toss them in the chat there.
We'll take a look at it.
We're monitoring in real time.
But if anybody doesn't have a question, I
guess we can move on to the next topic.
KAREEM ZIDANE: All right.
Let's see.
What do we have here?
We talked about git stash.
We talked about git checkout.
Suppose you would like to--
first of all, I think we lost a commit here.
Are we on master?
Now we're on master.
Can we merge the commit that we lost again?
Because in this case we lost it from master.
Can we do this?
What was the commit again?
aa7d.
Can we do git merge aa7d?
OK, cool.
Now we've got our commit back.
So now master matched exactly the same state
that we left it on before doing all this crazy stuff.
So one thing you might be interested in doing is actually removing one file,
and there are more than one way to do this.
The easiest, of course, is to actually remove this file.
So suppose I want to remove application.py.
I do git status again.
Git is going to tell me, hey, this file is deleted.
And you can literally add this to the staging area
like we did with any other change.
Application.py git status.
Same thing.
And then we can commit this like last time.
The other way-- and I'm going to stash these for now.
Now if I check again I have my application.py.
The other way I can do this is using git rm, so git rm application.py.
And I believe this is going to stage it automatically for me,
so it doesn't require two steps in this case.
COLTON OGDEN: Nice.
Looks like [INAUDIBLE] has a question for you as well.
KAREEM ZIDANE: Sure.
[INAUDIBLE]
Use all these commands--
OK.
Do you, Kareem, use all these commands in your everyday life,
or is there some basic commands you use?
Another question, how does [INAUDIBLE] work?
OK, so these are two questions.
One of them is way, way beyond the scope of this stream,
which is how [INAUDIBLE] works, but I'm going
to try to explain the basic details of how that works.
COLTON OGDEN: We can also do maybe a separate stream someday
where we go into [INAUDIBLE] in a lot more detail and have time.
But maybe if you want to them a couple sentences I guess that might be--
KAREEM ZIDANE: Yeah, certainly.
For the first question, do I use all these commands?
I want to say yes, I do use all these comments and more.
But the catch is I didn't really sit at some point
and read the whole git documentation.
I just learned things as I went.
So if I want to add something to the staging area, I just googled that.
How to add this?
And I just found git add, git commit, git reset, git reflog, and all these.
COLTON OGDEN: Stack Overflow.
KAREEM ZIDANE: Exactly.
If you find yourself trying to memorize these
you're probably doing something wrong.
I think what you should do is just learn about
what's out there if you can get a basic idea, and then as you go,
as you need to do something, just Google how to do this.
And over time, if you use this again and again,
you're actually going to develop a muscle memory
and use these pretty easily.
COLTON OGDEN: And certainly some commands
are used a lot more often than other ones too.
KAREEM ZIDANE: Yeah, definitely.
COLTON OGDEN: Elias also says, best git tutorial he's ever seen.
Thanks.
KAREEM ZIDANE: Thank you so much.
That's so sweet.
So let's discard these now that we talked about git rm.
Of course, we need to commit these changes if you want
to actually save deleting this file.
But it's also sometimes the case that I want to ignore some files.
So suppose I need temporary files for credentials
that I have and I don't really want to save this in the repository.
If I do git status now, it's going to show us untracked.
The problem is sometimes if I have even more changes
and I try git add --all or git add --a, this file
is going to get added to the staging area as well
and eventually going to be accidentally, or not accidentally,
committed, which is not what I want.
So one thing I can do is [INAUDIBLE] once you
see this file or this folder or these particular files or folders.
Don't care about them.
Ignore them.
And the way to do this is by creating a file called .gitignore in the current
directory.
And on each line in this file, you're going
to specify a file name or path or a pattern for these for git
to match against [INAUDIBLE].
So in this case, I specifically want to ignore the credentials files,
so what I can do is open this in a text editor.
I could do this in one step.
Ignore and then say, hey, credentials I want to ignore that file.
Save an exit.
If I do git status again, I don't see credentials but I see .gitignore,
which is OK.
We want to keep track of .gitignore in our repository.
Now I should probably just git add this, ignore, git status.
Verify what's in the staging area before committing.
Git commit -m added, or it's more descriptive.
Ignore credentials.
There you go.
COLTON OGDEN: Easy.
KAREEM ZIDANE: Yeah.
So this is actually a feature that's frequently used of git,
and I think we should be ready to talk about branches, unless we
have questions first.
COLTON OGDEN: Cool.
Awesome.
KAREEM ZIDANE: OK.
I don't see any.
You?
COLTON OGDEN: The stream takes about 10 seconds for them to hear it,
so I'll monitor and I'll let you know if I see anybody ask any questions.
KAREEM ZIDANE: Makes sense.
Do you have any questions in the meantime?
COLTON OGDEN: No, I'm excited to get to branching.
Let's do it.
KAREEM ZIDANE: OK.
So branching is also one of the cool features of git
that allows you to work on different parts of the project pretty easily,
or experiment with things pretty easily without really
missing the state of your project or repository.
It also makes it way easier to work with people when we get to GitHub later
because you can imagine each of us can have their own branch, whatever that
means for now, and work separately.
And then when we're ready we just merge these changes back together.
COLTON OGDEN: So up to now we've worked with the master branch, right?
KAREEM ZIDANE: Up to now, the default branch in this case
is the master branch, and usually that's the main or the default
branch in any git repository.
Of course, it doesn't have to be the case.
It's just a convention.
And usually this branch should be always in a good enough state, in this case,
or a near perfect state.
We don't want anything to be messed up in this branch ideally.
So just explain what a branch is in short,
a branch is just a sequence of commits.
So we have how many commits now, three?
So these three commits represent the master branch in this case.
The way to list the branches that I have is using git branch,
and right now it says you have one branch called master.
And it's marking it in green and putting an asterisk in front of it,
saying that, hey, you're currently on this branch actually.
So one way to create a new branch-- suppose you want to add a feature
or fix a bug or improve something or you want to experiment,
you can just create a new branch using git branch.
Same command but then mention the branch name.
So let's call this new-feature.
If I do git branch again, it's going to say, hey,
I created a new branch for you.
It's here, new-feature, but you're still on master.
COLTON OGDEN: That's what the asterisk and the green text
are representative of I'm guessing?
KAREEM ZIDANE: Exactly.
So the way to switch to this branch actually is git checkout new-feature.
Now if I do git branch again, it says we're on new-feature.
Interestingly, though, if I do git log it shows the exact same thing,
and shows on the top here that new feature
is also pointing to the same commit.
And this actually sort of supports the point
that we talked about earlier that git does this efficiently.
When you create a new branch, git doesn't really
copy everything that you have into a separate place and just
gives you a branch to work with.
But rather, if git can refer to something from before,
it's just going to use a reference to it.
In this case, all three references head--
new-feature and master-- are pointing to this specific commit.
COLTON OGDEN: Makes sense.
KAREEM ZIDANE: Now you might find it a little bit
boring to use two commands to create and switch your branch.
Usually when you want to create a branch you want to switch to it immediately.
So the way to do that is using git checkout
-b, a flag that influences the behavior of git checkout in this case.
Let's call this new-feature1.
And now if I do git branch again, I actually created new-feature1,
as you can see, and switched to it immediately.
COLTON OGDEN: Cool.
So any features now that you write in new-feature1
aren't going to necessarily be in master or in new-feature,
just in new-feature1?
KAREEM ZIDANE: Correct.
So let's actually verify this.
So suppose I add a file called foo to my repository right
now on new-feature1 branch.
So git add, git status.
I see my new file git commit, added foo.
It's nice.
Everything's OK.
If do git log, notice here it updated actually.
I can scroll through this, but notice here it says both head
and new-feature1 are referencing this commit,
but master and new-feature, which are the old branches,
are referencing this commit.
COLTON OGDEN: Makes sense.
KAREEM ZIDANE: The cool thing, though, is
that if I do ls to list the files on my current directory, I see foo.
But if I switch to master, I don't see foo.
COLTON OGDEN: Nice, OK.
KAREEM ZIDANE: So it's that easy literally
to switch between different states of your project.
So if you do git log again I don't see new-feature1 at all here
and I only see my commits from earlier.
So this is also one of the really handy features of git.
COLTON OGDEN: So [INAUDIBLE] says, how can we
think of branching, like a new path?
KAREEM ZIDANE: You can think of branches as a sequence of commits.
We don't really need to get into the details of how these are exactly stored
or how they are handled by git for now.
This is probably for an advanced git tutorial.
But for now, yes, you can think of a branch as simply a sequence of commits.
COLTON OGDEN: So if I wanted to make a feature in our repo
separately from you, I can make my own branch
and you can keep working on your own branch or on master.
And then later on we can sort of mix them together.
KAREEM ZIDANE: Correct.
That's exactly right.
COLTON OGDEN: That makes sense.
So that way you and I aren't working on the same exact branch--
KAREEM ZIDANE: Correct.
COLTON OGDEN: --and then having merge conflicts.
KAREEM ZIDANE: Yeah.
If we have time actually we're going to demonstrate this pretty soon.
So what else do we want to do?
We showed creating branch.
We showed switching to a branch.
You might want to delete branch.
So you were experimenting with something and you figured, hey,
we don't need this branch anymore.
We don't need any of these changes anymore.
So me list my branches one more time using git branch.
Suppose I want to delete the new-feature1 branch in this case.
So the way to do this is git branch --delete and then
the name of the branch, which is new-feature1.
But git prints an error in this case, saying the branch new-feature1 is not
fully merged.
If you are sure you want to delete it run git branch -D, capital D,
new-feature1.
And git is trying to be protective and helpful here in this case
because it knows that some of the commits that I made on new-feature1
don't really exist in any other branch yet.
It doesn't want me to lose any of these changes unnecessarily.
So it prevents me from deleting this branch if I do git branch again.
All branches are still there.
But it tells me, if you're absolutely sure that you
want to get rid of this branch you can just do git branch -D new-feature1,
and now we deleted a branch.
Just confirm.
There you go.
COLTON OGDEN: Nice.
OK, pretty easy.
Looks like Andre has a question in the chat.
Larger text.
KAREEM ZIDANE: So branches are in fact stored locally on a machine
so you can switch between various branches of your project
without actually having a connection to a git server?
Yes, that's absolutely right.
[INAUDIBLE] all repository history are stored on your local [INAUDIBLE] system
and you can switch between any of them anytime you want.
COLTON OGDEN: I guess it would come into play if you
had your own branch on your computer and I had a branch in my computer
but we hadn't pushed it to GitHub yet.
That's when we would have issues actually.
We wouldn't be able to communicate our changes that way.
KAREEM ZIDANE: Correct.
COLTON OGDEN: [INAUDIBLE] distribute them or centralize them
somewhere so that we can grab each other's information.
KAREEM ZIDANE: Yeah, so my copy of the project and its history
is completely separate from the copy that you
have of the project in its history.
I can create however many branches on my local [INAUDIBLE] system
and you don't see them until I push to GitHub.
Then if you sync your local copy, then you're going to see them.
COLTON OGDEN: Good question from Andre.
KAREEM ZIDANE: That's a follow up question.
You're not getting it wrong.
This is exactly right.
OK, what else do we want to do?
We showed deleting a branch.
Let's actually show merging changes in this case.
So let's switch back to our new-feature branch, and then, I don't know,
let's copy files.
We could do from froshims.
That would be, let's see, five maybe?
Let's actually do [INAUDIBLE] file.
In this case, create a dummy file, add it, commit it.
Status [INAUDIBLE] verify, commit it.
Now if I want to merge these-- now recall
that if I checkout master again and switch back to master.
And ls the files, I don't see foo, my new file.
If I want to merge all the changes from my new-feature branch, all I got to do
is git merge new-feature while I'm a master.
COLTON OGDEN: [INAUDIBLE] says take whatever is in this branch
and try to combine it with wherever I currently am, basically.
KAREEM ZIDANE: Correct.
And in this case, git verifies that the changes were merged.
And if I do git branch again I'm still on master.
If I do ls I see foo now.
COLTON OGDEN: And there was no conflict because it was a separate file that
didn't exist, right?
KAREEM ZIDANE: Yeah, that's actually a great idea.
Let's demonstrate a merge conflict.
So now let's get rid of--
actually, by the way, let's demonstrate this first.
If you do get branch --delete--
I think there is a shortcut for this.
I don't remember it.
Maybe dash lowercase d--
new-feature.
Remember that previously [INAUDIBLE] complained about this, having
changes that were not merged yet.
Now that we've merged these changes into another branch,
[INAUDIBLE] try and do this, it's just going to happily delete it.
COLTON OGDEN: Nice, OK.
KAREEM ZIDANE: So now I only have master and I am on master.
I could do git checkout -b.
Let's see.
I don't know, fix-bug.
Now I should be on fix-bug.
Now suppose I do foo.
I open foo and I add a new line here.
Save my changes, git status.
Hey, foo was modified. git diff.
Here is the line that was added.
And git commit.
What did I forget to do in this case?
I should add it first to the staging area,
so git add foo or git add all in this case
because foo is actually all essentially in this case.
Git status.
Hey, foo is in the staging area.
It's ready to be committed.
Git commit -m added new line.
Trying to be a little bit more descriptive here.
Git checkout master back.
If I open foo again I don't see my line because this line
was committed on another branch.
But suppose you're working directly on master, which is not recommended.
You should create your own branch.
But just for the sake of saving time here,
suppose Colton's working on master and he opened foo
and he added no my new line.
COLTON OGDEN: So greedily, yeah.
KAREEM ZIDANE: So here's how foo looks like now.
Do a git status.
Hey, foo was modified.
Git add foo.
Git status to verify that we have the things that already being committed.
Commit -m added Colton's.
Colton, new line.
Now if you do git log here is the commit.
Suppose we try to merge the changes from new-feature.
What do you expect is going to happen?
COLTON OGDEN: Probably bad things.
KAREEM ZIDANE: Probably bad things.
You have good intuition.
And not something we can merge.
COLTON OGDEN: That's a really bad thing.
KAREEM ZIDANE: Interesting.
That's weird.
That shouldn't have happened.
Git branch.
Oh, because we called our branch fix-bug not new-feature.
So git merge fix-bug now.
Still bad things happen.
But now git is telling me, hey, there is a conflict
and it's yelling at me that there is a conflict.
There is a merge conflict in foo.
Automatic merge failed, so git could have merged this automatically.
Fix the conflict and then commit.
So again, git is trying to be very helpful here.
If we take a look at foo now, notice this weirdness.
So there is a bunch of symbols and stuff, but we also see my line
and your line in both.
COLTON OGDEN: I think this is what Andre also was alluding to before with XML.
KAREEM ZIDANE: Yeah, maybe there is another format
where you could output these changes.
I think this should be easily machine-parsable as well
if you want to do this, but the point is not
about the format in which these merge conflicts are shown.
It's more about git is not sure which of these to take.
If it knew it would take these pretty easily,
but git doesn't know in this case.
So in this case me as a human I have to, or I have a human,
I have to fix this merge conflict manually.
And I can do this by favoring my line or Colton's language,
I'm going to do in this case.
So I'm just going to delete my line and these weird symbols,
save, git status, git commit in this case.
Sorry, git add foo first.
Git status.
All conflicts are fixed here.
If I do git status, git confirms that all conflicts are fixed.
Now all I need to do is git commit and it's going to open up text editor,
showing commit message, save, git log again.
Here is the merge commit that we had.
And if open foo, now Colton's new line is actually the one that's there.
COLTON OGDEN: Nice.
So I'm just moving the chat at [INAUDIBLE] request.
It's a little bit obtrusive, and it looks
like Elias also has a question too.
How do remove a file from git without removing it from your file system?
KAREEM ZIDANE: How do you remove a file from git without removing it
from the file system.
That's a good question.
I think you would need to do two things here.
The first one of them is actually remove the file from the repository using
git rm, and then ignore the file using gitignore to have git not
track this file again.
COLTON OGDEN: Sure, makes sense.
Is there a way to avoid git from actually even trying
to merge in that case--
referring to the merge that we just tried to resolve--
Or some way of detecting potential conflicts?
KAREEM ZIDANE: That's a great question.
I think there is a way to abort the merge in this case.
Let's see.
What are we looking at?
Try to reset the state of this to the previous commit maybe,
so let's git reset hard to the previous commit, which is 039d whatever.
Log.
That didn't work.
What are we going to do?
We're now on the previous commit in this case, which is--
foo didn't have anything.
Weird.
So let's do this again real quick.
I messed up something here.
New-line.
That was the one on master.
And if I switch back to--
let's add this.
Let's add this, commit this, add it, new line.
Switch back to fix-bug, check out fix-bug, git branch.
Now if I show what's in foo, I should see--
I should have added something else there.
Check out master.
Sorry about that.
My new line in this case.
My new line, checkout fix-bug.
So now if I try to merge this, I should still see a merge conflict.
OK.
I actually lost track of something.
Added a new line.
Which commit is this?
Oh, we're still on fix-bug, so we should probably
switch out to master first because that's
the branch that we want to merge into.
So git checkout master, git merge fix-bug.
In this case, I should still see the merge conflict, and I think--
is there git merge --abort?
Yep, there you go.
So if you do git merge --abort, I think it just canceled the merge
and not show any merge conflicts right here.
COLTON OGDEN: So that will just keep whatever was in master?
KAREEM ZIDANE: Yes, correct.
COLTON OGDEN: OK, that makes sense.
So this merge conflict is done when two people are working on the same file.
Am I getting it right?
KAREEM ZIDANE: That's correct.
Same file and actually same part of the file.
Because if you're working on different parts of the file,
git knows how to merge these changes.
That's great.
So we resolved merge conflicts.
I wanted to actually briefly demonstrate collaborating with someone.
So working on GitHub essentially.
And for that we're going to need to have accounts.
So I have mine here, which is a fake account.
COLTON OGDEN: You want me to collaborate with you in this case.
KAREEM ZIDANE: I hope GitHub doesn't flag us.
COLTON OGDEN: That would be unfortunate.
KAREEM ZIDANE: So the main thing that we need to understand about GitHub
is that it's a hosting service, which means
what GitHub does for us is actually allow
us to have a remote copy of our repository and history on their servers
so that everyone can sync with that, remote copy,
push changes to it to save it somewhere else so it's not just
on your local system.
Fetch new changes from it and so on.
So for that we're going to need a GitHub account.
If you're new to this you should go to github.com/join to create your account.
I just signed into mine here.
And the way to create a new repository I think
is by clicking on this little plus icon here and then choose new repository.
And I hadn't thought about the name, so I'm just going to call it froshims.
In this case, I'm going to make it a public repository.
I think GitHub might allow you one free private repository.
I don't remember.
I have to check this out.
COLTON OGDEN: Yeah, I think it was a limited amount.
Two or three or something like that.
KAREEM ZIDANE: So if you'd like your repository
to be private, not publicly accessible on the internet,
you should probably mark it as private.
In this case I just don't care, so I'm going to have it as public.
Create a repository.
COLTON OGDEN: [INAUDIBLE] cool, that's a lifesaver for the git merge abort,
or whatever it was.
KAREEM ZIDANE: Yep, definitely.
Yeah, definitely.
It's definitely a completely valid case that you want to change your mind
and I don't care about these changes anymore.
So you can just abort them as easily.
So now that we have this remote copy of our repository,
it doesn't have anything in it, obviously.
And GitHub is trying to be helpful here and giving us some instruction
on how to get started with this.
In most cases, people might have actual code on their local file systems,
and we just need a way to tell GitHub hey, GitHub--
or we need a way to tell our local repository that hey,
you should be syncing up with this remote repository from GitHub.
And the way to do this is by adding a remote.
And the way we add a remote is git remote add,
I think, and then we should choose a simple name for this remote.
By default, it's going to be origin I think.
And then the URL of the repository.
So we can just copy this from here, paste it here.
Git remote add origin and then this.
If this works as expected, you should do git remote -v
to list the remote repositories.
And in this case git is saying, hey, I'm going
to be syncing with this particular GitHub repository from GitHub.
COLTON OGDEN: Nice, and so now we've established that connection.
We can push to them and get code from them.
KAREEM ZIDANE: Correct.
And notice that git is actually listing these separately for fetch and push,
and this is because it's actually possible to read from some repository
and push to some other repository.
COLTON OGDEN: [INAUDIBLE] server or something that you want--
KAREEM ZIDANE: Yeah, we're going to briefly talk about forking soon.
But suppose you want to contribute to some open source project on GitHub.
You want to ideally sync with this project, as well as your project.
[INAUDIBLE] literally set the fetch URL to be the upstream,
or the original project, on GitHub.
And instead of pushing to that one, which ideally wouldn't be allowed,
you can just push to yours or your copy of it.
Your fork.
COLTON OGDEN: Looks like we have a couple of comments.
[INAUDIBLE] if I'm pronouncing that right.
He says, whoa, is that David Blaine on the right?
Do you know who David Blaine is?
Are you Familiar
KAREEM ZIDANE: No idea, I'm sorry.
COLTON OGDEN: Real quick.
This is very important.
This is David Blaine right here.
He's a very famous magician.
KAREEM ZIDANE: Oh, interesting.
He's not bald though.
COLTON OGDEN: Go to my screen for a second
so we can see some pictures of David Blaine.
KAREEM ZIDANE: Wow.
COLTON OGDEN: I think he has been bald occasionally.
[INAUDIBLE]
KAREEM ZIDANE: How did he get rid of it?
COLTON OGDEN: I don't know.
Maybe he was never bald.
Maybe he just had really short hair at times.
KAREEM ZIDANE: Maybe.
That's fair.
COLTON OGDEN: David Blaine and GitHub everybody.
KAREEM ZIDANE: I also think I have short hair all the time.
But anyway--
COLTON OGDEN: Another comment.
GitHub is basically like a storage facility for our files.
So can we both put stuff there without sharing our user name and password?
KAREEM ZIDANE: Definitely, yes.
I mean, if you have to share your username and password every time
you put something on GitHub that wouldn't really be ideal.
So yes, you can put stuff there without sharing any usernames or password.
You can give people access to it without sharing your username and password
with them, which is a neat feature as well.
But GitHub is actually not just a storing facility.
GitHub has a lot of features.
We'll hopefully explore them briefly.
So we're going to see about this.
So now that I let my local repository know that hey, you should be syncing up
with this remote repository on GitHub, one thing I can do
is simply push my current branch, which is master in this case.
So the way to do this is git push origin, which is the name of my remote
as you can see here on the left, and then
master, which is the name of my local branch.
So if I do this--
hopefully if the internet cooperates in this case.
So I'm seeing a prompt right now for my username and password
because obviously, I don't like anyone to be able to push to my repository.
So in this case, I'm going to provide my username, which is cs50student2--
my password, which I'm not going to say.
COLTON OGDEN: [INAUDIBLE].
Kareem the Dream 1990.
KAREEM ZIDANE: It's something like that.
So now git confirms that it pushed my changes to my remote repository.
If I refresh this page, I should hopefully
see my master branch has exactly the same content as my local master
branch has at this point.
COLTON OGDEN: Like a file system view of all the files on that snapshot
[INAUDIBLE] snapshot.
KAREEM ZIDANE: Not just that.
I think you can actually work directly within GitHub
and edit files and stuff, which is really--
COLTON OGDEN: Oh, that's true.
Use the little pencil icon.
The chat's blocking it.
KAREEM ZIDANE: Yeah, it's a really cool interface to browse your repository
or browse other people's repository without necessarily
having to have a local clone of them.
COLTON OGDEN: [INAUDIBLE] other things like issues,
pull requests, projects, a lot of different features too.
KAREEM ZIDANE: Yeah, we can briefly introduce some of these features.
Before we do that, though, I wanted to mention a point
on cloning a repository.
So suppose Colton is completely new to this
and he wants to make some contribution to my repository,
or just wants to get a local copy for my repository to experiment with it.
The way to do this is by clicking this, getting
the URL of the repository-- copying it essentially.
And if I go to a separate directory here, temp, I can do git clone,
paste the URL, enter, and it cloned my repository.
And notice it also cloned the history of my repository, which is really neat.
And this is what we meant earlier by this [INAUDIBLE]
version control system.
COLTON OGDEN: Everybody, whoever downloads your repo,
has all of the history in there for their own version of the entire version
control system.
KAREEM ZIDANE: That's exactly right.
And the cool thing though is that you are actually in control of this,
so you can actually clone only certain branches or even
only a certain number of commits from these branches without--
imagine a huge repository with a huge history.
It's going to be really difficult to download on some networks,
so you can just clone a limited number of these.
COLTON OGDEN: Sure.
Makes sense.
KAREEM ZIDANE: All right.
So do you want to switch to your computer now to make a tiny change?
COLTON OGDEN: Sure, OK.
So [INAUDIBLE] go to mine.
Let me go to my GitHub.
By default it's going to show my dashboard here.
So I want to go to your repo, so what's the URL of your repo again?
KAREEM ZIDANE: The URL of my repo is github.com/cs50student2
COLTON OGDEN: cs50student2--
KAREEM ZIDANE: Slash froshims.
COLTON OGDEN: Slash froshims.
KAREEM ZIDANE: And we mentioned earlier that random people on the internet
won't have-- not that Colton is random people but--
any other username or GitHub username won't have push access
to this repository.
So what probably Colton wants to do at this point
is actually fork this repository or create his own copy on GitHub first.
So the first thing you need to do is actually
click on the fork button on the top right.
COLTON OGDEN: OK, so this button right here.
KAREEM ZIDANE: Yup.
I don't think it shows up here.
COLTON OGDEN: Oh, it's not visible on the chat there.
We'll just hide the chat just for a second.
[INAUDIBLE] says, I can't believe that's Colton from the lectures.
Can you edit the code from Docker?
[INAUDIBLE] thanks for tuning in.
KAREEM ZIDANE: I'm actually using the Docker container right now.
I'm inside of a Docker container.
So yes, you can use git or edit your code inside of a Docker container.
COLTON OGDEN: Thanks for joining us.
I'm going to go ahead and hide the chat box just
for a second so that we can see the web browser in its entirety.
And then, you said click this fork button right here.
KAREEM ZIDANE: Yup.
COLTON OGDEN: OK, I'm going to click that fork button [INAUDIBLE]..
I'm an owner of multiple organizations on GitHub.
We won't talk about that.
I'm not an owner but an admin, rather.
I'm going to fork it.
KAREEM ZIDANE: That's gonna take a while.
COLTON OGDEN: --personal account.
So now I can just clone it, like you said.
Go down here.
And now I'm seeing that now it says, github.com/coltonoscopy/froshims,
no longer cs50student2.
KAREEM ZIDANE: Exactly because this is your own, as you mentioned, copy
of this repository on GitHub.
COLTON OGDEN: Nice.
So when I make push changes to this, you won't be able to see them, will you?
KAREEM ZIDANE: Nope.
I won't be able to see them until you actually create something called a pull
request, as we see.
So the way to do this is to switch where you want to clone this.
COLTON OGDEN: I'm in the game stream folder from yesterday.
So I'm going to go into my dev.
I'm just going to-- oh yeah, and streams,
and then I'm going to I guess clone it right here.
So git clone, which is a command that you showed before.
KAREEM ZIDANE: Correct.
COLTON OGDEN: And then I just paste in that .git URL and then clone it,
and then boom, I have everything.
So now if I hit ls, I should see I have the froshims folder.
I can cd into that froshims folder, hit ls again,
and I notice that I do have all the files that were in that repo.
KAREEM ZIDANE: So now maybe you can make any changes, like opening the files,
adding new lines, or add new files.
Colton can forward the same workflow that we have been following so far.
COLTON OGDEN: So I don't think I have a fancy CLI editor,
but I'll use nano on application.py maybe, which is--
KAREEM ZIDANE: I honestly don't know how to use nano except for saving.
COLTON OGDEN: It's a pretty bare bones editor,
but let's just say that I wanted to maybe add
a comment at the top or something.
So I go up here, do that, and then Colton's version.
And then I can save it with Control X, Y, Enter.
KAREEM ZIDANE: Git status to see what changed.
COLTON OGDEN: Right.
And now we see the same red message from before which says modified,
although it's red here and I think it was green.
Was it green for you before?
KAREEM ZIDANE: No, it becomes green when it's added to the staging area.
COLTON OGDEN: Oh, right.
KAREEM ZIDANE: So you can do git diff actually to see what changed.
COLTON OGDEN: Right.
So git diff, and then we'll see indeed.
Since my terminal color scheme is green--
KAREEM ZIDANE: Which shows a plus sign in this case in front of it.
COLTON OGDEN: So Colton's version and then this blue stuff.
I forget exactly what this means.
KAREEM ZIDANE: I think this refers to ranges of the file that are changed.
So in this case, I think the first line, the third column?
Or I don't know.
The first line I guess, or move three characters,
added five characters or whatever.
I don't know.
COLTON OGDEN: Yeah, I'm not sure either.
KAREEM ZIDANE: But it refers to certain ranges of line numbers and columns
in the file, Essentially.
COLTON OGDEN: Cool.
So then now I've done it.
[INAUDIBLE] git status.
[INAUDIBLE] made the change but I haven't actually
committed it, which is what we did before.
KAREEM ZIDANE: Correct.
Before you commit [INAUDIBLE].
[INTERPOSING VOICES]
COLTON OGDEN: It looked like the video signal chopped off.
So now I want to commit, right?
KAREEM ZIDANE: You have to stage it first I think.
COLTON OGDEN: I think you can just commit, right?
KAREEM ZIDANE: You can do this in one step, but usually people do it in two.
COLTON OGDEN: I don't.
I usually commit directly.
That's OK.
Walk me through.
KAREEM ZIDANE: So git add application.py.
And now if you do git status again, you should see this in green.
COLTON OGDEN: [INAUDIBLE]
KAREEM ZIDANE: Now this is staged.
This is ready to be committed.
If you do git commit -m and then your commit message.
COLTON OGDEN: So Colton's version.
KAREEM ZIDANE: You don't have to add the a.
The a is actually--
COLTON OGDEN: To add as well.
- KAREEM ZIDANE: --to add as well, yes.
COLTON OGDEN: OK, so that's why I guess I always commit,
because I always do the -a flag.
KAREEM ZIDANE: Yeah, the downside of -a I
think is that it doesn't account for untracked files.
COLTON OGDEN: Oh, I always git add those manually,
so I guess my workflow's a little bit different.
KAREEM ZIDANE: If you think [INAUDIBLE] to git add [INAUDIBLE]
you can obviously do this.
COLTON OGDEN: Maybe it's better practice to do it
the way that you're describing.
KAREEM ZIDANE: I personally always do git add first.
COLTON OGDEN: I don't think I've set my--
I thought I set my config yesterday but I guess it's not set.
But that's OK.
KAREEM ZIDANE: You can just copy these commands if you want.
COLTON OGDEN: Global user [INAUDIBLE].
KAREEM ZIDANE: While you're doing this I'm
going to try to answer this question.
So suppose I clone something from user 1, made changes
as commits to save on the main person's stuff.
Won't it mess up the original repository?
I don't think so.
This is completely going to be on Colton's copy,
both locally and remotely.
And we'll see now, what if Colton later wants to actually propose these changes
to the original repository?
So we'll explore this in a bit.
So I guess you're all set up with--
COLTON OGDEN: So I committed and I can push now if I want to.
KAREEM ZIDANE: Can I see git log just to verify that you committed?
COLTON OGDEN: Oh, sure.
KAREEM ZIDANE: Awesome.
Great.
So there is your commit.
Now you can exit this queue and git push.
So it pushed right now.
Previously, I was more verbose and specified origin master.
Truth is, git doesn't always know what the default remote branch should
be that would be synced with this current local branch because, recall,
they are separate.
And so you can always configure this using--
my computer got locked here.
You can always configure this using git push -u, lowercase u, or --set-upstream
I guess to sync local and remote branches with each other.
So now that Colton pushed, can we check your GitHub repository?
COLTON OGDEN: Sure, let me switch the view to my laptop right there,
go back to Chrome, and then refresh the page.
It still kept the John Harvard name on this account for some reason.
Git config doesn't seem to be working on this user.
I have to figure that out.
KAREEM ZIDANE: There are multiple levels of configuration,
so probably you have a narrower scope.
So now that Colton has--
can you open application.py just to verify that it has your comment in it?
So suppose Colton thinks that these changes
should be actually added to my repository,
my copy of the repository on GitHub.
One way Colton can do this is by actually opening a new pull request.
And the way to do this is if you go back to the repository,
there's a new pull request, as you can see here.
COLTON OGDEN: Oh, sorry.
[INAUDIBLE]
Creating a new pull request.
KAREEM ZIDANE: And notice that it's recognizing my repository right here
on the top left.
COLTON OGDEN: Oh, yeah.
The base fork.
KAREEM ZIDANE: So it's saying that, hey, it's
going to try to apply these changes to this branch
from the original repository.
And now Colton can create a new pull request.
COLTON OGDEN: It also shows the change here too.
KAREEM ZIDANE: Exactly.
And this is also one of the nice features about GitHub.
It shows you a graphical user interface for what we practically
were able to see using git log--
sorry, git diff in this case.
So if verify [INAUDIBLE] new pull request,
you're going to have to give it a title by the [INAUDIBLE] commit message,
and you can specify more details if you want.
And the nice trick about this is that GitHub actually
uses some version of markdown here.
So if you, for example, type something-- type anything.
Like suppose it's a more specific description
for your pull request in this case.
If you click on Preview, this is what's going to show.
If you go back to write and then add a hash in front of this,
it's going to convert it to a heading.
COLTON OGDEN: Nice.
KAREEM ZIDANE: There's actually a GitHub guide on these markdown tricks
that you can do to format your detailed pull request in a neat way.
So once you're happy with all your changes,
you could just click create pull request one more time.
Now, ideally, I'm going to see this if I have notifications actually enabled.
I should receive an email about this.
But ideally notice that pull requests here are-- one, if I go to this tab,
I'm going to see Colton's pull request.
And also, a few neat features of GitHub, I
can assign this pull request to certain people to take care of.
I can review this pull request.
I can give it certain labels if I want.
I can add custom labels too, and so on.
So these are some--
COLTON OGDEN: You can add continuous integration,
which we might talk about next week.
KAREEM ZIDANE: We might talk about continuous iteration deployment maybe.
That will be also me.
So I can also comment on the pull request.
This has nothing to do with the code whatsoever.
We can just add, hey, Colton.
I am expecting this to be like this or that's good.
Good job.
Or any other number of comments that I could add about this pull request.
Once I'm happy with Colton's changes, notice
that I also can see what changed using the file change interface here--
button, tab.
If I go back to the conversation-- and then once I'm happy,
I can just click Merge, Confirm Merge, and now I've
actually merged the changes from Colton's remote repository.
If I go back to my repository, open up application.py,
I can see Colton's comments here.
So this is pretty much it for pull requests.
There are also features that Colton alluded to earlier.
These are more like if you want to create a bug reporter for something
in this project, or if you want to request a feature,
or if you want to ask a question even.
You can also use the Issue feature of GitHub to create a new issue.
And notice the interface is pretty similar to the one
that you had briefly for a pull request and also uses the same markdown version
so you can just also format it in a good way.
I think that's pretty much it for GitHub.
One more thing that I think we should show that I actually forgot is--
I guess we're at a perfect time to show this.
So now that I am in my--
let me get back to my repository--
froshims.
Actually, if I do git locally, I don't really
see Colton's commit here in this case.
So the way to sync up with my version of the repository on GitHub
is using the git pull command.
So if I do git pull origin master, or if you converted this,
it can do this for you by default--
if I do git pull origin master, hit Enter,
it's going to fetch the changes from the remote repository now.
I do git log again, and now it's your commit.
If I open application.py, go to the top line, I can see your comment.
COLTON OGDEN: And we're all synced up.
KAREEM ZIDANE: Yeah, we're all synced up.
So this is one workflow that people follow to collaborate.
COLTON OGDEN: [INAUDIBLE] original user has the final say.
That's very cool.
KAREEM ZIDANE: Yeah, definitely.
I mean, we have pretty much an infinite number of open source projects.
Imagine that anyone can do anything to them.
That would be pretty bad, so it's good to have this sort of permission model
and restrictions.
COLTON OGDEN: But you have the ability to contribute to anybody else's code
if they approve of it.
KAREEM ZIDANE: Correct.
Yes, that's absolutely true.
All right, I think that's all what I have for now.
We can stick around for a few more questions.
COLTON OGDEN: Yeah, let's stick around for just a couple
of minutes for some questions.
Thanks for coming in to give us a talk--
KAREEM ZIDANE: Thank you so much.
COLTON OGDEN: --on git and GitHub.
And thanks everybody who tuned in today.
We had 15 viewers here.
We had upwards of 20 at some point.
KAREEM ZIDANE: That's great.
COLTON OGDEN: That's some good numbers.
KAREEM ZIDANE: That's exciting.
COLTON OGDEN: A lot of regulars in here today too.
And so on the horizon, you see you might have some potential other topics
you want to talk about?
KAREEM ZIDANE: Yeah, at least we should probably
talk about some continuous integration deployment techniques and tools.
That will be interesting, I think, and that's something
that we are actually using besides git and GitHub here at CS50.
Long story short, the idea is we are able, through these tools,
to automate some of the testing and deployment of our projects,
which is really cool.
One thing that I just remembered is talking
about how check50 and submit50 work.
They are built on top of git and GitHub.
So they essentially do something like this, so committing your changes,
pushing them to a remote repository underneath the hood,
just in a slightly different way.
But they essentially use the same principle
to push your code to some of our organizations on GitHub
or accounts on GitHub.
And from there, we actually do some automation
to actually create these automatically.
COLTON OGDEN: I think a lot of people would probably
be interested in seeing a more thorough walkthrough of how
submit50 and check50 works.
KAREEM ZIDANE: By the way, there are actually open source as well on GitHub,
so you can go to github.com/cs50/check50 and see the latest version of check50
right now.
Or submit50 to see the latest version of submit50.
Submit.
Did I spell that right?
There you go.
So that's submit50 as well.
COLTON OGDEN: [INAUDIBLE] pushed the last the last commit there.
KAREEM ZIDANE: On August 15th.
COLTON OGDEN: Merged a pull request, which we just talked about.
We've got a couple of comments in the chat there.
Did you answer the question about suppose
I closed-- yeah, you did the clone one?
KAREEM ZIDANE: Yeah.
COLTON OGDEN: Does the repo have to be public, or original user
can share a link if it's private?
KAREEM ZIDANE: That's a great question.
So in case it's private, anyone that's going to try to clone this repository
is going to fail to do that.
Git is going to refuse to clone it.
GitHub is not going to allow this data to be given I guess.
So if I go back to my froshims-- if I go back to the sitting step--
suppose this is a private repository, which it's not in this case,
but suppose it's a private repository.
I can click on Settings, I can click on Collaborators here on the left,
and then here I can actually add usernames like coltonoscopy-- right?
Is that your--
COLTON OGDEN: Yeah, coltonoscopy.
KAREEM ZIDANE: Colton's--
COLTON OGDEN: You're missing a T.
KAREEM ZIDANE: Sorry.
COLTON OGDEN: Colonoscopy is slightly different.
KAREEM ZIDANE: Wait, colonoscopy?
COLTON OGDEN: It's a coltonoscopy.
I think you wrote colonscopy.
KAREEM ZIDANE: I did write Colton first.
COLTON OGDEN: O-S-C-O-P-Y.
KAREEM ZIDANE: That's not true.
Do you want to spell it?
COLTON OGDEN: It's not working?
KAREEM ZIDANE: Yeah, that's awkward.
There you go.
I was spelling it incorrectly.
COLTON OGDEN: I couldn't read it from here.
KAREEM ZIDANE: So I can specify Colton's username, add a collaborator,
and once Colton accepts this invitation--
COLTON OGDEN: I think I'd have to go into my--
KAREEM ZIDANE: Yeah, do you want to switch to yours first here?
COLTON OGDEN: Would I have to go into my email to do that?
KAREEM ZIDANE: Not really.
You can just go to the same repository, which is
mine in this case, slash invitations.
COLTON OGDEN: Slash invitations on the repo?
KAREEM ZIDANE: I think so.
There you go.
COLTON OGDEN: Nice.
KAREEM ZIDANE: And then you can accept.
I think you do receive an email about this as well.
COLTON OGDEN: Yeah, I think that's where I usually click it to accept it.
KAREEM ZIDANE: So now if you go back to my screen, if I reload the page,
now I see that Colton's actually a collaborator here.
COLTON OGDEN: Now I can actually push directly to--
KAREEM ZIDANE: Now he actually has push access to my repository in this case.
I remember there was once a menu that allows you to give
read only access to the repository.
COLTON OGDEN: I think I remember that as well.
KAREEM ZIDANE: I don't see it here, but it might be present in other contexts.
But usually there is a menu that lets you give people
read only access to this repository.
COLTON OGDEN: Irene has another question there too
if you want to read that one off.
KAREEM ZIDANE: Why would you recommend forking project as opposed
to creating a new branch?
So these are two different things.
Forking a project is creating a copy of some project
into your own GitHub account, while creating a branch
is something that we do within a project.
So these are slightly different if that makes sense.
COLTON OGDEN: And then can you change the GitHub name, like froshims?
I was not able to change it.
KAREEM ZIDANE: I guess if you go to Settings options
you should be able to change the repository name,
so long as you don't have a repository within your own account
with the same name.
So that should be possible as well.
So Settings options, and then repository name.
COLTON OGDEN: I think my mic has been dead this whole time.
I just realized, which is great.
KAREEM ZIDANE: Wow.
Nobody commented on that.
COLTON OGDEN: Yeah, Dan just Slacked me.
We're always at the end of the stream, so I'll just piggyback off
of your microphone, I guess.
KAREEM ZIDANE: It's interesting no one commented on that.
COLTON OGDEN: I'm not sure why.
KAREEM ZIDANE: Maybe it got, like, I don't
know-- it interrupted in the middle of the stream.
COLTON OGDEN: Pretty cool.
KAREEM ZIDANE: All right.
What other questions do we have?
COLTON OGDEN: Oh, we were talking about the things
you might work on in the future.
KAREEM ZIDANE: Yes.
So I think we briefly talked about this.
So we're going to be probably using a service like [INAUDIBLE]
to automate some of the testing and deployment of some of our projects
for us.
And by that I mean, suppose you have the CS50 library, for example.
We ideally want to add some unit tests to this library that
checks that the functionality of the library actually works as expected.
And ideally, every time someone pushes to this repository
it's going to automatically run these tests
and indicate some failure if one or more failed or success otherwise.
Then by deployment I mean, hey, once this is all ready,
we can just push a new version of this repository--
sorry, new version of this library to whatever service
[INAUDIBLE],, for example, in case of it's a Python library.
COLTON OGDEN: On Friday, I'll be doing another game stream, so the memory card
game.
And then one of our teaching fellows, Nick [INAUDIBLE],, who was in the chat,
might pop in potentially.
We're gonna talk about [INAUDIBLE] machine learning,
some AI stuff if anybody's interested in that.
But as always, if anybody does have any suggestions
for particular topics or streams or anything
that you'd like for us to do on camera or program on camera
what not, definitely let us know because we have quite a few folks who
have different specialties around here.
KAREEM ZIDANE: Last question.
What is an organization on GitHub?
That's a great question.
An organization is a slightly different type of account on GitHub.
So for example, in CS50 we have the CS50 Organization in this case,
and that's because we don't want to host all the projects that we work on
in someone's account.
So an organization allows us to do this--
host more than one repository without actually hosting them
in one individual account.
COLTON OGDEN: [INAUDIBLE] has another question too.
KAREEM ZIDANE: I want to know about [INAUDIBLE]..
Is that inside the [INAUDIBLE] 50?
Would it let me allow multiple terminals?
Can I do something like that on PC?
I'm not really sure about the PC options.
There might be something like [INAUDIBLE],, which
is a terminal multiplexer in this case.
I used one here on Linux, which is indicated
by this really green bar at the bottom of the screen, which
I don't think we can see right now.
But [INAUDIBLE] is a terminal multiplexer.
Essentially, it allows you to create more than one terminal window
within the same window.
And yes, it exists on [INAUDIBLE].
But I don't think you need it really on the IDE
because you can always create a new terminal tab pretty easily.
But yes, it should be installed by default in the IDE.
So is that a separate account?
Yes.
The CS50 Organization is actually--
you can think of it as a separate account type that more than one of us
has access to it.
I guess you could create a new organization somehow.
Let's Google this real quick.
So GitHub actually has a very useful help guide here
that lets you know how to create a new organization.
COLTON OGDEN: Is that a premium feature?
Can you do that with a free account or do you need to have a--
KAREEM ZIDANE: That's interesting.
So if I go to Settings--
COLTON OGDEN: I guess maybe it would be like you could have public repos on it,
but private repos are probably [INAUDIBLE] premium account.
KAREEM ZIDANE: Yeah.
I haven't actually tried to create one before, so let's experiment with this.
Froshims.
If we go to Settings--
or is it Account Settings?
It's Account Settings I think.
Why did I go to repository?
Organizations here.
New organization and then--
COLTON OGDEN: OK, it looks like you can free,
and then you have to pay for the other ones it looks like.
KAREEM ZIDANE: So it looks like it supports unlimited public repository
for private ones you'd have to pay.
COLTON OGDEN: Cool.
TIL.
All right.
It's going to be about 5 o'clock.
We'll probably end up closing it off here.
KAREEM ZIDANE: OK, thank you so much for having me.
This was really--
COLTON OGDEN: Yeah, thanks for coming on and doing it.
If anybody is watching this on YouTube after the fact,
definitely come follow us on twitch.tv/cs50tv,
where you'll be able to join the live chat in real time and talk with us.
And then maybe we'll do some collaborative stuff in the future.
David [INAUDIBLE] in the chat, everybody.
[INAUDIBLE] you can say hi to him right now.
KAREEM ZIDANE: Hi, David.
COLTON OGDEN: [INAUDIBLE].
Kareem and Colton, thank you for an interesting stream.
Thanks for coming, Bella.
Appreciate it.
Thanks, David, as well, and thanks [INAUDIBLE]..
Thank you.
Very informative, says [INAUDIBLE].
Thanks, [INAUDIBLE] as always.
And then Nick says, thanks guys.
Powerhouse of the cell.
KAREEM ZIDANE: Thank you so much.
COLTON OGDEN: There we go.
All right.
Cool.
Thanks, everybody.
We're going to close out now.
And again as a reminder, we're going to stream again
on Friday where we'll do the memory card game.
Last word, Kareem?
KAREEM ZIDANE: That's exciting.
I want to thank you all, and see you next time.
COLTON OGDEN: Cool.