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.
