Placeholder Image

字幕表 動画を再生する

  • [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.

[MUSIC PLAYING]

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

GitとGitHub - CS50 Beyond 2019 (Git and GitHub - CS50 Beyond 2019)

  • 4 0
    林宜悉 に公開 2021 年 01 月 14 日
動画の中の単語