CS50 Video Player
    • 🧁
      • 🍩
      • 🍒
      • 🍿
    • 0:00:00Introduction
    • 0:00:15Git
    • 0:04:47GitHub
    • 0:14:48Commits
    • 0:27:00Merge Conflicts
    • 0:36:38Branching
    • 0:00:00[MUSIC PLAYING]
    • 0:00:17BRYAN YU: All right.
    • 0:00:18Welcome back, everyone, to Web Programming with Python and JavaScript.
    • 0:00:21So last time, we took a look at two languages, HTML and CSS, both of which
    • 0:00:26can be used to design web pages.
    • 0:00:28HTML, we used in order to describe the structure of web pages,
    • 0:00:31to decide what content we want in the layout of the page,
    • 0:00:34and then CSS, we used to describe the style
    • 0:00:36of the page, what color we wanted things, how much space we
    • 0:00:39wanted to run things as well.
    • 0:00:40Today, we're going to turn our attention to a tool
    • 0:00:42that we can use as we begin to develop these web applications,
    • 0:00:46and in particular, we're going to be looking at a tool called Git;
    • 0:00:49and what Git is is it is a version control tool, not specific to web
    • 0:00:53programs necessarily, but that we're going
    • 0:00:54to use as we begin to develop bigger and more sophisticated
    • 0:00:58web applications over the course of this term.
    • 0:01:01So what is Git going to enable us to do?
    • 0:01:03Well, it's going to do a couple of things.
    • 0:01:05First and foremost, what Git is; it is a command line tool
    • 0:01:08that's going to allow us to, first, keep track of changes that we make to code.
    • 0:01:12So once upon a time, and the first time I
    • 0:01:14was starting to develop web applications,
    • 0:01:16I remember working on a file, and then when I wanted to make changes,
    • 0:01:19I might have wanted to save the old version, so I would duplicate the file
    • 0:01:23and then just make changes to the duplicate, but this quickly gets messy.
    • 0:01:26Especially if you have lots of different versions
    • 0:01:28of your code in various different stages, keeping track of them
    • 0:01:31just starts to become a nightmare.
    • 0:01:32So what Git is going to enable us to do is to keep track of changes
    • 0:01:35that we make to our code.
    • 0:01:36So we might create a file initially, save that version of it, but over time,
    • 0:01:40as we make changes, add to it, remove things from it,
    • 0:01:43we can save snapshots, so to speak, of various different parts
    • 0:01:47of our code at different points in time, such
    • 0:01:49that we can quickly and easily reference all of those changes
    • 0:01:52that we've made to that code.
    • 0:01:54Additionally, Git is going to make it easy
    • 0:01:56for us to synchronize code between different people.
    • 0:01:59In larger scale web applications, it's rarely
    • 0:02:01just one person who's working on the entire application.
    • 0:02:04Usually, you're working with a co-worker or multiple co-workers,
    • 0:02:07all in the same application, and all at the same time.
    • 0:02:10And one definitely tricky part of this process
    • 0:02:12is figuring out how to synchronize your work between different people.
    • 0:02:16If I make a change on my part of the web application,
    • 0:02:18I want to make sure that my colleagues are also able to see those changes
    • 0:02:21and get access to the latest changes that I've made.
    • 0:02:24And then I want to be able to get access to the latest changes
    • 0:02:26that the people I'm working with have made too.
    • 0:02:28So we need some way to keep everything in sync and Git
    • 0:02:31is going to enable us to do that.
    • 0:02:33What we're going to effectively have is one version of the code stored
    • 0:02:36in we're going to call a repository somewhere online,
    • 0:02:39and both I and someone I'm working with-- a partner, for example--
    • 0:02:42might both be able to get access to that exact same repository,
    • 0:02:45the same files in the same state.
    • 0:02:48And if ever I and the other person make changes to those files,
    • 0:02:51we can each make changes to those files, and then synchronize them back up,
    • 0:02:55pushing them back up to the server, so to speak,
    • 0:02:58so that the server will have the most recent, most up-to-date version
    • 0:03:02of this code.
    • 0:03:03Then after that, after we've both pushed our changes up to the server,
    • 0:03:06then we can both pull changes from the server,
    • 0:03:09so to speak, in order to get access to the latest version of the code,
    • 0:03:12so that no matter what, so long as I've been working on the same project
    • 0:03:15that my partner has, we can use Git to synchronize our work,
    • 0:03:18so that I have access to my colleague's most recent changes, and vice versa.
    • 0:03:23Git also enables us to do a number of other things.
    • 0:03:25For example, Git allows us to test changes to our code
    • 0:03:29without removing access to the original.
    • 0:03:31So for example, you might imagine that as I'm working on writing a program,
    • 0:03:35I might want to try making some changes, but I'm not sure
    • 0:03:38if they're quite going to work.
    • 0:03:39So I want to test those changes, but I don't
    • 0:03:41want to lose access to my original working version of the program,
    • 0:03:44just in case something goes wrong.
    • 0:03:46So what Git enables us to do is it lets us make changes
    • 0:03:48to code on a separate branch, so to speak,
    • 0:03:51such that later, once we're happy and satisfied with the changes,
    • 0:03:54we can merge those changes back into the original version of our code,
    • 0:03:59being able to test those changes before we're really sure that they're the ones
    • 0:04:02that we want to make.
    • 0:04:03And finally, one powerful feature that Git gives us access to
    • 0:04:06is the ability to revert back to old versions of our code.
    • 0:04:09So you might imagine in the situation where I've been working on some code,
    • 0:04:12and I realize that actually, what I'm doing right now isn't what I want,
    • 0:04:16Git enables us to say, you know what?
    • 0:04:17This most recent change isn't something that I wanted.
    • 0:04:20I would like to revert back to a previous version of the code instead.
    • 0:04:24And Git makes it very easy to go back to those previous versions.
    • 0:04:28So the goal for today is going to be to learn how to use this tool,
    • 0:04:31to learn the various different and Git commands that
    • 0:04:33will be quite popular and quite common, as you
    • 0:04:36go about working on web applications or really
    • 0:04:38any other code-related project, because version control really
    • 0:04:41allows a number of useful features that are practical as you begin
    • 0:04:45to work on larger and larger projects.
    • 0:04:48But ultimately, as we begin working on these Git projects
    • 0:04:51they need to be stored somewhere online, such
    • 0:04:53that we're able to download them from anywhere,
    • 0:04:55such that me and a partner can both be working
    • 0:04:57on the same files and the same code, and so in order to do that,
    • 0:05:01we need to host our get code somewhere.
    • 0:05:03And there are a number of different websites that can do this,
    • 0:05:05but one of the most popular is a website known as GitHub.
    • 0:05:08GitHub is a website that stores Git repositories, where
    • 0:05:12all the repository is, is you can think of it
    • 0:05:14as a folder that holds a whole bunch of code and files related to our code.
    • 0:05:18So we're going to host this code online on a website called GitHub,
    • 0:05:22and then on our computer, we'll be able to access these GitHub repositories
    • 0:05:26and manipulate those repositories by changing
    • 0:05:28the files that are within them.
    • 0:05:30So let's go ahead and take a look at GitHub
    • 0:05:32and see how we can go ahead and create our very first GitHub repository.
    • 0:05:37If you don't already have a GitHub account,
    • 0:05:38you can create one by going to GitHub.com
    • 0:05:40and signing up for an account for free.
    • 0:05:42And I'll now go to GitHub.com/new.
    • 0:05:47GitHub.com/new is the page I go to if I want to create a new GitHub repository.
    • 0:05:53And so let's take a look at what I need to do in order to create a repository.
    • 0:05:57The first thing I need to do is give my repository a name.
    • 0:06:00So in this case, I'm just going to call the repository hello.
    • 0:06:03You can give it any name you want, so long as that name
    • 0:06:06doesn't collide with other repository names that you already have.
    • 0:06:09GitHub optionally lets me provide a description for this repository.
    • 0:06:13I'll just say, Web Programming with Python and JavaScript.
    • 0:06:17And then GitHub gives me the choice, do I want this to be a public repository,
    • 0:06:21such that anyone can see the repository?
    • 0:06:23Not everyone can necessarily make changes to it,
    • 0:06:25but it's publicly available if anyone wants to download my code
    • 0:06:28and try it out.
    • 0:06:29Public means that anyone can access it.
    • 0:06:31Or private, meaning, by default, only I can see this repository,
    • 0:06:35but I can choose if I would like other people to be able to see it as well,
    • 0:06:38and I can select which individuals.
    • 0:06:40For now, I'll go ahead and make this repository public,
    • 0:06:43and I'll go down here and click on the green Create Repository button
    • 0:06:46in order to make this new repository.
    • 0:06:49So I click the Create Repository button.
    • 0:06:51And here it is.
    • 0:06:52This is the GitHub's repository page, and right now, you'll
    • 0:06:55notice that there's a lot of instructions here,
    • 0:06:57but there are no files, because right now,
    • 0:06:59when I first created my first Git repository I got
    • 0:07:02an empty repository with nothing in it.
    • 0:07:05So what I'd like to do now is somehow download this repository
    • 0:07:08onto my own computer, such that I can add, say,
    • 0:07:11an HTML file that contains some HTML that I want to keep track of using Git.
    • 0:07:16So, how am I going to do that?
    • 0:07:18Well, in order to do that, we're going to take a look at the very first Git
    • 0:07:21command that's going to be involved with Git, which is known as git clone.
    • 0:07:25git clone is a command that we can run in order
    • 0:07:28to take a repository from the internet and download it onto our own computer.
    • 0:07:32So you'll need to have Git installed onto your computer.
    • 0:07:34You can install it on any Mac or PC or Linux machine, and once you do,
    • 0:07:38what you're going to do is, on your computer in the terminal,
    • 0:07:41you'll run it git clone, followed by the URL of the Git repository
    • 0:07:46that you're trying to download.
    • 0:07:47So you might imagine that here's your computer over here,
    • 0:07:50and up here is some server where a Git repository is located.
    • 0:07:53GitHub, for example, is one such server, but there are others as well.
    • 0:07:56And up there is the repository that potentially has files or maybe
    • 0:08:00other folders with other files that contain the contents of the repository
    • 0:08:04that you care about downloading.
    • 0:08:06So if I run git clone followed by the URL of the repository I want,
    • 0:08:09the effect of that is that the repository and all of its contents
    • 0:08:13get downloaded onto my computer, such that I on my computer
    • 0:08:17now have a copy of everything that was originally
    • 0:08:20inside of that Git repository.
    • 0:08:23So now that we know how to clone a repository, let's actually try it.
    • 0:08:26We've just created a repository using GitHub,
    • 0:08:29and now let me go into my terminal and actually tried
    • 0:08:31to clone this repository, so that I have a copy of it on my computer,
    • 0:08:36and I can begin to make some changes to it.
    • 0:08:39So I'll go into my terminal now, and I'll go into my lecture1 directory.
    • 0:08:43And the first thing that I'm going to need
    • 0:08:45is I'm going to need the URL of the repository.
    • 0:08:48So if I go back into GitHub, what you'll notice
    • 0:08:51is that it gives me an HTTPS link in order to download my Git repository.
    • 0:08:57So there are a couple of different ways that I can use to clone my repository,
    • 0:09:00of ways to authenticate myself.
    • 0:09:02One is using HTTPS, which will eventually
    • 0:09:04involve like a username and password that I'll
    • 0:09:06have to type in, in order to prove to Git
    • 0:09:08that these are my GitHub credentials.
    • 0:09:10Alternatively, if you're familiar with SSH,
    • 0:09:12this is another method of authentication.
    • 0:09:14You can give GitHub your public SSH key in order to authenticate as well,
    • 0:09:19but no need to worry about that if you're not
    • 0:09:21as familiar with that technology.
    • 0:09:23The key here is that this URL is the GitHub
    • 0:09:26URL that corresponds to my repository.
    • 0:09:28So I'm going to copy that URL, and then inside of my terminal,
    • 0:09:32I'll type git clone, and then I'll just paste in the URL
    • 0:09:37that I would like to clone that contains that repository.
    • 0:09:39I'll go ahead and press Return.
    • 0:09:41It says I'm cloning into a directory called hello, and then it's saying,
    • 0:09:44you appear to have cloned an empty repository.
    • 0:09:46It's saying that's a warning, but that's OK,
    • 0:09:48because I know that I've cloned an empty repository, because the repository is
    • 0:09:51brand-new.
    • 0:09:52And now I can type the command ls in my terminal.
    • 0:09:56The ls command in the terminal stands for list,
    • 0:09:59and effectively what it's going to do is list
    • 0:10:01all of the files that are currently inside of this directory,
    • 0:10:04all the files and folders that are inside
    • 0:10:06of my lecture1 directory, where directory is just
    • 0:10:09a fancy name for folder.
    • 0:10:10So I'll type ls, and I see that, all right,
    • 0:10:13I now have a folder called hello inside of my lecture1 directory, which
    • 0:10:17I didn't have before.
    • 0:10:19I'll go ahead and move into this hello directory.
    • 0:10:21In order to change into a directory or folder, you can use the cd command.
    • 0:10:25Cd stands for change directory.
    • 0:10:28And so if I type cd hello, I will now move myself into the hello directory.
    • 0:10:34And if I type ls, you'll see that there's
    • 0:10:36nothing inside of this hello directory right now, because again,
    • 0:10:40this repository was empty.
    • 0:10:41I cloned it, and there was nothing in it.
    • 0:10:44So now I'd like to actually put something in this repository.
    • 0:10:47The repository is only useful if I'm keeping track of my code
    • 0:10:50and keeping track of the changes that I make to that code.
    • 0:10:52So I'll go ahead and actually try now to add some code to the repository.
    • 0:10:57The first thing I'll do is create a new file.
    • 0:10:59And we could create a new file just by opening up a text editor,
    • 0:11:02but on the terminal, there's actually a command
    • 0:11:04for creating a new file called touch.
    • 0:11:06So in the terminal, I can type touch hello.html, and what that's going to do
    • 0:11:13is create a new file called hello.html.
    • 0:11:15And if I type ls, I can see that indeed I do have a file called hello.html.
    • 0:11:20Now inside of my hello directory, let me now
    • 0:11:23open up this directory in the hello.html file inside of a text editor.
    • 0:11:29Again, I'm using VS Code.
    • 0:11:31And let me now add just some text to hello.html.
    • 0:11:34I'll just add a simple HTML page, same thing we've seen before,
    • 0:11:38where I give it a header, a title will be hello,
    • 0:11:41and inside the body of the page will be "Hello, world!"
    • 0:11:45Same HTML page we've seen a number of times
    • 0:11:47now, just now inside of this repository.
    • 0:11:51Of course, I haven't yet made any saving to this repository.
    • 0:11:55I haven't said that I want to save these changes to the repository.
    • 0:11:58And the repository isn't keeping track of every single character I write.
    • 0:12:02I need to tell Git that this is a state of my current files
    • 0:12:06that I would like to keep track of, something that I would like to save.
    • 0:12:09And in the world of Git we call those save points commits.
    • 0:12:12When I say, I am making a commit, I mean I
    • 0:12:15would like to save the current state of all of the files
    • 0:12:17and folders and other assets that exist inside of the repository
    • 0:12:20and basically take a snapshot of their current position,
    • 0:12:23such that later I might be able to refer back to them.
    • 0:12:27But in order to do that, there are actually a couple of steps.
    • 0:12:30So the first step we need to follow is an additional command.
    • 0:12:32So we saw that git clone was the command we could use in order
    • 0:12:35to clone a repository, take a repository and download it onto our own computer.
    • 0:12:40The next command we'll take a look at is a command called git add.
    • 0:12:44And what git add is going to do is it's going
    • 0:12:46to let us tell Git that I would like to add a file as one
    • 0:12:50to track the next time I save, the next time
    • 0:12:54I make a commit to say that I would like to take
    • 0:12:56a snapshot of all these files, such that I'm able to refer back to them later.
    • 0:13:00And in order to do that, I need to tell Git what files to keep track of.
    • 0:13:03So if, for example, I am working on this file,
    • 0:13:06and I'd like to tell Git that I'd like to track it,
    • 0:13:08I can run a command like git add, followed by the name of the file like
    • 0:13:13foo.py or .html or whatever file it happens to be.
    • 0:13:16And then Git will display a message saying
    • 0:13:18that right now, we've added foo.py.
    • 0:13:21This is now a file that will be saved the next time I make a commit.
    • 0:13:26So why are these two separate steps?
    • 0:13:28Well, one reason you might imagine is that if I'm
    • 0:13:30working on a lot of different files, say I'm working on 10 different files,
    • 0:13:34and there are only three that I'm happy with, three that I want to save,
    • 0:13:37I don't want to just say save and have everything be saved in a commit.
    • 0:13:41I might want to say that you know what?
    • 0:13:42These are the only three files that I actually want to save right now,
    • 0:13:46and the other ones I'm still working on.
    • 0:13:48So it gives us that ability to have this separation to say,
    • 0:13:51let me explicitly say that I want to track this file the next time I save,
    • 0:13:55the next time I make a commit, and not all
    • 0:13:58of the files, for example, though there are shortcuts we can use if we do
    • 0:14:01want to add all of the files, and we'll see those in a moment as well.
    • 0:14:05So let's go ahead and try that.
    • 0:14:06We'll go back to our repository where I've created this hello.html file,
    • 0:14:11and now what I'd like to do is say that I
    • 0:14:13would like to add the hello.html file to my Git repository.
    • 0:14:17So inside of my terminal, I'll now say--
    • 0:14:20again, I have a hello.html file here--
    • 0:14:22I'll say git add, followed by hello.html.
    • 0:14:28And you'll notice that so far, nothing seems to have happened,
    • 0:14:31because so far, I haven't yet saved anything.
    • 0:14:33I've just said that I would like to add hello.html as a file
    • 0:14:38that the next time I say save, the next time I commit my repository,
    • 0:14:42it is going to keep track of the changes I have now made to hello.html.
    • 0:14:46So how do I actually make a commit?
    • 0:14:48How do I actually say, save the state of these files?
    • 0:14:51Well, that's going to be one more Git command, which is known as git commit.
    • 0:14:55When I say, git commit, I'm going to tell my Git repository that I would
    • 0:14:58like to save a snapshot of the current state of the repository,
    • 0:15:01keeping track of any of the changes that have been made to files
    • 0:15:04that I've added using git add.
    • 0:15:06And the way we run it is by running git commit, followed by -m, and then
    • 0:15:11in quotation marks, a message.
    • 0:15:13And this message is known as a commit message,
    • 0:15:16and what it is is it's a description in English,
    • 0:15:18or whatever your language is, of what changes
    • 0:15:21you've made in this most recent commit, because over time
    • 0:15:25as you work on a big project, you're probably going to make lots of commits
    • 0:15:28as you make lots of changes to your program.
    • 0:15:30You'll commit and commit again after each new addition
    • 0:15:32you make to the project.
    • 0:15:33And you might want to refer back to a previous commit,
    • 0:15:36but it's only valuable to do so if you can
    • 0:15:37identify in which commit you made a particular change, for example.
    • 0:15:42So by providing some English message-- just some note
    • 0:15:44to yourself-- such that later you can refer back to all your commit messages
    • 0:15:48and know that, all right, at this point in time, in this commit,
    • 0:15:51this is the change that I made that can just make it easier
    • 0:15:53to keep track of all the changes that you've made him to a particular Git
    • 0:15:57repository.
    • 0:15:58So when you type git commit followed by -m, you might include a message,
    • 0:16:02something like, "I added a new line," for example.
    • 0:16:05And when you do, Git is going to save a new snapshot of a version of your code
    • 0:16:09right now, keeping track of the old version or old versions
    • 0:16:13that used to exist there inside of the repository.
    • 0:16:16So let's try and actually make a commit now and see
    • 0:16:19how that's actually going to work.
    • 0:16:21So we've already added the file, as by running git add,
    • 0:16:24to say add the hello.html file as one to keep
    • 0:16:26track of, but now when we're happy with it
    • 0:16:29and we can make additional changes to the file if we want to,
    • 0:16:32I can go back into the terminal and now say git commit and then -m,
    • 0:16:38and then I can specify the commit message,
    • 0:16:40some English description of what it is that I did in this most recent commit.
    • 0:16:45And what I did was I added the hello.html file.
    • 0:16:50So I'm just going to say, I added the hello.html file.
    • 0:16:53That was the change I made in this most recent commit.
    • 0:16:56I'll go ahead and press Return.
    • 0:16:58And here's what it's telling me.
    • 0:17:00It's telling me one file has been changed with nine insertions.
    • 0:17:04So Git keeps track of changes in terms of how many lines
    • 0:17:07have been added or inserted, and how many lines
    • 0:17:09have been deleted or removed.
    • 0:17:11And in this case, it's telling me there have been nine insertions to one file,
    • 0:17:14because previously, the file didn't exist,
    • 0:17:17and now a file that has nine lines does exist.
    • 0:17:20And now I have saved hello.html to this Git repository.
    • 0:17:25So now you might imagine if I go back to my Git repository on GitHub's website
    • 0:17:29and refresh it, that maybe I'll see that hello.html file,
    • 0:17:32but I refresh, and nothing happened, nothing changed.
    • 0:17:36I don't see my hello.html file.
    • 0:17:39And that's because there's one final step
    • 0:17:41here I'm missing before my changes are going to be reflected online.
    • 0:17:44Recall that when I ran the git clone step in order
    • 0:17:47to clone the repository from GitHub, GitHub had a version of the repository,
    • 0:17:52and I ran git clone it to download a copy of that repository
    • 0:17:55onto my own computer, and when I ran git add to add the hello.html file,
    • 0:18:00or I ran git commit to say, I would like to save these changes,
    • 0:18:03I was always making those changes only to my local version of the repository.
    • 0:18:08I was never affecting anything that was already on GitHub.
    • 0:18:11The changes I was making were only happening on my own computer.
    • 0:18:14If I want to push those changes up to GitHub,
    • 0:18:17then I'm going to need some additional commands.
    • 0:18:19And in fact, we can see what's currently going on inside of my repository
    • 0:18:22using a command called git status.
    • 0:18:25And what git status will do is, it'll tell us what's currently
    • 0:18:28happening inside of my repository.
    • 0:18:30So, for example, if I were to, in this current state,
    • 0:18:33run the command git status, then Git is going to report back to me
    • 0:18:36and tell me that I'm currently on branch master--
    • 0:18:40more on branches later--
    • 0:18:42but then it's saying, my branch is ahead of origin master by one commit.
    • 0:18:47So this is a long-winded way of saying that my local version
    • 0:18:50of the repository-- the version of the repository on my computer--
    • 0:18:54is ahead of the origin version of the repository,
    • 0:18:57the version of the repository that's up on GitHub by one commit,
    • 0:19:01that I have one commit that the origin GitHub does not have.
    • 0:19:05And it's helpfully telling me I can use the command get
    • 0:19:08push to publish your local commits.
    • 0:19:10get push of the command that I can use in order to say,
    • 0:19:13I would like to take my changes and actually push them up to the server,
    • 0:19:17push them up to GitHub so that they're reflected there.
    • 0:19:20So after we've checked our current status with git status,
    • 0:19:22we can use the command git push to say that now whatever changes that I've
    • 0:19:26made, when I run git push, those changes get pushed up to GitHub,
    • 0:19:31so GitHub has access to all of the commits that I have now made.
    • 0:19:35So let's try those two commands now-- git status,
    • 0:19:38to see what's currently going on inside of my repository, and then git push,
    • 0:19:42to say, I would like to now push those changes to GitHub,
    • 0:19:45so that the online version of the repository
    • 0:19:47has the same contents as the local version on my own computer.
    • 0:19:52All right.
    • 0:19:52So in my terminal now, I can run git status,
    • 0:19:55and I see that I am on branch master, same as before.
    • 0:19:57And it's a slightly different message, because there
    • 0:19:59is nothing currently inside the repository,
    • 0:20:01but the key here is that now I can run the command
    • 0:20:04git push to, say, take all of the changes
    • 0:20:06that I have made to my repository and go ahead and push them up to GitHub.
    • 0:20:11So I'll type git push, and what's going to happen
    • 0:20:13is it's going to compress all the information,
    • 0:20:15and it's going to push it up to GitHub to this URL.
    • 0:20:19And now, if I go back to GitHub's website, GitHub.com/myrepository,
    • 0:20:24and refresh the page, I'll see that I do actually now see something different.
    • 0:20:29And so this is what GitHub's user interface actually looks like.
    • 0:20:31It gives me a few pieces of information.
    • 0:20:33It's telling me, for example, that there's one commit currently made
    • 0:20:36to the repository-- that's the one I just made--
    • 0:20:38that is on one branch, so if I've only created one branch, the default one,
    • 0:20:42but we'll see how to create more branches later.
    • 0:20:44And, in particular, down below, you'll see
    • 0:20:46the files that currently exist inside of this repository,
    • 0:20:49that right now I have this hello.html file, which is the one that I pushed,
    • 0:20:54and, in particular, next to it is the commit message, the message
    • 0:20:57from the most recent time that I touched to this file, which is in particular
    • 0:21:01telling me that I added the hello.html file in the most recent
    • 0:21:05commit that affected hello.html.
    • 0:21:08And if I were now to not click on hello.html
    • 0:21:11to actually see what's inside of it, I would see the same content
    • 0:21:15that I wrote in the file before.
    • 0:21:17I see !DOCTYPE html, and then the "Hello, world!"
    • 0:21:19page that we've seen a couple of times now.
    • 0:21:22So I made the change on my own computer, and I've now pushed them up to GitHub,
    • 0:21:25so they're now inside of this repository.
    • 0:21:27That's now public, such that anyone else,
    • 0:21:29if they wanted to collaborate on this project, could take this URL,
    • 0:21:33clone it to their own computer, and make their own changes locally as well.
    • 0:21:37So now we can explore how we might be able to make additional changes
    • 0:21:41to this web page as well.
    • 0:21:43So if, for example, I wanted to add a heading to this web page, for instance,
    • 0:21:47I might at the top of the body say something like, in an h1 tag,
    • 0:21:52"Welcome to my website!"
    • 0:21:56And now if I, just for good measure, open up hello.html
    • 0:21:58to see what it looks like, this is what my web page now looks like.
    • 0:22:04And now I've made changes to my hello.html file, changes
    • 0:22:07that have not yet been saved, and I can tell that if I run git status.
    • 0:22:12git status is your go-to for telling you what's currently
    • 0:22:14going on inside of your repository.
    • 0:22:17So here we see "Changes not staged for commit,"
    • 0:22:20which is a fancy way of saying, files that have been changed,
    • 0:22:23but I haven't said I would like to keep track of them in the next commit.
    • 0:22:27It's telling me that I've modified hello.html,
    • 0:22:30but it's not something that Git is currently
    • 0:22:32going to keep track of the next time I make a save.
    • 0:22:35So if I want to save hello.html when I commit for the next time,
    • 0:22:38then I'll first need to run git add hello.html,
    • 0:22:42and then I could run git commit.
    • 0:22:44But there's actually a bit of a shorthand here.
    • 0:22:46If you want to add all of the files that have been changed
    • 0:22:49and commit at the same time, the shorthand is git commit -am.
    • 0:22:55Remember, before we just used -m to say, specify a message.
    • 0:22:58-am means git commit all of the files that have been changed--
    • 0:23:02a for all-- and also provide a message.
    • 0:23:05So you can combine the git add step and git commit step
    • 0:23:08into just a single step by saying, I'd like to commit all of the files
    • 0:23:11that I've changed, and then I'll provide a message.
    • 0:23:13What exactly did I change?
    • 0:23:15I added a heading.
    • 0:23:19I'll go ahead and press Return.
    • 0:23:20It's kept track of the fact that I have now
    • 0:23:22changed one file with one insertion.
    • 0:23:24All I did was add one new line to that file.
    • 0:23:28And now if I run git status, it's going to tell me, I'm on branch master,
    • 0:23:32and I am ahead of origin master--
    • 0:23:34origin master being the version on GitHub--
    • 0:23:36by one commit, that I have this "Add a heading"
    • 0:23:39commit, but right now, on GitHub, if I refresh this page,
    • 0:23:43it's still showing the old version of that page.
    • 0:23:48In order to take my changes that I've made on my computer
    • 0:23:50and make sure they're updated on GitHub, I can just run git push to say,
    • 0:23:54push those changes up to GitHub, and once that's done,
    • 0:23:58I can now refresh the page on GitHub, and I'll now
    • 0:24:00see that GitHub now has the latest version of my program as well.
    • 0:24:04It now has this h1.
    • 0:24:06It says, "Welcome to my website!"
    • 0:24:09So that's git push now, the ability for me to say I
    • 0:24:12would like to take the changes that I have made to the my repository
    • 0:24:16and push them up to some remote server, the remote server on GitHub,
    • 0:24:19for example.
    • 0:24:20But we can also go in the opposite way.
    • 0:24:23You might imagine that maybe the version that's up on GitHub
    • 0:24:26is more recent than the version that I have on my computer, and in that case,
    • 0:24:30I would like to download the latest version of the repository that
    • 0:24:33currently exists on GitHub.
    • 0:24:35And in order to do that, we can use a command called git pull.
    • 0:24:39How does that work?
    • 0:24:40Well, when I run git pull, what's going to happen
    • 0:24:43is the opposite of what git push did.
    • 0:24:45While git push took my changes on my computer and pushed them up to GitHub,
    • 0:24:49git pull, we'll say, take the changes that currently exist on GitHub,
    • 0:24:53and go ahead and pull the most recent changes down,
    • 0:24:56so that I and my local version of the repository
    • 0:24:58have access to the latest version of all of the code that is currently
    • 0:25:02on GitHub.
    • 0:25:03And we can demonstrate this, for example,
    • 0:25:05if I go back and take a look at GitHub's website itself,
    • 0:25:08because on GitHub, I actually have the ability
    • 0:25:10to edit files using GitHub's interface.
    • 0:25:13So I'm going to simulate someone else working on this project, for example.
    • 0:25:17Maybe someone else added a second heading,
    • 0:25:20so they add an h2 that says, just hello, for example.
    • 0:25:26And then, they can provide a commit message.
    • 0:25:29This is sort of a graphical equivalent to the -m and then a message
    • 0:25:33that we provided before.
    • 0:25:34They can say, "Added h2," and then commit.
    • 0:25:41So this is another way to edit a Git repository is by literally in editing
    • 0:25:46it inside of GitHub's interface.
    • 0:25:48So GitHub allows you to just edit a file,
    • 0:25:50and then add or modify any of the lines there.
    • 0:25:54So now the version on GitHub is actually different from the version
    • 0:25:58that we have on our computer, that if we look at hello.html
    • 0:26:01here I only see the h1, and I don't see the h2 that
    • 0:26:05was just added, because it's a more recent commit that I don't yet
    • 0:26:08have access to.
    • 0:26:09But if I want to download that commit, then what I can say
    • 0:26:13is inside my terminal, I can say git pull in order to download it,
    • 0:26:18and all right.
    • 0:26:19It's updated one file.
    • 0:26:21It's made some changes.
    • 0:26:22And so now, if I go back to the file, you'll
    • 0:26:25notice that automatically I now have the latest version of the file.
    • 0:26:28I now have this h2 that says "Hello!"
    • 0:26:31because I've pulled the latest version of the file down from GitHub.
    • 0:26:35So via combination of get push and get pull,
    • 0:26:38I can make changes to my code to push them up to GitHub,
    • 0:26:41and also get access to the latest version of code that
    • 0:26:44already is on GitHub.
    • 0:26:46But as we do this, you might imagine that we
    • 0:26:48could run into some sort of problem.
    • 0:26:50In particular, we might run into a problem
    • 0:26:52if I've been making changes to my code, and someone else
    • 0:26:56working on my same project has also been making changes to the code.
    • 0:27:00What happens if we both make changes to the same part of the code
    • 0:27:04and then try to sync up our work together?
    • 0:27:05What's going to happen?
    • 0:27:07Well, we're going to run into some sort of conflict,
    • 0:27:09because I've made changes to the same line
    • 0:27:11that my colleague has been making changes to, and that type of conflict
    • 0:27:14is called a merge conflict, that when trying
    • 0:27:16to merge my changes with the changes that someone else has made,
    • 0:27:20we run into a situation where suddenly Git doesn't know what to do.
    • 0:27:23They're two different sets of changes, and we
    • 0:27:25need to figure out how to resolve them and what to do
    • 0:27:28when we run into this sort of conflict.
    • 0:27:30So here's what's going to happen.
    • 0:27:32If ever we run into this sort of merge conflict,
    • 0:27:34it is generally going to happen if I try and pull in or merge in some changes
    • 0:27:38from elsewhere.
    • 0:27:39So let's say I run git pull, but there's some conflicting commit,
    • 0:27:43something that is online that conflicts with my current version
    • 0:27:46of the repository.
    • 0:27:47What I'll get is a message like this.
    • 0:27:49Some conflict saying, Merge conflicts in some file have failed.
    • 0:27:53You need to fix the conflicts and then commit the results.
    • 0:27:57So what might those conflicts look like?
    • 0:27:59Well, generally, the file is going to look a little something like this.
    • 0:28:02Git is automatically going to add some metadata to the file
    • 0:28:06to describe the things that it can't quite figure out,
    • 0:28:08and it's a lot of cryptic looking information,
    • 0:28:10but we can distill it down into a couple of key parts.
    • 0:28:13Everything in between these arrows at the top and equal signs
    • 0:28:17here are your changes, the changes I have
    • 0:28:20made on my version of the repository that are somehow
    • 0:28:23conflicting with some other changes.
    • 0:28:25Everything between these equal signs and these arrows
    • 0:28:28down here are the remote changes, the changes from GitHub
    • 0:28:32that I'm trying to pull in that somehow are conflicting with what
    • 0:28:35I've currently been working on.
    • 0:28:36And then this sequence of numbers and characters
    • 0:28:39here is the hash of the conflicting commit.
    • 0:28:42So every comment gets a hash, just some sequence of numbers and characters
    • 0:28:47that is likely to be unique that helps to identify any particular commit,
    • 0:28:51and Git will automatically generate a hash every time you make a comment,
    • 0:28:55and we'll see in a moment how you can look at all of those possible commits.
    • 0:28:59But here again, it's just helpfully telling us,
    • 0:29:01this is the commit that is causing the conflict, just for our own reference.
    • 0:29:05In order to address this merge conflict, the way we do it is we
    • 0:29:08first need to remove all of these merge conflict markers that
    • 0:29:11exist in the text file and decide what we
    • 0:29:15want as the resolution of the conflict.
    • 0:29:17So maybe I want to keep my version of the changes;
    • 0:29:20maybe I want to keep the remote version of the changes, the changes that
    • 0:29:23were already on GitHub, for example; or maybe I
    • 0:29:25want to combine them in some intelligent way.
    • 0:29:27I, the programmer get to make that decision.
    • 0:29:29I get to look at my version and the conflicting version
    • 0:29:32and decide how I want to resolve that conflict.
    • 0:29:35I'll remove any of the blank lines and then commit the changes to say,
    • 0:29:39this is what I want the merged version of this program to look like.
    • 0:29:43So let's now take a look at an example of a merge conflict in action,
    • 0:29:47to see how one might arise, and how we might actually
    • 0:29:50go going about dealing with a merge conflict should it happen.
    • 0:29:54So I, on my computer now, I'm going to make a change to this page.
    • 0:29:59I'm going to say, add a second exclamation.
    • 0:30:01One exclamation point wasn't enough.
    • 0:30:03I'll add in a second exclamation point to this h1,
    • 0:30:06and I'll go ahead and commit those changes.
    • 0:30:08I'll say git commit -am "Add exclamation point,"
    • 0:30:14and I'll go ahead and commit those changes.
    • 0:30:16I've saved this new version of the program.
    • 0:30:18But I'm not going to push the code yet.
    • 0:30:20Instead, what I'm going to do is simulating someone else
    • 0:30:22working on the same file.
    • 0:30:24Maybe someone else on GitHub has decided, you know what?
    • 0:30:27For this h1, what we'd really like to do is
    • 0:30:30add some style to it with some inline style by saying,
    • 0:30:33let's give it a color of blue, for example.
    • 0:30:36So they've added some CSS.
    • 0:30:39We'll go ahead and write a commit message.
    • 0:30:41What did they do?
    • 0:30:41They added some style.
    • 0:30:43And we'll commit those changes.
    • 0:30:46And now what we've created is what is going
    • 0:30:48to be a merge conflict, that someone else on GitHub
    • 0:30:52has made a change to this line changing the color to blue
    • 0:30:56of this particular h1 tag, for example, and I meanwhile
    • 0:31:00have also made a change to the same line, adding an exclamation point.
    • 0:31:03And Git entirely operates in terms of adding lines and removing lines.
    • 0:31:07Given that we both made changes to the same line,
    • 0:31:10Git going to have a very hard time figuring out
    • 0:31:12what to do in this scenario.
    • 0:31:15So here in my terminal, I'll go ahead and run git pull,
    • 0:31:17because I want to pull in those latest changes, and when I do,
    • 0:31:21I'll see that, all right, I get this message.
    • 0:31:23CONFLICT: There was a merge conflict in hello.html.
    • 0:31:26The automatic merge failed, because normally, Git we'll
    • 0:31:29try to merge files automatically if I can,
    • 0:31:31but sometimes it can't, so now I need to fix the conflicts
    • 0:31:36and then commit the results.
    • 0:31:39So let's go ahead and look at what's inside of hello.html,
    • 0:31:43and what you'll notice is a whole bunch of these markers,
    • 0:31:45and my text editor just so happens to highlight them for me,
    • 0:31:48so that I can see them a little more clearly,
    • 0:31:49but this is just highlighting provided by the text editor.
    • 0:31:52It's not actually part of the text itself.
    • 0:31:54But you'll notice all of these arrows, and then all of these equal sides,
    • 0:31:58and in between, here is my version of this line
    • 0:32:01of code, the line of code with the extra exclamation point at the end of it.
    • 0:32:06Down below, here is the remote conflicting version
    • 0:32:10of the same code, the version that was modified on GitHub that I am now
    • 0:32:13trying to pull in.
    • 0:32:14This is the version that says, we want style color blue inside
    • 0:32:18of the inline style for this particular h1 element.
    • 0:32:22And now what I need to do is somehow figure
    • 0:32:23out how to merge these two together.
    • 0:32:26How do I want to resolve this conflict?
    • 0:32:28Well, in this particular case, I might like
    • 0:32:30to resolve this conflict by just taking the best of both worlds.
    • 0:32:34If the person on GitHub wanted to add a style attribute to this h1 element,
    • 0:32:38and I wanted the extra exclamation point, I can do both.
    • 0:32:41I can go ahead and just add an extra exclamation point,
    • 0:32:45and then get rid of my version, and then also get rid of these commit markers.
    • 0:32:50So go ahead and remove those.
    • 0:32:52I basically modify the file until I'm satisfied with it
    • 0:32:55until I think that, all right, this is the way I
    • 0:32:57wanted to resolve the conflict.
    • 0:32:59One person added color.
    • 0:33:01One person then added punctuation.
    • 0:33:02The way to resolve it in this case is just use both of them.
    • 0:33:05But here is where some human intuition comes in.
    • 0:33:07The human programmer doesn't need to look at this file and figure out,
    • 0:33:10how exactly do we want to resolve this conflict?
    • 0:33:13How do we want to figure out how to take these different changes
    • 0:33:16and merge them all together?
    • 0:33:18But once we're satisfied with it, we can go ahead and commit the results.
    • 0:33:22I can say git commit -am "Fix merge conflict,"
    • 0:33:27and all right, we fixed the merge conflict.
    • 0:33:29And now, if I push those results back up to GitHub, when that is done
    • 0:33:36and I refresh the page, I now see the updated line of code on GitHub,
    • 0:33:40with the h1 that has both the inline styling and the extra punctuation,
    • 0:33:45because I've resolved the merge conflict,
    • 0:33:47and then I've pushed that information back up to GitHub as well.
    • 0:33:52There are a couple of other Git commands that are just useful to know about.
    • 0:33:55I mean, there are many, but we'll talk about a couple
    • 0:33:57right now, the first of which is git log.
    • 0:33:59git log is useful if you ever need to keep track of all of the changes
    • 0:34:03that you've made to your code, you want to keep
    • 0:34:05track of all of the commits that have been
    • 0:34:06made in this particular repository.
    • 0:34:08All you need to do is run the command git log,
    • 0:34:11and Git will spit out a bunch of messages
    • 0:34:13that look like this, describing each of your comments for each commit.
    • 0:34:16It'll tell you what the commit hash is, such
    • 0:34:19that you can reference it more easily, it'll tell you who made the commit,
    • 0:34:22it will tell you the date on which that commit was made,
    • 0:34:25and it will also tell you the commit message.
    • 0:34:27So if you need to very quickly look back and see on what day with this feature
    • 0:34:31added or who added this part to the web page,
    • 0:34:33you can just look through the git log, find the commit in question,
    • 0:34:37And then you'll know which commit it happened to be.
    • 0:34:40Also helpful is if you realize that you've
    • 0:34:42made a change that you didn't mean to, and you
    • 0:34:44want to go back to a previous commit.
    • 0:34:46Then, in that case, you can use a command called
    • 0:34:48to git reset, which has a number of different possible ways to use it,
    • 0:34:52but git reset in effect will take the current state of the repository
    • 0:34:55and revert it back to an older state of the repository, for example.
    • 0:35:00So a couple of ways you can use it are like this.
    • 0:35:02You can do git reset --hard, meaning hard reset, reset everything, back to--
    • 0:35:08and then you can plug in a commit hash.
    • 0:35:10So git log, as you might recall from before,
    • 0:35:12gave you the commit hashes for each of the various different commits.
    • 0:35:16If I want to go back to one particular commit, I can say git reset --hard
    • 0:35:20and then the commit hash that I want to go back to,
    • 0:35:24and I'll go back to that commit.
    • 0:35:26Alternatively, I could say something like, git reset --hard origin/master.
    • 0:35:31And recall that origin/master is the version of my repository
    • 0:35:35that's currently on GitHub.
    • 0:35:36So if I want to take my current version of the repository
    • 0:35:39and reset it back to whatever is on GitHub,
    • 0:35:41then I can use a command like this in order to do so.
    • 0:35:44So you run git reset, followed by a commit hash,
    • 0:35:47and that will reset the current state of your repository back to whatever state
    • 0:35:51it was in previously.
    • 0:35:53And there are a number of other Git commands
    • 0:35:55as well, that can be quite helpful as you
    • 0:35:57begin working with larger and larger projects,
    • 0:35:59but these are some of the most helpful, and some other ones you'll
    • 0:36:02use the most often are just adding files that you want to keep track of;
    • 0:36:05git commit to say, I would like to make a save,
    • 0:36:07I would like to save the current state of all of these files; push
    • 0:36:10and pull to be able to upload changes and download changes that have been
    • 0:36:14made to your repository; and then some helpful commands like reset and log
    • 0:36:18and status,
    • 0:36:19just to give you information about your repository
    • 0:36:21and get you back to an older state of the repository if you need to.
    • 0:36:26But as we begin to work on more and more projects,
    • 0:36:29especially as we begin to work on more sophisticated projects,
    • 0:36:32you may find that just keeping track of one
    • 0:36:34change after another isn't nearly as powerful as you might like it to be.
    • 0:36:38And so we can explore what might happen in a hypothetical situation
    • 0:36:41where you begin making some changes to a Git repository, for example.
    • 0:36:46So let's imagine you make your first commit, you make some changes,
    • 0:36:49you make some additional changes, and maybe
    • 0:36:51you realize you want to start working on a new feature to this web application
    • 0:36:55that you've been working on.
    • 0:36:56So you start working on a new feature, then
    • 0:36:58you continue working on that new feature,
    • 0:37:00but then you realize suddenly, you know what,
    • 0:37:02there was a bug in the original code that I made way back here,
    • 0:37:06and you want to go back and fix that bug,
    • 0:37:08but now we're sort of in a tricky spot, that we want to fix the bug,
    • 0:37:11but we're in the middle of working on a new feature.
    • 0:37:13So what do we do?
    • 0:37:14We could go back to this and try and fix the bug,
    • 0:37:17but then what happens to the new feature?
    • 0:37:19The problem is that this structure-- just change after change after change--
    • 0:37:23it is very linear.
    • 0:37:24It only goes one after another after another.
    • 0:37:27And oftentimes, when you're working on a project,
    • 0:37:29it's not going to operate in a very linear fashion.
    • 0:37:32You're not always working on one thing that immediately
    • 0:37:34follows the thing before it.
    • 0:37:35You might be fixing multiple bugs while working on multiple new features,
    • 0:37:39and you want some way of being able to work on all of those things
    • 0:37:42simultaneously and to easily be able to switch between them.
    • 0:37:46And so that is where branching comes in handy.
    • 0:37:49Branches are Git's way of working on different parts
    • 0:37:52of the repository at the same time.
    • 0:37:55And so you might imagine a situation unfolding more along these lines.
    • 0:37:58You make your first commit, you start to make changes, you make more changes,
    • 0:38:01and when you decide that you'd like to start
    • 0:38:03working on a new feature, for example, rather than making changes in one
    • 0:38:09after another after another on this same branch, so to speak,
    • 0:38:12I can create a new branch.
    • 0:38:14I can branch off and say, you know what?
    • 0:38:16Let's create a new branch and start working on our new feature there,
    • 0:38:19and then keep working on that new feature there.
    • 0:38:22And if I realize later on down the road that, you
    • 0:38:24know what, there was a bug way back at this commit, then
    • 0:38:27I can go back to this commit and create a new branch, where I go ahead
    • 0:38:30and fix that bug.
    • 0:38:31And now I have two different branches, each of which
    • 0:38:35might have different code on it, one of which I've been fixing a bug,
    • 0:38:38one of which I've been working on a new feature on, for example.
    • 0:38:42Generally, each of those branches is going to have a name.
    • 0:38:45So the master branch is your default branch,
    • 0:38:47which is generally going to contain the up-to-date, stable version
    • 0:38:50of your code.
    • 0:38:51And as you're working on newer things, newer additional features,
    • 0:38:54you might have some feature branch, where you're working
    • 0:38:56on some other feature, for example.
    • 0:38:59And at any given time though, your focus is only on one of these two branches,
    • 0:39:04and where your focus is, what the current state of your repository
    • 0:39:07is, is designated by something we call the head.
    • 0:39:11So if HEAD is pointing to master, that means
    • 0:39:13your repository right now is working on this branch, where you fixed the bug.
    • 0:39:17But you can change the head.
    • 0:39:19You can switch what branch you want to look at,
    • 0:39:21and you can check out the feature branch,
    • 0:39:23and say, let's look at that branch, and begin working on that as well.
    • 0:39:26And you can begin working on these different branches
    • 0:39:28by switching where your head is, switching from one branch to another,
    • 0:39:32and then back again.
    • 0:39:34And only when you're satisfied, that you know what, this bug is fixed,
    • 0:39:37and this feature is in a satisfactory place, then, after all of that,
    • 0:39:40we can merge those changes back together,
    • 0:39:42so that everything comes back onto this unified master branch that
    • 0:39:46now has all of the latest code.
    • 0:39:49And that's the real power of git branch, this ability
    • 0:39:52to say that I would like to be working on multiple things simultaneously
    • 0:39:55and be working on a feature without disrupting the master
    • 0:39:59version of the code.
    • 0:40:01So, let's now take a look at an example of how we might go about doing that.
    • 0:40:08So here in my hello.html file, I've been adding some style to this h1.
    • 0:40:12I added the color of blue.
    • 0:40:14And let's say that I would like to make some changes.
    • 0:40:16I would like to move the styling outside of inline styling,
    • 0:40:21and I'd instead like to move it up into the head section of the web page,
    • 0:40:24because we decided earlier that was slightly better design for a web
    • 0:40:28page like this.
    • 0:40:30I could make those changes immediately, but I can instead,
    • 0:40:33if I expect I might be working on multiple changes,
    • 0:40:35I could move on to a different branch, and branch off into something else
    • 0:40:39in order to work on these new changes.
    • 0:40:41And so here are some of the key commands to know about this.
    • 0:40:44If I type git branch, that will tell me what branch I'm currently on
    • 0:40:49and what branches exist in my repository.
    • 0:40:52So here, for example, I type git branch, and I
    • 0:40:54see that I just have a single branch called master,
    • 0:40:57and the star on the left-hand side tells me
    • 0:40:59that this is the branch that I am currently on,
    • 0:41:01the only branch that there is.
    • 0:41:04If I want to check out a new branch, I can type git checkout,
    • 0:41:08and if it's a new branch, I'll type git checkout -b and then
    • 0:41:13the name of the new branch.
    • 0:41:14And I'll call the new branch style, because I'm
    • 0:41:17going to be making some style changes to the web page, for example.
    • 0:41:20So I typed git checkout -b style, and Git gives me a message.
    • 0:41:24I have switched to a new branch called style.
    • 0:41:27And now, if I type git branch again, you'll
    • 0:41:30see that now I have two branches.
    • 0:41:32I have the master branch, which is the branch, I was originally on,
    • 0:41:35and now I have the style branch, which is
    • 0:41:37this new branch which I am on now, as indicated by the star
    • 0:41:41on the left-hand side.
    • 0:41:43So now that I'm on this new branch, I can feel free to make any changes
    • 0:41:45that I want, and nothing I do is going to mess up
    • 0:41:48what is on the master branch, so long as I stay on this branch.
    • 0:41:51So I can say, all right, let's experiment with removing the style,
    • 0:41:56and let's add a style tag to the top, where
    • 0:41:58I can say that I would like my h1 to have a color of blue, for example.
    • 0:42:02So I've made a whole bunch of changes, and I
    • 0:42:05would like to now commit those changes.
    • 0:42:07I'll say git commit "Move style properties."
    • 0:42:12That's the change that I've made.
    • 0:42:14But I've only made those changes to the style branch.
    • 0:42:18Again, if I run git branch, you'll see that I'm currently
    • 0:42:20on the style branch, where I've moved the style information up
    • 0:42:24here to the top of my page, but I can switch branches by using git checkout.
    • 0:42:30git checkout allows me to switch between branches.
    • 0:42:32We used to git checkout -b to create a new branch,
    • 0:42:35but if you're switching to a branch that already exists,
    • 0:42:37I can just say git checkout master, for example,
    • 0:42:41to switch my current branch from the style branch to the master branch.
    • 0:42:45So I run git checkout master.
    • 0:42:47Now I'm on the master branch.
    • 0:42:49And now you'll see, if I go back to the file,
    • 0:42:51now I'm back to the inline styling without the styling
    • 0:42:55up here in the head section of the page.
    • 0:42:57If I check out the style branch again, then the file immediately goes back.
    • 0:43:01Now I have the style code up here in the style section of the page,
    • 0:43:04and not inline.
    • 0:43:06So these changes have only been made to one part of the page.
    • 0:43:10So now I'll check out master again.
    • 0:43:14And maybe I want to make some other changes on my master branch.
    • 0:43:17Maybe I realized that I want to remove this extra punctuation.
    • 0:43:19You know what?
    • 0:43:20Two exclamation points with too many.
    • 0:43:22We'll remove-- now we just have one.
    • 0:43:25And now we'll commit these changes.
    • 0:43:26I'll say git commit and "Remove punctuation."
    • 0:43:32And now I've removed the punctuation only from the master branch.
    • 0:43:37So this master branch now has just a single exclamation point here,
    • 0:43:41but it still does have the inline styling.
    • 0:43:44So now what I'd like to do is merge in those changes
    • 0:43:48that I made from the other branch.
    • 0:43:49I'd like to take what I was working on in the style branch
    • 0:43:52and merge it into this current version of the repository on my master branch.
    • 0:43:57And in order to do that, the command we'll use is called git merge.
    • 0:44:01So git merge.
    • 0:44:02Notice that I am currently on the master branch, but if I run git
    • 0:44:06merge and then style, that is going to take whatever is on the style branch
    • 0:44:11and attempt to merge it into my current branch.
    • 0:44:15And what we'll find is we're able to get most of the way there,
    • 0:44:19but there's a merge conflict.
    • 0:44:20Now this won't happen all the time when you merge.
    • 0:44:22Sometimes, Git will be smart enough to know
    • 0:44:24that if one change has been made to one part of a file,
    • 0:44:26and one change has been made to another part of a file, when you merge
    • 0:44:29those changes back together, Git will resolve those merge conflicts
    • 0:44:32automatically.
    • 0:44:33But in this case, that wasn't the case, because both my style
    • 0:44:37branch and my master branch made changes to the same line of code,
    • 0:44:42and we'll see why if I go back here.
    • 0:44:44You'll notice that in the merged version,
    • 0:44:46we do see this style tag at the head of the page.
    • 0:44:49No problems, no conflict there, because that was just
    • 0:44:52lines that have been added to this page, so there was no conflict.
    • 0:44:56The conflict comes up here, which is where,
    • 0:44:58in my version on the master branch, I removed this punctuation
    • 0:45:02mark, whereas in the version on the style branch,
    • 0:45:05which we can see here by the word "style," we removed the inline styling.
    • 0:45:11So we need to resolve these somehow.
    • 0:45:13And what I'll ultimately do is just get rid of these style
    • 0:45:16markers or the conflict markers, and say, you know what?
    • 0:45:20I would like for the updated version not to have either,
    • 0:45:23not to have the inline styling, and not to have the additional punctuation.
    • 0:45:27So I have now made those changes, I have resolved the merge conflict,
    • 0:45:30and now I can commit.
    • 0:45:32I fixed the merge conflicts.
    • 0:45:36And that's the general workflow now of how branching in Git ultimately works.
    • 0:45:41When you're working on something new, you
    • 0:45:43might branch off in order to say you would
    • 0:45:44like to work on a different part of this web application.
    • 0:45:48You'll make changes, make commits, add changes to that new branch,
    • 0:45:51and when you're satisfied with those changes, when they're in the state
    • 0:45:54that you want them to be, you can then say merge them back
    • 0:45:56in to the original version of the repository.
    • 0:45:59Sometimes you'll have to deal with merge conflicts, though certainly not always.
    • 0:46:03And if you're careful about where you make changes
    • 0:46:05and trying to be careful not to make modifications to the same line of code
    • 0:46:09in two different places, you can reduce the likelihood of actually getting
    • 0:46:13a merge conflict, because Git ultimately is
    • 0:46:15quite smart about how it tries to deal with these sorts of issues.
    • 0:46:20And finally, we'll take a look at a couple of features of GitHub
    • 0:46:23specifically that can be quite helpful as you
    • 0:46:25begin to work on larger projects that have many different moving
    • 0:46:29pieces, the first of which is forking a GitHub repository.
    • 0:46:33So let's go to a GitHub repository and look at the GitHub repository
    • 0:46:38for Bootstrap, for example.
    • 0:46:40So Bootstrap, which is the CSS library that we took a look at last time,
    • 0:46:45is a library that gives us easy access to a whole bunch of different CSS
    • 0:46:48features, and the entire thing is open-source, meaning
    • 0:46:51all of the code for Bootstrap is publicly available for anyone
    • 0:46:54to look at, and more importantly, for anyone to contribute to,
    • 0:46:57that it's not just one person that's been working on all of Bootstrap,
    • 0:47:00but it's a community-driven repository that many people can be working on,
    • 0:47:05adding new features, and making fixes to Bootstrap's code,
    • 0:47:08and collaborating on them by taking advantage of the features of Git
    • 0:47:12And so if you find a Git repository that you would like to contribute to,
    • 0:47:17or if you want other people to be able to contribute to your repository,
    • 0:47:20one thing you can do is fork that repository, and by forking.
    • 0:47:24We mean making your own copy of the original repository.
    • 0:47:28And so up here in the upper right-hand corner of GitHub page
    • 0:47:31is a button called Fork, and we can see that right now, about 68,000 people
    • 0:47:35have already forked Bootstrap's repository,
    • 0:47:38made a copy of the repository into their own GitHub account.
    • 0:47:43And so we could fork it ourselves just by clicking on this button called Fork
    • 0:47:47and then getting our own version of the repository
    • 0:47:49that we can then clone and push and pull from as well.
    • 0:47:53The reason we might do that is that Bootstrap's repository,
    • 0:47:56while it is public, doesn't allow anyone to just push to it.
    • 0:48:00That would be probably unsafe if anyone in the world
    • 0:48:02could just update Bootstrap's master code, but what you can do
    • 0:48:05is copy the code, make a fork of it, make changes to it on your own,
    • 0:48:09push and pull to it.
    • 0:48:10And then, when you feel like you've made a contribution that you would
    • 0:48:13like to send back to Bootstrap, you can open
    • 0:48:15what's called a pull request, that you are requesting that your code be
    • 0:48:19pulled in to Bootstrap's code.
    • 0:48:22And we can look, for example, at Bootstrap's Pull Request tab.
    • 0:48:25It looks like right now there is 71 open pull requests.
    • 0:48:29There are 71 people that have made some fixes
    • 0:48:32or made some changes to Bootstrap's code,
    • 0:48:34and you can submit a pull request to say that you
    • 0:48:36would like to take those changes and merge them back in with Bootstrap's
    • 0:48:41actual code, and the people that maintain
    • 0:48:43Bootstrap's code in this particular repository
    • 0:48:45can review those pull requests, provide feedback, ask for additional changes,
    • 0:48:49and then when everyone's satisfied, they can merge those changes
    • 0:48:52into Bootstrap's actual code.
    • 0:48:54And this is one of the key benefits of open-source software,
    • 0:48:57the ability for multiple people to be working on the same piece of code,
    • 0:49:01and for a community to be able to collaborate on finding bugs
    • 0:49:04on figuring out what changes to make, on figuring out
    • 0:49:07how to improve upon an existing repository
    • 0:49:11and make it better moving forward.
    • 0:49:14And one final thing worth noting about GitHub
    • 0:49:16is an additional feature known as GitHub Pages.
    • 0:49:18GitHub Pages is a free way that GitHub provides
    • 0:49:21to be able to quickly take a website with HTML,
    • 0:49:24and CSS, and maybe even a little bit of JavaScript,
    • 0:49:26and deploy it to the internet for anyone to look at.
    • 0:49:29And anyone with a GitHub account is allowed to create a GitHub Pages
    • 0:49:33website for free.
    • 0:49:34And in order to do so--
    • 0:49:36we can demonstrate it now--
    • 0:49:38all you need to do in GitHub is let's create a new repository
    • 0:49:43that we'll call--
    • 0:49:44it should generally be your user name, .github.io is the conventional name
    • 0:49:50for your GitHub Pages site, though it can have other names.
    • 0:49:53You'll just have to manually turn on GitHub Pages.
    • 0:49:56And we'll go ahead and create this repository now.
    • 0:49:59If you create a get up repository called your username, .github.io,
    • 0:50:04it will automatically be supporting GitHub Pages,
    • 0:50:07and what that means is that I can take this URL and I can clone it.
    • 0:50:12So I can say git clone, followed by this URL.
    • 0:50:17I've cloned an empty repository, but I can go into this repository
    • 0:50:21and add some files to it.
    • 0:50:23I can say, let's add, by default, it's called an index.html file,
    • 0:50:30and I'll create an HTML file.
    • 0:50:34That is my site.
    • 0:50:35And the body of it will just say, "This is my GitHub Pages website."
    • 0:50:43So something like that, something simple.
    • 0:50:45But it can certainly be more complex if you want it to be.
    • 0:50:49Inside my terminal, I will git add this index.html file,
    • 0:50:54and I'll make a commit.
    • 0:50:55And often, the first commit, you'll just, in the commit message,
    • 0:50:58write "First commit," so that we know it was the first commit,
    • 0:51:01and then I'll push those changes to GitHub now.
    • 0:51:07So if you push your changes to a repository called your username,
    • 0:51:10.github.io, then if you take a look at the settings and scroll down,
    • 0:51:18you'll see that GitHub Pages is by default ready to be published.
    • 0:51:22And now if I click on this URL my username, .github.io,
    • 0:51:27you'll see deployed to the internet, such that anyone can go to this URL
    • 0:51:31and see it.
    • 0:51:32They'll see a big heading that says "This is my GitHub page's website,"
    • 0:51:35because this is the way the browser is rendering the HTML that I
    • 0:51:39pushed to my GitHub Pages repository.
    • 0:51:41And the advantage of doing this is that it's
    • 0:51:43very easy now to be able to quickly update my website.
    • 0:51:46All I need to do is if I make a new change, I can commit that change,
    • 0:51:50push that change to GitHub, and when GitHub detects that I've made a push
    • 0:51:54to my GitHub Pages repository, then it will update my website that anyone
    • 0:51:58in the world can access by going to my username, .github.io.
    • 0:52:02And this allows you to leverage all of these features of Git,
    • 0:52:05the ability to branch, the ability to work on different features of your web
    • 0:52:08page at different times, and revert back to different versions of the code
    • 0:52:13as well.
    • 0:52:14So all in all, Git has given us a number of very powerful tools
    • 0:52:18that's given us the ability now to be able to very quickly and very easily
    • 0:52:22keep track of any changes we make to code,
    • 0:52:24keep track of when a piece of code is updated, and to quickly revert back
    • 0:52:27and look at old versions of that code if need be,
    • 0:52:30and in particular, it's given us the ability to take our code
    • 0:52:33and work together with other people on it,
    • 0:52:36such that we can be working on multiple parts of the same project,
    • 0:52:39and someone else working on the same project
    • 0:52:41can also be working on multiple parts of the same project on different branches,
    • 0:52:45and it's very easy then to sync up our changes in order to work together.
    • 0:52:48And so Git is a very popular tool used, not only in
    • 0:52:50the world of web programming, but especially whenever
    • 0:52:53dealing with any kind of larger project, where multiple people might be working
    • 0:52:56on the same thing simultaneously, Git will
    • 0:52:58enable us to more easily develop our web applications
    • 0:53:02over the course of this term.
    • 0:53:04Next time, we'll take a look at Python, which is one of the first programming
    • 0:53:07languages that we'll use as we continue on our journey towards building
    • 0:53:10more sophisticated web applications.
    • 0:53:12I'll see you then.
  • CS50.ai
Shortcuts
Before using a shortcut, click at least once on the video itself (to give it "focus") after closing this window.
Play/Pause spacebar or k
Rewind 10 seconds left arrow or j
Fast forward 10 seconds right arrow or l
Previous frame (while paused) ,
Next frame (while paused) .
Decrease playback rate <
Increase playback rate >
Toggle captions on/off c
Toggle mute m
Toggle full screen f or double-click video