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