[MUSIC PLAYING] BRIAN YU: Welcome back to CS50 Beyond. Hope you all enjoyed lunch. Feel free to help yourself to
pizza now still, if you'd like, as we go through this afternoon. A bit of a change of
pace this afternoon. So we spent the morning
talking about HTML and CSS, which you had seen in CS50, but
we went a little bit beyond that, looking at other features of HTML and
CSS and more modern versions of both. What we're going to do this
afternoon is take a look at Git. And so just for show of hands-- actually, let's do via the faces. If you've used Git before and you feel
comfortable with it, green smiley face. If you've never used it
before, red frowny face. If you're somewhere in between, yellow. OK, so sort of all over the place. A bunch of people have used it before. A bunch of people have
never used it before. So if you've never used it before,
this will be a good introduction. Even if you have used it
before, hopefully you'll get a bit more of an
understanding of it here. Git is what we call a piece
of version control software. It's software designed to
help us manage and track different versions of our code. And it is incredibly helpful. If you ever go on to take
future computer science classes, or you go and work for a
computer science internship, or work in computer science
industry, you will almost definitely be using Git as your
means of keeping track of different versions of your projects. And so it's good to have an
understanding of it and how it works. So today is going to be a bit
of an introduction to that, give you an opportunity to see
the various features of it, get an opportunity to practice with
it hands-on later on this afternoon. And then in the latter
part of the afternoon, we'll also take a look
at SaaS, which is a way to generate CSS code, which we'll
take a look at in a moment as well. But questions before we begin
on anything from this morning, anything about the
structure of the class or, logistics of what's going
to happen this afternoon? All right. Let's go out and get started then. So we're talking about
Git today, and Git is a piece of version control
software, as I mentioned. And it's good for a number
of different things. So the first thing that Git
is particularly good for is for keeping track of
changes you make to your code. I remember when I first
took CS50, I would be working on a problem
in the problem set, and I would work and get like
part of it working, but not quite. But I'd be afraid that
if I added more, I would break the stuff I had already done. So I'd save a duplicate
copy of the code somewhere, make changes to another
copy, and pretty soon, you have four or five different
copies of the same program that are all slightly
different, and they just become a little bit
tough to keep track of. Maybe some of you had similar
experiences, definitely something that happened to me. This is before I learned how
to use Git, which is primarily designed for trying to deal
with problems like this, keeping track of changes you make to your code,
such that you have a full revision history, so to speak, of
all the changes you make. So you might have initially created a
file, made some changes to the file, added a line to the file,
removed a line from the file. And Git is going to help keep track
of all of those different changes we make to the code so that we have a
record of all the changes we've made. Another thing that Git
is particularly good for is for synchronizing code
between different people. So you might imagine
that you have some file that you and a collaborator, a
partner, are working together on. Maybe it's a partner you're working on
in a problem set in a class together, or a bunch of people that you're working
with on the same software project, if you're working for the
same company, for instance, and you're sharing some file
that you're working on together. And what Git makes it easy to do is
to give both you and your partner the same version of that file, such that
you can both independently be making modifications to that file, change
different parts of that file, and then eventually
synchronize them back up together in some sort
of central server, such that you can both then get that updated
version of the file, where the idea is you can both be independently
making changes to the code, synchronize them somewhere so that you
both have access to the latest version. No more emailing, like, this is
the latest version, use that one. And then there are conflicting
versions being emailed around and that starts to become messy. Git helps to just simplify that
process, keep track of everything much more cleanly. Another thing that Git
is good for is it's good at testing changes to
your code without losing the original copy of the code. So you might have
something that's working, and you might want to add a new
feature to your website, for instance. So you might want to tackle the
next part of the problem set. But doing so might involve breaking
the stuff you've already made and you want to save that. So what git makes it
very easy to do is say, branch off, a term that we'll
explore more in just a moment. But say, try something else for a
little bit while keeping the original. And only when we've tried it and it
works and we're feeling comfortable with it can we then merge it back
in with the original code, such that we now have the original
version of whatever it is that we were working with. And finally, Git is very good at
reverting back to old versions of code. You've made some changes
and you decide the feature you have is not a feature that you want,
or you decide that what you've done has a mistake in it, a bug, you want
to go back to a previous version. It's very easy to just
say, you know what? Go back in the revision history. Go back to a previous
version of that file. So questions about the goals here, the
problems that we're trying to solve? And then we'll introduce
Git and see how it actually goes about solving those problems. All right, a website you may or may
not be familiar with is called GitHub. You should all have GitHub accounts
that you made when you took CS50, or in some other time. And what GitHub is going
to do is it's going to be a website that's going to
host what we call Git repositories. And the word "repository" you can think
of as just meaning a folder where we're going to contain the code files
that we're going to track, the code that we want to keep track
of different versions of and synchronize
between different people. It's just a folder where
you're going to store code. And so GitHub is an online place
to store those repositories, such that you can put code
there, and then different people can access that same shared repository. So I'll show you an example of that now. I'll go ahead and go to github.com. You'll be brought to an interface
that looks something like this. And in the upper right, you'll
see a little Plus button. If I click on that, there's a button
there that says a New Repository. So you click on that, New Repository. You're going to give
that repository a name. I'll just call it Beyond for now. You can give a description if you want. You can make it public, meaning anyone
can access it, anyone can see it. You can also make it private. GitHub recently allowed
any user, even for free, to create private repositories. So if you don't want other
people to be able to see it, you can make it private as well. I'll make this one public. And you go in and create the repository. And what this is going
to do is just create an empty folder, an empty
repository, on GitHub servers, wherein I can begin to
store code, eventually. So that's all I've done, created a
new repository on GitHub's website. So now, what are the commands
that I can run on the command line to interact with this Git repository? Well, the first thing I need
to do is this repository is located on GitHub servers. I want it on my computer so that
I can begin adding files to it, looking at the files that are in
it, making modifications, and such. And so a command that we're
going to use is called git clone. And so what git clone is going to
do is if I have my computer here and I have some server that's got
the code that I want to clone locally onto my computer, I run the command
git clone, followed by the URL are all of the repository. And what that's going to do
it's going to make a copy. It's going to take the repository,
locate it up somewhere on GitHub servers, and it's going to copy it
and bring it down onto my own computer so that I have a copy of that
repository on my local machine. What questions do you have so far? OK. I'll actually do this so you
can see what it looks like. What I have here is a URL. And there are going to be two different
URLS, an HTTPS URL and an SSH URL. If you set up SSH with
GitHub-- there are instructions for how to do that on the
GitHub website-- you can use that URL. That involves something called
public-key cryptography, which we'll talk about later in the week. But if you haven't set
that up, you're probably safest using the HTTPS URL for now. I'm going to use the SSH
URL, but either will work. And you'll go into your terminal. I'll go to my desktop. And I'm just going to type git
clone, followed by that URL. And that's going to do is it's
going to clone that repository. And it says, "Warning. You appear to have cloned
an empty repository." But that's fine. I know that the repository is empty. But if I look at the folders
that are inside of my desktop right now-- recall that LS is a
terminal command that stands for list, list all the files and
folders in this directory. What I'll see is I have
a directory now called Beyond, the same name as the repository
that I had just a moment ago. If I move into the Beyond
directory by typing CD-- CD for Change Directory,
or move into a folder-- CD Beyond, I'm now inside
the Beyond directory. And if I type LS, nothing happens. There's nothing inside of this folder. But I have now cloned
this folder so that I have a copy of the
repository on my computer. So that's git clone. Questions? Yeah? AUDIENCE: Sorry, can you
show where you got the URL? BRIAN YU: Yup. So the question was,
where did I get the URL? When you create a new
blank repository, you should get a URL that shows up here. If you have files in the
repository, this interface looks slightly different. But there will be a dropdown
where you can clone it and there should be
a link there as well. So what I'd like to do now is add
some files to this repository. Maybe I want to put my website
that I was creating this morning inside of a gate repository, which
would allow anyone to see it, anyone to put modifications to it, allow
multiple people to collaborate on it, for instance. And so to add something to a Git
repository, the command we run is just called git add. And so quite simply what happens
is that if I have a file, and I make some changes to it and I want
to add these changes to the next time that I save a version
of the repository-- and instead of save a
version of the repository, the terminology we're going to
start using is the word "commit." Whenever I say commit, just think of it
as this is a version of the repository that I'm saving. And we'll save the entire history of
commit so that anytime I make a commit, it's going to save that as
a version I have access to. And so if I want to
say, this is a file I want to include the next
time I make a commit, I'm going to run a command called git
add, followed by the name of the file, foo.py, or whatever
the file happens to be. And that's basically telling
Git that foo.py, this is a file I want to
include in my next commit. And so I'll actually give that a try. And when you do that, Git
will give you a message letting you know that this is
now a change that you can commit. And so let me go ahead and create
a new file inside of this folder. I'll call it hello.html. Touch is a command that you can use just
to create a file, an empty file, if you want to called hello.html. I'll go ahead and edit that file. And we will put a very
simple hello.html file that I've now put inside
of the Beyond directory. If I type LS, I see that
hello.html is there. And now, if I type something
like git add hello.html, nothing seems to have happened. But I have now added
hello.html as a file that I want to include
in my next commit. I've told Git that this is a file
that should be in the repository. The next step is to actually make this
change, to actually commit this change. And so how might you do that? The command is just git commit. And so what does that look like? You type git commit
dash m-- m for message. And then, in quotation
marks, you're going to include what's called
a commit message, which is just an English phrase
or sentence describing what it is that you changed in this commit. And that could be anything you
want, but the rationale for this is that when you're going back
and looking at your history, it becomes very clear what
changes you made when. And when other people are
looking at your repository, it becomes easier for them to
understand what changes you're making. And this is especially useful
if people are collaborating. You can see what other
people have been up to, not by trying to read every single
line of code that they've written, but, in particular, by looking
at their commit messages, to see a description in English of
what it is that they've changed. So git commit dash m
followed by the message. And you say, OK, this is what I did. I just added a line to the file, some
message to describe what you did. And that's going to take your code and
just save a new version of that code with all of those changes in it. So that's git commit. We'll go ahead and give that a try. I'll type git commit dash m, and
I'll just say add a hello file. This is what I did in
this particular commit. I'll press Return. "Your name and email address
were configured automatically." Yeah, that's fine. I haven't yet set up my name and email
address on this particular computer, and that's something
that you'll probably need to do the first time that
you start working with Git. So OK, questions so far
about what we've done? Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: Oh, good question. So the question is, are there
now two versions of this file? If I just look inside of the
Beyond directory right now, I only have one copy of hello.html. And if I show what it's inside
of it by saying, cat hello.html, it's got the contents,
the most recent contents. And so if I were to just look at the
files themselves, they'll look like-- right now, at least-- whatever my
most recent version of the file is. But separately, Git is storing
all of those previous versions, I just can't see them right now. But yeah, good question. All right, so maybe now I want to
get a better understanding of what's happening inside my Git repository. A command I can use very
frequently is git status. That basically just tells you
what's currently happening in my Git repository, what's going on. And it lets me, then,
figure out what to do next. So if I type, inside my repository,
git status, what I'll see is that I'm on branch master, and we'll
see in a moment what the branch means. And it says but the upstream is gone. Try this for a moment. OK. I haven't quite configured
everything just yet. But I just did git status
to check what was going on. And then the command that
I just typed was git push. So I typed git push and you saw
a whole bunch of things happen. So what exactly is git
push and what does it do? Well, when I added the hello.html
file, it wasn't yet on GitHub servers just yet. It was only on my own computer locally. And what git push does is it
says, when I type git push, it says take whatever
changes that I've made and go ahead and push
them up to the server. I want to take those changes
and push them up to GitHub so that anyone who goes online onto
GitHub and looks at my repository can actually see the
changes that I've made, can see those commits that I've made. And in fact, now, if I go
to my GitHub repository, that right now is just empty, and I
refresh this page, what I'll see now is there's a file here. There is hello.html. And if I click on hello.html, I'll see,
OK, here is the file that I've created. It's the same as the one that
was locally on my computer, but I added it to my
Git repository, and then I pushed it up to GitHub so that
it now has the latest versions. And anytime I make a change,
I can do something like this. So for instance, I can go back here. And maybe instead of just Hello World, I
want to put Hello World inside of an H1 tag to make it big and bold. So Hello World, get rid of that. Question? Yeah. AUDIENCE: [INAUDIBLE]
when you use [INAUDIBLE] BRIAN YU: Oh, good question. So what's the difference between
git push and git push origin master? git push, normally, will just default
to doing what git push origin master is. It has to do with pushing
to different branches, and we'll talk about
branches in a moment. All right, so I took Hello World
and I put it inside of the H1 tag. And now, this is some change
that I would like to commit. I'd like to save this is a
new version of the repository. And so I can say, all
right, git add hello.html. This is the file I want to
include in my next commit. git commit dash m, and I'll
say, OK, put text in an H1 tag. And OK. And it's telling me
that I need to add my-- I'll just go ahead and do
my name and email address so that it stops telling me to do that. OK, sorry about that. OK, so I committed those changes, and
let me fix the identity to commit. And now, if I type git status, it
says that I'm on branch master. And it says my branch is the head
of origin master by one commit. OK, it's a little bit confusing,
but what does that mean? It means that my branch
of the repository, the version that I have on my computer,
is ahead of the origin version-- the origin one is the one
that's up on GitHub servers-- by one comment, meaning I have made
one change that my server on GitHub doesn't yet know about. And so if I want to publish those
commits, push them up to GitHub, I can type git push. Before I do that, notice that hello.html
just has Hello, not in an H1 tag. But as soon as I type git push to say
take my changes, push them up to GitHub so that GitHub has the latest version of
my code, I push that, refresh the page, and, OK, now Hello World
is inside those H1 tags. This is the latest
version of the repository. But what you'll see on GitHub is if
I go to the GitHub repository page, I can see that I've made two commits. And if I click on OK, two commits that
I've made here, I can actually see, OK, here was the original
add a hello file. And I can see, OK, here is the
original file that I created, the one without the H1 tag. And then I can say, OK, when
I put text inside the H1 tag-- let's look at that commit. And OK, here was the change that I made. I took the Hello World line and
I added the H1 tags around it. So GitHub and Git, more generally,
is tracking all of these changes that I make. It knows when I make the changes,
whenever I make a new commit, and it's saving all of those different
commits in the commit history of this particular repository. Questions? Yeah? AUDIENCE: So does Git actually
save a list of the changes that you make so that it's able
to recreate the file [INAUDIBLE] or is your entire Git
history a massive collection of files that you [INAUDIBLE] BRIAN YU: Good question. So the question is, what
is Git actually storing? Simply put, Git is storing
a different version of the file for each type, time, you
create a new version of that file, although there are
ways to compress that. And Git does some compression behind
the scenes to try and save space. But you can generally think of it as
storing a separate version of the file every time you make a change. Yeah? AUDIENCE: Can you make
multiple [INAUDIBLE] BRIAN YU: Yes. If you make two commits
and then you type Git push, that will push both of
those commits up to GitHub. Other things? Other questions? OK, so let's explore a little more. And actually, before we go ahead, can
I just get a little bit of feedback with the smiley faces about,
how much are we following this? How much does it makes sense,
are we feeling about it? OK, it's a mix of mostly
green, some yellow. I'll take some questions. Yeah? AUDIENCE: If you make multiple
[INAUDIBLE] same file, will it show-- [INAUDIBLE] let's say
[INAUDIBLE] data set [INAUDIBLE] added something else to that
file, or would [INAUDIBLE] absolutely [INAUDIBLE] committed [INAUDIBLE]
specifically [INAUDIBLE] BRIAN YU: The default will be
the most recent on GitHub, yes. Yeah? AUDIENCE: Why would you commit
something and not push it? BRIAN YU: Why would you commit
something and not push it? Good question. Pushing it is only relevant
if you care about other people online being able to
access that same version. And so there are many times
when I'm working on a project independently, for instance, and I
might care about committing things for myself, but I don't
really care about other people on the internet being able
to access the repository. And so then you might
commit, but not really care about pushing because you
don't care about other people on the internet being able
to access the repository. Yeah? AUDIENCE: Why did you
add it again [INAUDIBLE] BRIAN YU: So git add-- so the question is, why did
I add before I committed? It's sort of a two-step
process that Git uses. First, you add files
and put them in what's called the staging area, which is to
say you tell Git that this is a file you want to include in your next commit. And then you actually do the commit. The reasoning here might be
maybe you've made modifications to a bunch of different files, but
you don't want to commit all of them at the same time. Maybe you are only done with two or
three of them and are ready to commit, but the others, you're not ready yet. So you can only add the files
you actually want to commit, and then you say, OK, commit to
say commit all of these files. So there's always this
additional add step. Now, there's shorthand
workarounds to this. If you type, instead of a git commit
dash m, you do git commit dash am-- the "a" for add-- that will automatically add
all of the changed files and commit at the same time
so you can combine the add and commit steps together. But there is still that add
step that needs to happen. AUDIENCE: If you already added the
file, [INAUDIBLE] added and then you BRIAN YU: Yeah, good question. So the idea here is even if I've
added it and it's in the repository, if I make changes to the file, I need to
tell Git that those changes to the file are ones that I want to
include in the next commit. So I still need to add it again. Yeah? AUDIENCE: So how do you access
the Git history if you're just working with a [INAUDIBLE] BRIAN YU: Great question. We'll get to that in a moment. Yes? AUDIENCE: Do you have
to download [INAUDIBLE] BRIAN YU: Do you have to download Git-- AUDIENCE: The GitHub [INAUDIBLE] BRIAN YU: Yes. So the question is, how
do you actually use Git? You'll need to install
Git, most likely, first. If you go to either Git
or GitHub's website, there'll be instructions
for how to install it. It varies a little bit, depending
on which platform you're using, but you'll likely need
to install it first. For Macs, it comes with
the Xcode developer tools, which it may ask you to
download, but there are other ways to get access to it as well. Other things? OK. The opposite of git push, as
you might imagine, is git pull. So the idea here is that before,
we talked about situations where what's on my computer is
more recent than whatever is up on the server. Sometimes it's going to
be the other way around. Whatever is up on the server is
going to be more recent than whatever I have on my computer. And I want to take the
changes from up on the server and download them down to my
computer so that I can then use them and have access to them. To do that, I just run
the command git pull. That takes the changes
from up on the server, downloads them onto my computer,
such that I now have access to them. And so I'll show you an
example of that as well. GitHub's user interface actually lets
me make modifications to the code. So I can go into hello.html
and actually edit it. So I'll go to hello.html,
I'll edit it, and I will say-- let me go ahead and add a comma between
Hello and World, just a simple change. And I'm going to say, OK, add a comma. That's my commit message. And I'm going to commit those changes. So I've committed those changes
just by GitHub's web user interface, which you can do. Just edit a file and
make a commit online. OK, so that's what I've done now. But on my version of the repository
here, if I look at hello.html, it's still Hello World, no comma,
because the version on GitHub is more recent than the
version on my computer. And I would like to
pull down those changes so that my version on my
computer is up-to-date. So to do that, I just type git pull,
press Return, and here's what it says. All right, it's updated my repository. And it says "one file changed,
one insertion, one deletion." Git is not quite smart enough to know
that I've taken one line and edited it. So if I take one line and edit it,
it sees that as removing the line and adding in the new line. So that's what one insertion,
one deletion means. And now, if I check the file,
you'll notice that there's actually a comma between Hello and World. I've pulled down the
latest version of the file and now the file on my
computer has updated in order to reflect those changes. Questions about that? OK. So we can git push to push our changes
from our computer up to the server. We can git pull to take
changes from the server and pull them down onto
our local computer. What can go wrong here? What are some problems you
imagine might start to come up? Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: People trying to push
different versions up to GitHub. All right, great. So what might go wrong if
multiple people are trying to make changes to the same repository? What can happen? Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: Yeah. So imagine a situation where
multiple people are making changes to the same line and now Git is not
going to be able to resolve for itself how to deal with that. Which version should it actually
be if person A has made this change and person B has made that change? Git is normally pretty
smart about things. If I'm adding something
to the beginning of a file and someone else is adding
something to the end of the file, Git is usually pretty
smart about just being able to merge those changes together. But sometimes you'll
run into situations, when people are working on the same
file, where we can't quite resolve it. And this brings up what
we call merge conflicts, when we try to merge
two people's changes and we can't resolve those differences. And that generates what
we call a merge conflict. And so that might happen
if I git pull some changes. I pull some changes down from GitHub,
but the changes I'm pulling conflict with whatever I have on my repository. There is some conflict there. And so rather than being
able to actually merge, it's going to say conflict. There was a merge conflict in some file. The automatic merge failed. I need to fix the conflicts
and then commit the results. All right, there's some problem. We need to fix them. You open up the file and you'll
see something really cryptic that looks something like this. This can be strange
and confusing at first. I'll try and help you decipher what
it is that this actually means. What you'll see is between the left
arrow symbols and the equal signs, these are your changes, the changes
that you've made on your repository. And the changes between the equal
signs and the greater than signs, these are the remote changes,
the changes that you're trying to merge in to
whatever it is that you have. And this long sequence of
numbers and letters, this is what we call a commit hash. Every time you make a
commit, Git gives it a commit hash, which is just a long
sequence of numbers and letters to uniquely identify that commit. This is just telling you
which commit is actually the one that's creating the conflict. And so what do you do when
you see something like this? The first thing you can do is
remove those marker symbols. And then you need to decide what it is
that the file should look like, maybe remove any excess whitespace. And when the file looks the way you
want it to look, you commit the results. Basically, you need to
manually go in and tell Git how it is that you want to
resolve these different conflicts. Some modern text editor come
built in with some automated ways of trying to help you do that. But in short, you have to do
something like this every time. So let's give that a try. I am going to go to Hello World and
maybe add some exclamation points. We'll add two exclamation points. And I'll do git commit dash am to
combine the add and the merge step. And say, add two exclamation points. All right. OK. And then up on this GitHub
repository, I'm going to edit it. And let's, I don't know,
add five exclamation points. So I've made a change
on my local computer. I've made a change on GitHub. And importantly, these changes conflict. They are changes to
the same line of code and Git is not going to know, when
it tries to take these two changes and merge them together,
which one should it listen to. So I go back here. And now, if I tried
to git pull, I'm going to get, OK, trying to
automerge hello.html, conflict. Merge conflict and HTML,
automatic merge failed. Fix the conflicts and
then commit the results. So let's take a look at it. Here's hello.html, and VS code
is doing some fancy highlighting to try and make it clear to
me what exactly is going on. But basically, between the left
arrow symbols and the equal sign, this is my version, the one with
just three exclamation points here. Then beneath it is the
version that I'm trying to pull in, the one with
even more exclamation points. Here is the commit hash of the
one that's causing the conflict. And I basically need to manually resolve
this conflict in order to figure out what should actually happen next. And so in order to do that,
well, I can go ahead and say-- and the VS code actually
gives me some buttons, like either accept my current
change, accept the incoming, or sort of compare them in order
to figure out how to resolve it. I'm just going to resolve it manually
for now by deleting this line, deleting that line, deleting that line. So here are the two versions. And I sort of just need to decide, how
am I going to resolve these together? And maybe I'll say, you know what? I'll just use all of
the exclamation points. Let's put them all
together and save that. This is the version
that I now want to keep. I'll do git commit dash am. I'll say, fix merge conflict. And OK. Great. Now, if I type git push, say, OK,
push those changes back up to GitHub, those are changes that I want to save. I refresh the page, and all right. Now I've been able to
fix the merge conflict and I have the long sequence of
exclamation points that I want. So I've been able to resolve the changes
that were conflicting between the two. Doesn't always come up when
you're working with Git, but comes up often enough that it's
good to know what a merge conflict is and how you can actually deal with it. What questions do you have about that? Merge conflicts, pushing, pulling. Yeah? AUDIENCE: What would happen
if, say, you were working on the top part of the
component and someone else was working at the bottom part. [INAUDIBLE] variable name,
but you didn't realize it, would that [INAUDIBLE] merge
[INAUDIBLE] or would it not? BRIAN YU: Good question. So the question is, all right,
we're working on the same VS code. I make some changes to the top
of the code, and that's fine. My partner makes some changes
to the bottom of the code. But we're using the same variable. Maybe we're using the same
variable in different ways and don't realize what
the other person is doing. Is Git going to catch
that merge conflict? It's not. Git is not smart enough to know
anything about the logic of the program. It's just looking at lines of code
and figuring out how they work. And so it's still something
you need to be careful about. You still need to be careful. Just because you don't
have a merge complex doesn't mean that things are going
to go together perfectly the way that you want them to. So something to be aware of. Good point. Yeah? AUDIENCE: Sorry, but I have not been
able to make it work on [INAUDIBLE] BRIAN YU: OK. When we get to project time, come
find one of the teaching fellows and we can help you try and solve that. Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: Good question. How do you delete a
file from a repository? On your normal command
line, rm is the command to delete a file. rm for remove, so
you do rm space name of the file. If you do git rm, followed
by the name of the file, that's going to remove the file from
the next time you make a commit. So the next time you make
a commit, you'll save that. But because Git does store the
history of all the commits, if you wanted to go back and get
that file removed, you still could. Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: So the question is, how do you
save changes to specific files rather than all the files you've changed? You do that via the git add step. So when you type git add,
you specify which files you want to save in your next commit. And so if you've edited 10
files, but only half of them are ones you want to
commit, only add those half. And then when you
commit, you're only going to commit the ones that you've
added to the so-called staging area. Great questions. Other things? We'll get an opportunity
to practice, too. Yeah? AUDIENCE: If you're adding
everything-- if you're adding [INAUDIBLE] in the directory,
[INAUDIBLE] add all of the files, even if you haven't made any changes
to them, will it still push all of them up as well, like the
ones that aren't changed? Or are they just kept the
same in the previous commit? BRIAN YU: Yeah, they are. Yeah. So git add dot-- dot stands
for current directory. That's basically a way of saying,
add everything that may have changed. All right, great questions. A couple other commands
that we'll look at briefly. One is git log. git log is a command that basically
just shows you a history of the commits that you've made. It's a way of seeing all your
commits on the command line. So I type something like git log,
and it basically just [INAUDIBLE] here is a commit that I made, and here's
when I made it and what I changed, and here's another
commit and what happened. And so if I type and git
log, I see, all right. Here's when I fixed the
merge conflict at 14:33. Added five exclamation points,
added two exclamation points. They're in reverse
chronological order, but I can see this whole history of
all the comments that I've made and what they're commit hashes were. OK. git reset is probably the
last command that we'll look at before we talk about branching. This is a way of going back to
a previous version of a commit. And so if you type git
reset dash dash hard-- so there's differences between
soft resets and hard resets, that we won't quite go into
today, you can experiment with. Followed by a commit hash, that
will basically take you back to a previous version of the file. So git reset dash dash hard,
followed by a commit hash, takes you back to this
particular comment that will eliminate all those
changes and take you back. And you can also go back to
a particular branch as well. And when we start to
talk about branching, you'll see this a little
more clearly, too. So let's talk about making
changes to a repository, and what exactly happens as you go about
the process of working on a repository, working on a larger project, and
what making changes looks like. So you make your first commit, and
maybe now you're adding features to it. You're making changes to it. You're making some more changes to it. You start working on a new feature. You keep working on that new feature. What happens, then, if you
discover a bug in your program? You want to go and fix that bug. But you want to fix that bug,
but simultaneously, you're also working on this new feature,
and that's not quite ideal when you want to figure
out some strategy for being able to deal with this,
being able to work on two different parts of
a project simultaneously. And so that's what
branching is, this idea you'll hear about a lot when
we start to talk about Git, and something that's built
into the core of what Git is. It's designed to allow you to branch
very easily, where the idea here is you've made your first commit. You're making some
changes to that commit. You're making some more
changes to your project. And now you want to start
working on a new feature, but you've got this, what we might call,
the master version of your repository, some version of your code that works. And when you start
working on in near future, you don't want it to be on the
master branch, so to speak. You want to work on it separately,
such that when it's done, you can merge it back in
with the rest of the code. So rather than start working
on a new feature and just keep it on the same
branch, what you might do is you might branch off, start working
on a new feature on a different branch and keep working on that new
feature on a different branch. And now you might imagine,
OK, you discovered that way back in the original version
of the code, there's some bug. And so you can say, all right,
this was when I first branched off to start working on the new feature, but
the bug is in this version of the code. Let me just go ahead and fix the
bug on this version of the code. And now, what I've got going
on in two different branches, I've got this master branch, the
original version of the code, and then I have my feature branch,
which could be called whatever you want, just some name to describe the
feature that I'm currently working on. And I've got these two
independent versions of the code that I can switch back
and forth between. Git has a term called the HEAD of
the repository, capital HEAD, that just represents, where in
the repository am I now? And by default, HEAD is going
to be whatever master is. It's going to be pointing
to the master branch. But I could move my HEAD. I could move where I am in the
repository and say, you know what? I actually want to work on the
feature branch instead, for instance. And so we'll show you how you
can check out different branches, so to speak, in just a moment. So I'm keeping working
on this new feature. I fixed the. Bug and the feature is now done. I'm ready to bring it back
into the master branch. The last thing I can
do is say, all right, I want to take these two changes,
I want to merge them back together so that this new feature
is now on the master branch, but so is the bug fix. Everything comes together in that way. Yeah? AUDIENCE: Before, when
you moved around the HEAD, what's the significance of where
the HEAD is and what the HEAD is? BRIAN YU: The question is, what's the
significance of where the HEAD is? It represents whatever-- which
files I am currently working on. And so if I try and open
up a file to edit it, the version of the file
that I'm looking at is whatever version the
HEAD is pointing to. So we'll see that in just a moment, too. Other things? OK. So let's actually give this a try. The commands we're going
to be using are git branch to go to a different
branch, git checkout in order to check out some
new branch, and git merge to say merging some things together. So let's go ahead and
go into My Repository. And let's say git checkout. git checkout is my way of saying,
I want to go to some new branch. And I don't have any
other branches right now. In fact, if I type git branch right
now, it will show me the branches that I currently have. I just have the master branch. And a little star next
to master means this is the branch that I'm currently on. I'd like to branch off,
go create a new branch. And so I'm going to say
git checkout out dash b. So git checkout will normally just
take you to a different branch. If I want to check out
a brand new branch, I'll do you git checkout dash
b to create a new branch. I'm going to call this branch-- what am I going to do? I'll just call it Feature. I'm adding some new
feature to my web page. And so OK, switch to
a new branch feature. Great. If I type git branch right now, I
see that now I have two branches. I have a feature branch
and I have a master branch. The feature one is
the one with the star. That's the branch that I'm currently on. And the master branch is the other
branch that I have available to me. Here's hello.html, and I want
to add some sort of feature. Maybe the feature that I'm going to
add is some styling to this web page. So I'm going to go up
here, add a style header, and say, all right, H1 is going to
have a color and it's going to be blue. Fairly straightforward, I
just added some styling to it. I can test it, open up, code in
HTML, make sure it looks blue. Great. So I've added that. Now, I'd like to commit those changes. So I"m going to say git
commit dash am add styling. That's the change that
I made, and I want to save those changes
in this repository. So I'm on git branch
on the feature branch, and I have this styling, that
I'm coloring the H1 tag blue. But this is only a change that
I've made to the feature branch. If I go ahead and type git checkout
master, meaning switch branches, go to the master branch instead. Press Return. All right, I've switched
to branch master. And now, if I look at the
code, no more style code. The version, I've switched my
HEAD to be on the master branch. I'm now looking at the
code on my master branch and the master branch
doesn't have the styling yet. Only the feature branch does. If I say git checkout feature,
switch back to the feature branch, now my code has the style code there. You switch back and
forth between branches, you can get different
versions of the code. I switch back to master,
git checkout master. Now, no more styling code. So now, what I'd like to do is say,
OK, I'm happy with the feature. It works. I've opened up the page. It looks blue. I've tested this feature thoroughly. I'd like to merge it in. I'd like to merge it
into the master branch so that my master branch has
the latest version of this code. How do I do that? Well, what I can do is I can just
say git merge and then the branch that I want to merge in. So I want to merge in the feature branch
into this current branch, my master branch. So I say, git merge feature. And it says, "one file changed, five
insertions," which sounds about right for the style tag plus the style code. And now I'm looking at my master
branch and the style code is now there. So the story of what we
did there is we created a brand new branch, the feature branch,
added some code there, made a commit, then went back to the
master branch and merged that commit into the master branch. And this is a way of
version control, of being able to work on something
without messing up the original until you're satisfied with
the original, at which point you can merge in those changes. Yeah? AUDIENCE: [INAUDIBLE] BRIAN YU: Can you still get conflicts? Absolutely. If I, in my feature branch, made some
changes, and I, in my master branch, made other changes to the same
places and tried to merge them in, you can definitely get
conflicts there as well. You resolve those the same way. Yeah? AUDIENCE: Does your branch
still exist [INAUDIBLE] BRIAN YU: Good question. Does the feature branch still exist? Yeah, it does. I type git branch. The feature branch is still there. I can switch to it. If I don't want it
anymore, I can delete it. I think it's git branch dash capital
D for delete, followed by feature. And then just hard deletes the branch. So now, if I type git branch, just
back to only the master branch. Other questions about anything so far? OK. One last thing I'll show you
is the idea of a pull request, which is a GitHub-based feature for
when you're trying to merge in changes. This is especially useful
if you're collaborating with each other, multiple
people making changes. And you want to make
sure that whatever is being merged in has been reviewed, that
you have an opportunity to look at it and approve it before it actually
gets merged into the master branch. So I'm going to go ahead and push
these changes, push them up to GitHub. And what I'm also going to
do is let's say, all right, here's the master branch. Here's hello.html. It's blue right now. Let's say I want to make a change,
and the change I would like to make is I'd like to make the
heading red instead of blue. So to do that, I could just
make the change and commit it. But to show you branching, I'll
actually create a branch first. So git checkout dash
b, create a new branch. I'll call the branch Red, let's say,
because I want to change it to red. I'm on a new branch called Red. I'm going to go to the style heading,
change the color from blue to red. git commit dash am,
save all these changes, add all the new files that I've
changed, change color to red. That's my commit message. Press Return. All right, I've made that change. Now, if I type git push, you'll see
that I don't quite get this to work. It says, "The current branch
red has no upstream branch." What does that mean? Well, it means that I'm
trying to push the red branch, but on GitHub, GitHub doesn't
know that there's a red branch. GitHub only knows that
there's a master branch. So what I need to do is
tell GitHub the origin-- GitHub is my origin repository--
to push my red branch up to a new branch called
Red on the origin. And so to do that, you'll
just run this command, git push set upstream origin red, to
mean push upstream to GitHub, push to a new branch called Red. So I went ahead and did that,
push to that new branch. And so now if I check GitHub,
refresh this page, it's still blue. And that's because I'm on
the master branch right now. See, on the left side, I see
here I have branch master. But if I click on branch master, I'll
see a list of all of my branches. And here, I have master and I have red. If I switch to the red
branch, now I'll see, OK. Here's the fact that I have color red. So I've got both of
these branches that are coexisting on GitHub simultaneously. And what I'd like to do is I'd like
to use GitHub's interface to say, I would like to propose this as a
change to make to the master branch. And so this is what a
pull request is, it's a request to pull in some
code from a different branch. And so I'll go to pull requests,
and it's actually suggesting now that I actually make a new pull
request from the red branch-- and notice that I've
just pushed this branch. So I'll go ahead and
compare and pull request. It's going to ask me to title my pull
request, propose the name of the change that I'm making, and leave a comment. So I thought the red looked
better, whatever you want to say. You can create the pull request. And OK, now anyone who has
access to this repository can see this pull request. You can go online and see
it now if you want to. You can see the comment
about the proposed change. If I go to the Files
Changed, you can see here's the change that I'm proposing to make. I'm proposing to change
the color from blue to red. And you can see that
what I want to do is I want to merge one commit
into master from red. That's what my pull request is doing. I'm trying to take one commit
that's on the red branch and merge it into the master branch. And so this is something you
commonly see in industry, where they don't just let anyone
just make a change automatically to the code base, where they'll want you
to make changes on a different branch and then submit a pull request, like
propose these changes so that someone else can code, review it, leave
comments and feedback on the changes that you've made. And then only when everyone
feels confident and comfortable with the changes that you've made
do they go down here and click this green Merge Pull
Request button that says, all right, I'm happy with these changes. Let's take the changes
from the red branch, bring them into the master branch. And when I click Confirm Merge,
now on the master branch, it's going to be updated
with that new red styling. It's now giving me the option
to delete the red branch, which I can do now because I no
longer need the red branch. But that's the idea of a pull request. Questions about all of that? I know that's a lot. Yeah? AUDIENCE: Yeah, so if you branch it
off and you change the color to red, then someone else adds a bunch
of extra features to the master, merging the red to the master is
not going to lose those features. And likewise, if you wanted to
merge the master to the red, would that keep the changes that
you made in the red as well? BRIAN YU: Good question. So the question is, I
changed the color to red, but before I'm able to
merge it in, someone's added new features to the master branch. What happens when I merge red in? It's going to keep all
those same features. So everything just gets merged together. The only trouble comes if, when
someone was adding new features, they also decided to
change the color to green, and now they conflict and then you
have to deal with that merge conflict. But other than that,
everything is preserved. Yeah? AUDIENCE: Are there ways,
in GitHub, to regulate who can actually improve [INAUDIBLE]
project leader, or [INAUDIBLE] BRIAN YU: Good question. Is there a way in GitHub to
have some approval mechanisms so that only certain people
can improve pull requests? Absolutely. In the settings, you
can go to collaborators and you can add configuration
there for security to make sure. You can even add certain
branch protections to make sure that nobody
can push to master without going through a
pull request first, even if they can push the other branches. There are a lot of
features there as well. Yeah? AUDIENCE: Conceptually, even
though it's called a pull request, is it more like a merge request? BRIAN YU: Yeah. You can think of it as that. It's called a pull
request insofar as you're trying to request to have some code
pulled into a particular branch, but depending on how you think of
it, however makes best sense to you. But you're trying to merge code
together, one branch into another, generally. All right. You'll have an opportunity to play
around with pull requests in GitHub a little more in the afternoon
project, but just wanted to introduce that to
you as a useful tool that you can use over the course
of this week and future classes that you take in your own work,
in industry, so on and so forth. Other questions about Git before we
turn to one final topic for today? OK. So last topic we're going
to talk about is SaaS. And so SaaS is an
extension to CSS that is going to add some new features to CSS. So you might imagine
that CSS code can quickly start to get a little bit repetitive,
where you might imagine that if you've got a themed website, where your
website follows a standard color scheme, for instance. You might have a particular
color that you're using again and again and again throughout
the entirety of your CSS page, for instance, whereby
if you later then wanted to go back and change
the color of the page, you might run into some
issues, whereby you'd have to go back and change the
color in every single place where that color shows up. And that starts to get
a little bit annoying. In code, how do we solve this problem? If we've got some piece
of code that we're reusing a lot, some value
that we're using a lot, and we want to avoid using
it over and over and over, how would we solve this problem
in a language like C or Python? AUDIENCE: Define a variable. BRIAN YU: Define a variable, exactly. We define a variable, set the
variable equal to the value, and then we can reuse
that variable whenever we want to represent that value. CSS, by default, doesn't
give us that ability, but it is an ability that we get
with something called SaaS, which we'll see in just a moment, among other
features that it adds on top of CSS. And so let's take a look at what
that would actually look like. So I'll give an example here. We'll go in and go to the desktop
and just create a new file, which I'm going to call variables.css. And you might imagine here that
if I want to color unordered lists and ordered lists the same way,
I might say, OK, unordered lists, I want to have a color of red
and a font size of 14 pixels. And ordered lists, I want
to have a color of red also. And ordered lists, I want them to
be bigger, font size 18 pixels. Let me now create a new file. I'll call it variables.html,
doc type, HTML. I've created a separate CSS file,
which we haven't yet seen today, but it works the same as
putting things in the style tag. The only change is-- we'll call this my web page. Rather than putting a style tag, here
I'm just going to link the CSS file. I'm going to say the relationship
of this file is a style sheet and the source for the
file is that variables.css. So basically, I'm saying take the
CSS code located in variables.css and include it as styling for
this particular HTML page. This can be a useful tool if
you want to use the same CSS file for multiple pages. You don't need to duplicate the CSS. You just have all the files reference
the same CSS file, for instance. And inside the body of this page now,
I might have an unordered list, so UL. We have a bunch of list items,
so item 1 and item 2 and item 3. And maybe in addition to that, I
also have an ordered list, an OL. So I have a UL, an unordered
list, and an OL, an ordered list, that also has items on it. And I have them both. Whereby now, if I open
up variables.html, I see that I have a small unordered list
and a large ordered list, both of which are red. And that's to be expected,
because in variables.css, I said, unordered lists should be
a size 14 point font, color red, and ordered lists should be a size
18 point font and also colored red. But the duplication here
is in the color red. If I wanted to change the color to
blue, or green, or something else, I would have to actually go to
both of the places in the code and change both of the occurrences
of red to blue, or green, or something else. Now, might not seem like a
big deal for a simple example, but you imagine starting
to work on larger projects where things start to
get more complicated, and this can start to get
messy or annoying to replace all of these changes
constantly, more room for error if you happen to miss
one and then things start to look a little bit strange. So how can we solve this problem? That's what SaaS is designed to do. So I'm going to create a new
file, call it variables.scss. It's the file extension for SaaS files. And this is going to
be very similar to CSS, but we're going to extend it with
the capability of defining variables. So I'm going to define a variable
called dollar sign color-- and dollar sign is just the way in
SaaS that you define a variable-- colon red. Color could've been anything,
but the dollar sign just says, here's a new name for a variable. The variable is called color
and it's going to be set to red. And now, I can say, all
right, unordered lists. I should have a font size of 14 point. But the color, rather
than just saying red here, I'm instead going to
say dollar sign color. That's the name of the variable
that I would like to use right here. Just plug in the value of
that variable here as well. Then I can also add an ordered list and
say, all right, the font size for that should be 18 point font,
and the color there is also just going to be whatever
the value of the color variable is. I'm using some variable there,
putting it inside of my SCSS file. Questions about what I'm doing
so far, or why I'm doing it? OK, so what we might like to be
able to do is go into our HTML file and say, all right, instead
of using variables.css, let's use variables.scss, and
then go ahead and load this page. But when I do that, I
lost all the styling. Sizes are the same, nothing is red. Why is that? Any guesses? AUDIENCE: [INAUDIBLE] BRIAN YU: I didn't link it. But I did link it. I linked to the SCSS file. The problem here is that
web browsers don't natively understand SaaS or SCSS files. They only understand CSS as a language. And this, although it looks a
lot like CSS, is not quite CSS. It's using variables
that CSS doesn't support. And so this is a bit of a problem. So what you need to
do is this extra step of converting our SCSS file,
our SaaS file, into a CSS file. And so that's the extra
step that you'll need to do. You'll have to install SaaS,
and there's instructions for how to do this on the SaaS website. But when you do, then you
can say something like, all right, SaaS, variables.scss,
and then variables.css. What I'm saying here is
take variables.scss and just convert it into plain old CSS
and generate a file called variables.css via the SaaS program. So I press Return. Nothing seems to happen. But if I look at variables.css
now, looks a little bit different. But the general thinking
is the same thing. I've generated the CSS file, whereby
it's plugged in the color red into both unordered
lists and ordered lists. And if I go into the SCSS
file now and change it, go from red to blue,
and then I rerun SaaS, say recompile the dot SCSS
file into a dot CSS file. Then when I go back to variables.css,
OK, both colors are now blue. It keeps generating the new
CSS file based on whatever it is that I've included in the SaaS file. It's making that conversion for me. And then in variables.html, rather
than including the SCSS file, I'm just going to include the CSS file,
the translated version of that file, such that I can refresh, and
OK, now everything is blue. Now, if I'm currently
working on development, it's probably a little bit
annoying to have to constantly be, every time I make
a change to the SaaS file, recompile it to the CSS file. So SaaS has some features
to help with this. I can say SaaS dash dash watch
to say, keep watching this file. And anytime I make a change to the file,
just automatically due to conversion into the CSS file. So I'll say SaaS dash dash watch
variables.scss colon variables.css. The colon separates original
file, resulting file. It's just the way the
command line program works. I press Return. And now it says SaaS is
watching for changes. Now if I go to variables.css, and
instead of blue, say, all right, let's take the color green. Save that. And go to variables.css,
all right, the color's green it's automatically
updated the CSS files for me based on whatever it is that
I have in the SCSS file. Questions about that, what I've
done, what the idea there was? OK. So this adds some ability
for you in your SaaS files to be a little
bit clever about CSS, to be a little bit better
designed in the way that you structure your style
sheets, in the way that you go about thinking about
what goes where, and how to think about avoiding reusing
the same thing multiple times to make it easier to change
things later on down the line. So now, let's begin to look at
some of the other features that were afforded in SaaS, one of
which is the idea of nesting. And so let me show you an example. I'll go to Source. I'll go into nesting.html. So notice here, I've got an HTML page. I have a div, a big div,
inside of which is a paragraph. And inside of the div is also
an unordered list, a UL element. Then I have a paragraph
that's outside of the div and I also have an unordered
list that's outside of the div, so some hierarchical
structures here that are elements within other elements. But maybe I only want to style
the paragraph and the lists that are inside of the div. And so you might end up with code
that looks something like this. So SaaS supports the idea
of nesting CSS selectors within each other, where the idea
can be, all right, I'm going to style the div. The div is going to have a
font size of 18 point font. And then if, inside the div,
you have a paragraph, a p tag, that can be colored blue. And if, inside the div,
there is an unordered list, that's going to have a color of green. So you can add the nesting
of elements within elements. That can often be helpful if you're
thinking about larger, more complex CSS style sheets. And in fact, earlier this
morning, I was working with some of you who are
starting to come up with things that were a little more complicated. You had a lot of things
nested within each other. It's just a lot simpler to think about
when you can nest CSS selectors within each other, to say, only style
paragraphs and unordered lists that are inside of the div in particular ways,
whereby if I open up nesting.html-- HTML. OK, I haven't compiled the SaaS file
into CSS yet, so saasnesting.scss, nesting.css. And all right, great. So now, the list items inside the div
and the paragraph inside the div, those get styled, but the
paragraph outside the div and the list outside
the div, those don't get styled, because I
was able to generate from nesting.scss the nesting.css
file, which looks something a little like this. It's generating
equivalent CSS code that's taking advantage of
the descendant selector that we were talking about
earlier this morning. Questions about that? OK. I'll show you one other
SaaS example, just to give you a sense for the
type of thing that you can do. Oftentimes, you might have a
whole bunch of different things that are very similarly styled,
except for a couple of differences. So an example of that might be-- go to inheritance and
open inheritance.html. This is the type of
thing I want to create, where I have similar to
bootstrap alert messages. I have a success message, a warning
message, and an error message. And these are admittedly different. The success messages is green. The warning is yellow, or orange,
and the error message is red. And they are all different colors. But there's also things
about them that are the same. They are similarly spaced. They have a border
around the edge of them. They're a similar font,
and the same font, in fact. So everything about them is
the same, except for the color. And so I'd like some way of
avoiding repeating myself when I'm writing this code. And so here's the code I might use. I'll use inheritance.scss. And what I have up here is
I'm defining the styling for something called a message. And a message that I'm
defining with this percent sign, which is going to
allow me to extend it later, is going to be sans serif. It has a particular font size. It's going to be bolded. It has a border. It has certain spacing, 20
pixels around the edge of it and 20 pixels inside of it. And then anything with
a class of success, I'm going to say is going
to extend the message. It's going to inherit
all of the CSS properties that the original message had,
so all of these CSS properties get used inside of the success class. The only difference is that
the background color is green. And likewise, for my
warning message, I'm also going to extend the message
that has all of these CSS properties and values. And I'm just going to say,
all right, let's change the background color to be orange. And for the error message, I'm likewise
just going to extend that message and change the background color to red. When I generate the resulting
inheritance.css file, it's going to look like this. It looks like, all right, let's
give success, warning, and error all of these same properties in common. And let's make success have
a background color of green, and warning of a
background color of orange, and error of a background color of red. And certainly, you can
do this for yourself, but sometimes it's going to
be easier to reason about and easier to think
about by just giving it a name, saying these are all a message
and success extends that message and also has a background color,
for instance, to avoid needing to have success in too many places,
to avoid having to repeat yourself too many times. And so yet another thing
that SaaS can be useful for, just making it easier to design your
style sheets a little more effectively. Yeah? AUDIENCE: Does SaaS have the same
kind of variable name inheritance that CSS does with not-- so if you're using
bootstrap, or something, and they use success and warning
and [INAUDIBLE] general class names, if you create a SaaS
variable, would that override success and warning variables
if they have another SaaS file? BRIAN YU: Good question. So the question's about
conflicting class names. Like, what if you have
a class name declaration that bootstrap has and you
reuse that declaration in SaaS? This has actually very
little to do with SaaS itself because SaaS is just
generating CSS files. But it is an interesting
question of bootstrap defines what class success
means, maybe, and my code also defines what class success, how
class success, should be styled. How should those two things be resolved? And the answer is that if
the selectors are identical-- we talked a little bit earlier
about specificity, the idea that IDs bind more
tightly than class name. And so if something has an
ID, that will take precedence. But if the selectors are the same,
CSS tends to go with the last one, so whatever occurs last. And so we can demonstrate
this very quickly. I'll just open up-- I'll copy variables.html and call it
style.html and open up style.html. And I'm going to have
an H1 that says Hello. I can add some style here,
whereby each ones are colored red and each ones are colored blue. These are identical selectors so
they should bind equally tightly. But when both are in conflict, the
latter one is going to take precedence. It's going to be blue instead of red
because the color blue selector comes after the color red selector. Now, there are ways to override this. If you really want one of
them to take precedence, even if it is earlier in a file,
you can say color red exclamation point important. Like, this is an important
style, you should use this one. And if you do that, then Hello
is going to show up as red. But you should use that sparingly. Usually, there is almost
always a way to get by without needing to use being
important, where you can just add an ID or add some additional layer
of specificity, such that you can make sure it binds more tightly. But good question. All right, questions about SaaS,
or what it can be used for, or what the idea of it is? So we saw this idea of
variables of being able to, in SaaS, be able to
specify names of variables that you can reuse later when you're
trying to use some common CSS property value. I talked about nesting
things inside of each other to avoid having code that
looks something like this. You can have code that looks something
a little more like the right. It's a little bit easier
to reason about sometimes. So this afternoon, what I thought
we'd do is do a couple of things. I'll leave this up for a little
bit so you can take a look at it. First thing to do, install
SaaS on your computer. You're probably also going to want to
install Git, if you haven't already. And then the TAs can walk
around and help you with that. And add some SaaS to your HTML page. Add some variables. Add nesting, if you'd like to. Add some inheritance,
if you want to, as well. Then go to GitHub. Create a new repository. And take the HTML page
you've been working on today and push it up to GitHub. Push it up to the master branch. And just try and practice committing
changes and pushing them up to GitHub, since that's
probably new for many of you. And then here's an opportunity
to get to know each other. What we're going to ask you to do is
find a partner, someone to work with. Add each other as collaborators
to your GitHub repositories. If you go to Settings
and Collaborators, you can add the other person's GitHub
username as a collaborator there. And then what we'll have you do
is clone each other's repositories by doing git clone, followed by the URL. Make some changes on a new branch. Go to a new branch and
change the styling, change the wording of
something, for instance. And push those changes up
to GitHub on a new branch. And then practice
making the pull request. Make a pull request to the master branch
and add whoever owns the repository. Look at those changes. Maybe comment on them and then
approve that pull request. That'll sort of simulate
for us this idea of what very commonly happens in
practice and in industry all over, this idea of making changes,
pushing them to branches, merging them together. It would be good practice
with HTML, CSS, and SaaS, and also good practice with Git as well. So I think what we'll do is-- I know people are sitting in
slightly different places. But we'll change up the
groups a little bit. We'll have the people sitting
in the middle go to room 136. Have the people sitting on
this side, go to room 212. Actually, were you in 212 last time? This side, go to 212, and
this side will stay here. And we'll go ahead and work on that. Just so everyone knows, we
will all reconvene here. We'll keep working
until 5 o'clock, or so, and then tomorrow, we'll
meet again here at 10:00 AM.
