SPEAKER: All right,
welcome to this seminar. It's going to be about Git and
GitHub, which are technologies that you can use to do what's
called version control, keeping track of different
versions of your program, testing out new changes, et cetera. All right, so before we get started,
we'll do a quick introduction into kind of what Git and GitHub it is all
about, and what it can be used for, and then we'll go more
specifically into of the command line commands that you would use in
order to use some of this technology and leverage it for projects
that you're working on, or projects that you're
collaborating on with other people. So first of all, what is Git? What can it do? The first, and one of the most
important features for Git, is that it can keep track
of changes to your code. So if you have code, you create a
file, and maybe you're making changes, Git will keep track of all
of the different changes that you've made to your
code such that, at any point, you can kind of go back and
see the history of whatever it is that you've been working on to
see what were your earlier changes and when did you make those changes. And that can sometimes help when
you're going back, and trying to debug, and figure out what went
wrong at some stage in the code process. So that's one thing that
Git can be useful for. Another thing that it can be
useful for is synchronizing code between different people. Especially when you're
collaborating with other people, Git is valuable for trying to make
sure that your code potentially matches the code that
someone else is working on. And at any point, absolutely feel free
to interrupt me if you have questions. If something doesn't make sense, I'd
be happy to field questions as we go. So imagine that you and
a collaborator are both trying to work together on the same
piece of code at the same time. So maybe that code lives
somewhere on some server, and there are a whole
bunch of servers that can host what we call
get repositories, just folders that contain files
that are tracked via Git. GitHub is one example of that. So maybe both you and your partner
need access to the same file. Maybe you both make
changes to that same file. And what Git allows
you to do is Git makes it very easy to then take those changes
that you both have made independently and then kind of merge them back
together when you push them back online to the same file and then pull
those back down to your own computers. So that you both have
the latest changes, not only what you've changed
on your file, but also what a potential collaborator
has made changes to as well. And you both have the most recent,
up to date version of the code. And so synchronizing code
between different people is another really valuable
thing that Git can be used for. A third valuable thing that get
can be fantastic for is to test changes your code without
losing the original. It's all too common that,
before I started using Git, would try making changes to
code to try to make it better and then suddenly find out
that the code no longer works. And so my original solution
to this was to do something like make a copy of my
original file, save the old one and then make changes so
that, if it messed up, I could go back to the original
one and not lose the original. And that ends up getting
very, very messy. Especially if you get into
larger projects, and working with multiple people, you'll end up
with a lot of different old versions and it might be hard to keep track of. So Git makes it very easy to save
an original version of your code, test out new changes that
you might want to add, and, only when you're sure that
you like these changes, that they work that you want to
what's called merge them back in with your original file, can you
merge them back with the original file that you were working
on in the first place. And the fourth and very valuable
thing that Git can be useful for is for reverting back changes
to older versions of your code. Say you made a change to your
code somewhere along the way and realized later on that that's
not the change that you actually wanted to make, and that you would
want to go back to an older version. Git makes it very easy. As long as you know which
version you want to go back to, you can just go back to that
old version and kind of start over from wherever you were previously. So that's sort of an overview
of kind of what Git is and the things that Git can do for you
if you leverage its functionality well. And now we'll begin to go
into the actual commands that you would need to use
and need to type in order to make all of this kind of work. Questions Before we go on? OK, fantastic. So first command that will
be really valuable to know is what's called git clone. git clone is a command you
would type at the command line, and I'll show you how
this works in a moment. And essentially, what
git clone does is you type git clone followed
by some git URL where that URL is the address of some GitHub
repository-- and remember a repository is just a collection of files and
folders that are being tracked by Git-- and it'll don't make a copy of that
repository that lives somewhere on the internet, potentially
on GitHub, but there are also other services that do similar things. And it will make a copy of that
repository on your computer. So you can begin to make
changes on your own computer. And side note, you can
also do something called Creating a fork of a repository,
where if someone else owns a repository online
somewhere, you can fork it, which just means you create kind of
your own copy of that repository that also lives online. But we'll get to that potentially later. So if this is Github, imagine
this being some kind of server, and this is a file that's being
tracked via Git in some Git repository. If I were to type git clone followed
by the URL of that repository, then this file, I would
clone it, and it would make a copy of the entire repository
that is now saved on my own computer. Make sense? OK, fantastic. The next thing that's important to
know is a command called git add. So git add is what you would do
after you've cloned a repository and so now you have a copy of
that repository on your computer and say you're making changes to
that repository, changing the files, changing the code, and now you want
to say that the next time that git saves a change to this
repository, you want git to save the change that
you made to that file. So let's show you what I mean by this. Let's say that we've
just cloned this file. So this file now exists
on your computer. It's being tracked by a repository. If I make a change to the code,
maybe add a line to that code, and I want to say that, the next time
you save a change to this repository, I want you to track
that change, you would say git add followed by the
name of the file, whatever that file happens to be named. And then, it would, say
change is to be committed. And it would track that this is a change
that you now want to make to that code. So let me show you what
that looks really quickly. I have here GitHub repository. So they usually live at
some link, like github.com, slash some user name-- my
user name is [? BrianU28 ?] slash whatever the name
of the GitHub repository. Is in this case, this repository
is just called seminar. Up in the upper right
hand corner, you'll see a button that says
clone or download. And if you click on that
link, it will give you a link that you can
copy in order to clone this repository to my own computer. And so I could copy this. And then I could go in to CS50 IDE. And then, if I were to type
git clone followed by that URL, it would clone the repository
and save it to my computer. In this case, I've already done it,
so I'm not going to do it again. But you'll see, here, I have
this folder called seminar. And that folder is just my copy of
the repository that exists on GitHub. So we'll take a look at
the file that's in here. There's two files in here. But [? swap.c ?] is the
one that I'm interested in. You might recognize this
file from a previous lecture. It was just the file
where we kind of set two variables equal to two different
numbers in C, and we want to swap them. But what you'll notice here is
that this code is incomplete. It says swapping right now, but we
don't actually swap the values just yet. So what I'd like to do now is
I'm going to change this code so that it actually
swaps the two numbers. And then I want to git
add those changes so that git knows that this is
a new version of the file that I want to save. So I'll just quickly
add the necessary code, and those three lines are
going to swap the file. And so now if I cd into the
seminar directory, what I can do is I can add the changes
that I just made, and git will then track those changes
so I can save them in the future. And in fact, one kind of little
tip that might be helpful is that if I ever type
[? git dif ?] at the command line, it will show me all of the changes that
I've made that I haven't tracked yet. So I type git dif, and
it shows me down here that these are the three lines
highlighted in green that I've added. I added this in temp equals x,
x equals y, and y equals temp. And those are now changes that,
the next time I add a file, they're going to be tracked by git. So I can do something
like git add swap.c, and that will add the
swap.c file as a file that I now want to track the
next time I save a change. So git add swap.c. And so that now has been added to
the changes that I want to track. So what's the next step? The next step is called git commit. Once I've added all the files
that I now want to save, now I need to actually make the Save. So git commit you might think of
as the equivalent of telling git to save a version of this repository. So the syntax looks something like this. You would type git commit
followed by -m, and then, in quotation marks, some message. And that message is just going to be
usually some summary of the changes that you've made in
this particular change so that if anyone were to go
back and look at what we call the commit history, they would
be able to see all the changes, and when you made those changes,
and what changes you made at any given stage in this program. So that's what git commit is. And it saves those new revisions
of a repository and kind of records a message along with it. And just as a side note, if
you'd like to combine the adding and committing steps
together into one step, this command right here git commit
-am, a for all, or a for add, will automatically add all
the files that you've changed, and also commit it
with a commit message. So you can combine both
of these steps together. So I'll show you what this looks like. When I type git commit and follow
it by kind of a message suggesting what it is that I've changed, then what
git will do is it will take my file, and it will save kind
of a new version of it. It'll save this version, which
says that I've added a line. It saves the message
along with the commit. But it also still
remembers that old version. Such that if I ever wanted to
go back to that old version, I could still do that. So I'll show you what
that looks like right now. So I'm back here, and
I've made these changes. I've already added them. So I can do git commit -m. And then, in quotation marks,
actually swap the values. And that's going to
be my message saying, here's the change that I made when I
just made these changes to the code. And so I see this what's
called a commit hash, which is just an identifier about the commit. And it says I've changed
one file and added three lines, which is indeed true. I added three lines to
this file in swap.c, and those are the changes
that I have just now saved. So what can I do now? git status is a helpful command,
where, at any stage in working on a git repository, if you ever want to see kind
of what's currently going on in the git repository, you can use git status
to gain some kind of insight into what's currently happening,
what are the changes that I've made to my current repository. And so the way that works is
that if I were to type git status into the command line, I
would see a message show up that says, what is the current
status of my repository, and the message might look
something like on branch master, and git ads has a feature which we'll
get to in a moment called branching, which basically lets you keep track
of different versions of your code, so you can have kind of different
separate tracks of your codes. So if you want to test changes, or
try and to implement new features, you can do that separately from
kind of the main part of your code, where master we consider to
be kind of the default code. And the second line here says, your
branch is ahead of origin master by one commit, which is just kind
of a fancy way of saying that, that version up here on
the server, this version that we have is one commit, or one
version, ahead of that version. So we've saved one change
that the server up on GitHub doesn't yet know about. Clear so far? OK. And I'll show you exactly
what that looks like. I can type git status right now, and
it will tell me that exact same thing. I'm currently on branch
master, and CS50 IDE is really nice in that it actually
tells me, right here in my prompt, what branch I'm currently. I'm on the master branch. And it says that I'm ahead of origin
master, which is the version that lives up on GitHub by one commit. So one revision ahead. So now, now that I'm one revision
ahead, how do I then take those changes and, what we call, push
them back up to GitHub so that the online version that can be
accessible by anyone looking online, or accessible by collaborators who are
also using the same online repository, can then see? And that git push is the
comment that we would use. And so the syntax for that
is just git push, which will send whatever committed
changes we've made up to the remote repository up on GitHub. I can be very explicit and
state exactly what branch I want to push to, as in git
push origin master, meaning push these changes to the master branch. But generally, you wouldn't need
to do this for normal purposes. So I would say something
like git push, and then this new change, the change
that I made on my computer, would then get pushed up to GitHub
so that anyone looking online would then be able to see
those changes that I just made. And so I'll show you what
that looks like right now. If I go back here. So again, I did git status. I'm ahead by 1 commit
because right now I've added these three lines that
actually perform the swap. And on GitHub, if I were to look at
swap.c, this is online on GitHub, swap.c doesn't have
those lines right now. On the online GitHub version,
it just says swapping. But if I go back into CS50
IDE, and I type in git push, those will push those
changes back up to GitHub. And if I go back to GitHub
and refresh the page now, I'll see that, indeed, these
three lines that I just added have now been pushed up online. And if you actually go to github.com
slash [? brianu28 ?] slash this whole link, you'll be able
to see this exact same thing because this repository is public. So those changes have
now been pushed online. Questions on how that worked? Fantastic. OK. So now git pull is
another valuable command. git pull is kind of the
opposite of git push. If git push means I made
changes on my computer, and I want to send them up to GitHub so
that the online version knows about it, git pul is GitHub contains a more
recent version of the repository than I have on my computer. And I'd like to take
those changes from online and pull them down onto
my computer so that I can see the most recent version
of the repository that's currently reflected on GitHub. And so the way that
would work is, if someone were to make a third
change to this repository, and my computer only had these
two revisions to the repository, I could say something like git
pull, and this third change to the repository that was added would
then be pulled down onto my computer so that my computer now has all the
versions that are matched on GitHub. So I've actually set up
a second IDE workspace. So this version has all
the changes we just made. In this version of my
workspace over here, which is a completely different
workspace, inside swap.c, I haven't updated it to
the latest changes yet. Because I haven't done a git pull. So it still says
swapping, and it doesn't have the latest version of the code. So if I want to pull from
GitHub, get the latest version, I would cd into the seminar directory. And then I could say git pull. And so it will pull the
latest changes from GitHub. And you'll see that it says,
fast forwarding this swap.c file. It changed one file, added three lines. And indeed, if I go to swap.c now,
that file that I just changed, you'll see that those three
lines that were on GitHub but weren't on my computer
before are now on my computer because I did git pull, and so those
changes are now reflected there. Clear on that? Fantastic. All right, let's talk
about merge conflicts. This is the part of git that
can often scare a lot of people. But don't worry. It's actually quite manageable. So here comes the question of, Git
seems to be very good at automatically tracking what changes I've made to
a file-- where I've added new files, where I've removed lines,
I've added new lines to code. But what happens if I'm working
on code, on a particular line, and I make a change to line 28,
say, and some collaborator also makes a change to that
same line, and we both try and push that code up to GitHub? Git's not going to be able to know
what to do about that situation because it doesn't kind of which version
of the code to believe, so to speak. So this creates what we
call a merge conflict, when, in trying to combine two different
versions of the repository, there's some sort of problem that
Git can't automatically resolve. And so you, the programmer,
need to figure out how to resolve that conflict. And so here's what that might look like. Maybe if you try and git pull,
and you're pulling in new changes from GitHub, but those
changes conflict with changes that you've made on
your computer, you might get a message that looks like this--
conflict, the merge conflict failed. You need to fix the conflicts
and then commit the result. And so this might be
what your file would look like after you get this merge conflict. You might get a situation where you
have a whole bunch of lines of code, and then this weird kind of series
of less than signs followed by head, a bunch of equal signs, and then
a bunch of greater than signs, followed by some weird sequence
of numbers and letters. This is what a merge conflict
might actually look like. And just to break this down for
you, here's what all this means. Everything between head and the set
of equal signs are all of the changes that you made that are in conflict. So changes that you've
made on your computer. Everything between all
of these equal signs and this series of greater than
signs are all of the changes from GitHub that you're trying to
pull down that are in conflict. So what happened here seems to
be that the online version seems to have said in b equals 0,
but my version, on my computer, I've committed, that b
should be equal to 2. And those were the same line. So when git tried to
merge those two together, it didn't know which line to go with. And so that's why we're
getting this conflict. And this random sequence
of numbers and letters right there is the conflicting commit. Every single commit gets
a unique identifier, just a sequence of numbers
and letters, and so this is telling me which is the
commit from GitHub that is causing this conflict,
that is the reason why I'm not able to merge these two together. And so what do you do in
a situation like this? To resolve this merge
conflict, all you need to do is get rid of this head line,
the equal line, the greater than line, and then figure out what
to do about these conflicting lines. You might delete one set
and only use the other. You might somehow find a way to
combine the two, but, in some way, you need to tell git what the actual
version of the code should look like. So in this case, we might
get rid of all the lines except for b equals 2 because b equals 2
is the version that I know that I want. You can get rid of
the extra space there. And after that, I
could commit this file, and now that would be
the version that's saved. I've now resolved the merge
conflict by specifically telling Git which version of
the code that I want to use. So let's try and create a
merge conflict right now so we can see what that looks like. In one version of my IDE, I'm going
to take this x, which is right now 28, and I'm going to set it to--
pick a number, any the number. 51. 51. And I'm going to git commit am. And I'll say so, what I'm doing here is
I'm adding this change that I just made and committing it, saying
I'm going to change x to 51. So I've made that commit. It notes that I've
only changed one file. It says one insertion, one deletion. What that means is I deleted the
line that says int x equals 28, and I added the line that
says int x equals 51. It doesn't know that I
changed two characters. It knows that I got rid of a
line and replaced it with a line. I can git push now. And so that change [? pushing ?]
[? changing ?] x to 51 is now online. So if I go to GitHub, and I
refresh this, right now x is 28. Now I see that x is 51 because
that's the change that I just pushed. Now, in this other
version of the repository, where x is still 28-- why don't
you pick a different number? AUDIENCE: 17. SPEAKER: 17. And I'm going to say git
commit -am change x to 17. So I'm saving that change. And let's say now I wanted to
pull the changes from GitHub, make sure I have the
latest version of the code. I've changed x to 17 here. The version on GitHub has
a recent change that says, we've changed x to be 51. So when I git pull, watch
what's going to happen. I'll close this file for
now, but I press git pull. And it says conflict,
merge conflict in swap.c. The automatic merge failed, so
git couldn't merge these two files automatically. I need to fix the conflicts
and then commit the results. So let's open up swap.c
and see what's going on. And you'll see, oh,
and CS50 IDE actually adds some nice little markers that
help us understand what's going on. But we see this head, and
we see this commit hash, and we see what the
different versions are. This is my version that
says int x equals 17. And this is their version
that says int x equals 51. That's the version that we
just pulled down from GitHub. So I need to decide kind of
which version of the code that I actually want to use. Maybe I don't know. And maybe I just want to go with, I
don't know, the average of the two. We'll do like, what is it, 34? And then I would get rid of
these lines that are conflicting. I'm not too used to the
syntax, but-- oh here we go. So I would just say int x equals 34. And I'll get rid of
all those extra lines. And so I've now changed this code,
gotten rid of all those excess lines, and just replaced it
with kind of the line that I actually want-- in this case,
the one that says index equals is 34. At this point, I can do git status,
just to see what's going on. It says that I have unmerged paths. I need to fix the conflicts
and run git commit. I will do git commit, -am, and I'll
say, I'm going to commit these changes. I just fixed the merge conflicts. So now it says I fixed it. I can now git push, which
takes these changes I just fixed the merge conflicts. I'm going to push them
back up to GitHub. I git push. And now, after that's done, I can
go back to GitHub, refresh the page, and x is now 34. And this is my resolution
to this merge conflict. Kind of a lot of stuff happening
simultaneously, but that makes sense? Any questions on how that merge
complex happened, why it happened, or what we were able to
do in order to fix it? All good? Fantastic. OK. Let's move on then. git log is another very useful feature. And git log's job is,
basically, it will tell you kind of the history of all of the
commits that you have made previously. So it shows the history of the
commits and their messages. So if I do something like git log,
and type that into my terminal, then something like this will
show up, where it will show me a history of all the
commits that I've made. It will show me the kind of
commit ID, or the commit hash, that identifies that commit. It will tell me who made that commit. So if multiple people are
collaborating together, it will tell you who
made the change, when they made the change,
on a particular date, and then this message here is whatever
you said was the commit message. So that's why a commit message
can be very, very important. Because when you use git log, you'll
see all the changes that were made, and the message is a very
good indicator as to what was changed in this particular version. So make sure you use good commit
messages if you're going to use git. Questions on git log? I'll show you what that looks
like in the actual terminal. I can type in git log at the terminal. And it will show me all
these changes that I've made. So I added the swap file, changed x
to 17, fixed these merge conflicts. Those are all the changes, and you can
see kind of when I made those changes and who made those changes. Clear? Fantastic. All right, so now let's
say I made a change, but I didn't mean to make that
change, and I want to kind of go back to a previous version of the code. That's what git reset is for. That allows I mean to kind of roll
back, these changes didn't work, I want to go back to an older version. And here's how that works. So recall that every
one of our commits has a commit hash, some
unique identifier that says this is how we identify
this particular change. And down here, next to
the commit messages, I've included the first couple
characters of those commit hashes. If I type git reset [? dash dash ?]
--hard, followed by some commit hash-- and usually you don't need to include
the entire commit hash because usually it's dozens upon dozens of characters. Usually just a couple of characters,
at least enough to uniquely identify that commit so that no other commit
has those same initial characters is sufficient-- if you type that,
it will revert your code back to that previous version, and
you will lose all of the changes that you've made sense that version. So do this only if you
were sure that you want to go back to the previous version. In addition to going back to a previous
version in your commit history, you can also go back to the version
that currently exists on GitHub. So if there were a version on
GitHub, which is our origin, in this case, the origin
of the repository, and we've made changes on
our computer, and now we realize those changes really don't
work, and really want to go back, you can use git reset
--hard origin slash master, to go back to the version
that's on GitHub and its master branch. And again, we've only been
working on the master branch so far, so that's the only thing
that we really have to work with. So I can type git reset
--hard followed by 476 1626, where that is the beginning
of the commit hash for this version of the repository. And again, if I don't know
what the identifier is, I can always use git log,
that code, that command that shows me the history
of all the comments that I've made along with when
I made any particular commit and what changes were
made in that commit. So that can give me the
identifier, and if I do git reset, then these changes that I've made
after that file will kind of go away, and I'll be left with this
being the most recent version. And so that's what I'm
going to have left over. Any questions on that? OK, let's get into
talking about branching. So branching is a very,
very valuable feature in git that basically allows you,
in a single repository, to have a couple different kind
of versions of the code that are going on simultaneously. So maybe you have one version of
your code, your master branch, that's generally the one
that works perfectly, or that does what you need
it to do, and maybe you want to add new features
to your program, or you want to add something
brand new to your code, but you don't want to
potentially mess up the master branch because that one you know works. So one thing you can do is
you can kind of branch off, creating a new branch that
you're making new changes to, testing out new features, while keeping
your original master branch identical. And then you can make
commits to this new branch. You can roll back those commits
and do all the same things that we were just talking about
previously in the seminar. And then only when you feel ready that
this new branch has all the things that you want it to have and is ready
to kind of become the official version, can you then merge it back
into the master branch so that you then have
the one working version. So let's explore how
you do that branching. So just to recap, branching is
a version of the repository. Each branch has its own commit
history, and each branch has its own kind of most
recent version of the code. So git branch is the
command that you would use in order to create a new branch. So if I just type git branch, it will
show me all of the current branches that I have on the repository. But if I want to create a new
branch, I would type git branch followed by the name of the branch. And I could just make up
any branch name I want, so long as it's not a name that
already exists as a branch. And then, once I've
created a new branch, if I want to switch to that new
branch, I would use git checkout. So git checkout, followed
by the name of the branch, will switch me to that
new branch that are going to be working on that other branch. And side note, if you want to kind of
combine these two steps to check out a new branch and create
it at the same time, you can use git checkout -b, and
then followed by a new branch name, and that will both create a new
branch, and it will switch you to it. That can just be a little
time saving feature. So right now, I just have
one version of the code. It's the master branch, the
original version, by default. And if I were to tight git branch
tests, that would create for me a new branch called tests that
basically will just be a copy of master, at least for the time being, creating
that new version of the code. So then, I can make new
changes to this test. I can add files to it. I can make commits, so saving
reversions of this test branch, and then later, once test
is the way I want it to be, I can merge it back in with master. And so we'll look at that right now. Git merge is the command
that we would use to merge two different
branches together, and the way that works is like this. git merge, followed by some branch name,
merges that branch with whatever branch I am currently on. So what that means is that if I
am currently on the master branch, and the tests branch now has
kind of a whole bunch of versions to the code that have been made so it's
got a whole bunch of files that have been changed, and I now want
to take those changes and say, I want to bring them
into the master branch. Then the command that
I would use here would be something like git merge tests. And that would take all these
changes to the test branch. And it would merge them
with the master branch so that the master branch now
reflects all of those changes. Now, there may be the possibility
that, on the master branch, I've made changes to
the same lines of code that the test branch
also made the changes to. And in that case, when you try and
merge tests into the master branch, you're going to run into
another merge conflict, and we've talked about
how to resolve those. But basically, it involves getting
rid of those lines you don't want, and then figuring out
how to take the two kind of different versions
of the code and figure out which version you actually want. So that's, oftentimes, a possibility
that you'll run into, especially on larger projects, where multiple
people are working on the code simultaneously, and potentially
working on different branches, it may very well be the case
that merging two branches can result in a merge conflict. So let's take a look
at how this might work. So as you can see, right now, I'm on
the master branch of this repository. And I can see this even more clearly,
if your terminal doesn't display what branch you're on,
just by typing git branch, and that will tell me that there is
only one branch in this repository, and it is called master. So let's say I want to
create a new branch. Let's say I want it to separate out this
code, the code that does the swapping, into its own function. But that seems like it has
the potential to go wrong. It might not necessarily work. So I don't want to
just change this file. I want to create a new branch that
will let me test out those changes without worrying about whatever
is happening in master. So I'm going to create a
new branch via git branch, and I'll call it function just
because the purpose of this branch is I'm going to be creating a new
function in order to perform the swap. So I type git branch function. And now, if I were to
type git branch, you'll see that I have two branches going here. I've got a master
branch, and it's green, so that says that's the
branch I'm on right now. But there's also a function
branch that appears now. That's the branch that
I've just created. And if I want to switch
to that branch, I would type something like
git checkout function. And it says, switched
to branch function. And so now, if I type git branch, I
would see there are two branches still, function and master, but function is now
the green one with the star next to it. That's the branch that I'm currently on. So now I'm on this function branch,
and I can add this swap function, void swap, int star A, int star
B, and in temp equals star a, star a equals star b,
and star b equals temp. And I can now replace this with just
swap address of x, address of y. That should work, right? Hopefully, it works. I'm going to commit those changes. I'm going to say add a swap function. And so that change was just made,
and so it says one file changed, I added eight lines,
removed three lines. And so that commit is there. But now, if I type git branch, I can say
I'm currently on the function branch. If I were to check
out the master branch, the git checkout master, what you'll
notice is that swap.c changes. It changed back to the version
that's on the master branch because the master branch
doesn't have new function. It just has these three
lines of code that are right inside the main function. Watch again, if I git checkout
back to the function branch, watch what happens to swap.c. It will just immediately
show me, here's the version that's on the function branch. And so those are those changes. Question? [INAUDIBLE] Yeah, so on the Mac Finder,
if you do a git checkout, and maybe this new branch
has, like, has a file that didn't exist on the
other branch, that file will appear in your file system. So it absolutely works. And so now maybe I'm
happy with those changes, and I want to-- let's
actually make sure it works. [INAUDIBLE] [? 34505034. ?] Fantastic. That did in fact work. So now I feel comfortable merging those
changes back into the master branch. So I'm going to go to the master branch
via git checkout master, and notice, once again, this is the version
that's currently in the master branch, and my function branch has that
new commit that I want to merge in. If I type git merge function,
what that's going to do is it's going to take the
changes on the function branch, and it will merge them
into the master branch so that that new commit, that version
where I made the new function, will now become part of master. And there shouldn't
be any merge conflicts because I haven't changed master. So I press Return. It makes those changes. And now this is my master branch,
and I have that swap function. And you can show, if I type git
branch, I'm still on the master branch. But that new function that I
created in the function branch now exists in master. And at this point, if I wanted to,
I could delete the function branch, because I no longer need it. And the command to do that is git
branch dash-- capital -D, for delete, followed by the name of the branch. So git branch dash -d function
deleted branch function. So now, if I type git branch again,
I only have the master branch, and if I were to git log to look
at all the commits that I've made, I would see that out
of swap function is now there as a commit in the master
branch because I merged those commits into that particular branch. Any questions on how that works? And so merging and having branches
is a very, very powerful tool. And I would highly recommend it when
you're working on your final projects. Because if you want to kind
of be a little bit ambitious and potentially test
new changes to the code, this can be a good way of
making sure that you still hold on to the original
while still allowing yourself the creative freedom to experiment, and
make changes, and mess with the stuff that you've already written. All right, and last thing
I'll kind of briefly touch on but won't do a demonstration of
something called pull requests. This happens very frequently in
open source projects, especially. But if you've made a change to a
repository, either in a separate branch or potentially in a fork, like I
mentioned earlier, where a fork is just kind of your version of
someone else's repository, sometimes you may want to request
to kind of merge those changes back into the original version. And so this would be when
you would submit a pull request, as the terminology goes. And so if you hear that,
know that all that means is that you've made
changes to some repository, either in a different branch, or in a
different forked repository altogether, and you would like to
then kind of merge it back into whatever the original version was. And this is typically
done via a pull request. And GitHub has functionality built
into it to allow for pull requests to happen and to allow for whoever owns
the repository to kind of review pull requests, look at the changes
that people have made, and either decide to approve
or reject those changes. So once again, Git is
a very valuable tool that helps you keep track
of different changes your code, makes sure different
collaborators can work together on the same repository, makes
sure you can be ambitious and test new changes without losing the
original copy of your code, and also allows you to, if
you ever do make a mistake, to go back to a previous version. So as long as you are kind of frequently
making commits, saving the work that you're doing, this can
be a very, very valuable tool for keeping track of the
different versions of your code and making sure that your
project is under control. I'll take any questions now, but
that's what I had for you today. All good? All right, fantastic
thank you both for coming. AUDIENCE: Oh, question. [INAUDIBLE] SPEAKER: Oh, yeah. So submit 50 is-- OK, let me make
sure I'm remembering this correctly. Submit 50 is, basically
what that's happening is, every time you submit 50 something,
you are submitting kind of a new branch to your submit 50 repository. So when you type in
something like submit 50 p set 7, what was happening
is, behind the scenes, we were creating a new
branch called p set 7. And we were kind of pushing
all of those changes to GitHub as a brand new branch. So if you were ever to go to GitHub.com
slash submit 50, slash your username, that, in itself, is a repository. Each student in the
class has a repository. And within that repository,
there are branches for each of the different times you submit 50. So there's a submit 50 for
Mario, there's a image 50 for 15, there's a submit 50 for the test. And each one of those are
just different branches that are named with whatever
the name of the problem is and the name of the problem
set, or the name of the test. And so whenever you do a Submit 50,
it pushes those to a new branch. And then what we do is we, like,
tag those changes as a new release such that it makes it easy for us to
kind of look at all of the changes that you've made. We didn't go into tagging
and releases in this seminar. But it's just yet another
way of kind of keeping track of different versions of code
and keeping track of different changes to it. AUDIENCE: [INAUDIBLE] SPEAKER: Yeah, yeah. That's typically what
it would be used for. Exactly. And so when you submit
something, that's kind of our semantic equivalent of saying
that you've now supposedly gotten your problem set working, and this
is the version that you want graded. And if so, we'll tag those. That's kind of the way it works. Good question, though. OK, thank you so much.
