CS50 Video Player
    • 🧁
      • 🍩
      • 🥥
      • 🍿
    • 0:00:02BERNIE LONGBOY: Good afternoon, everyone.
    • 0:00:04Welcome from Cambridge, Massachusetts.
    • 0:00:07Welcome to today's seminar on collaboration and version control
    • 0:00:13with Git.
    • 0:00:15Today we have Tarun Prasad, a junior and computer science major
    • 0:00:19and one of our CS50 teaching fellows.
    • 0:00:22I'm Bernie Longboy, one of the staff members and your moderator for today.
    • 0:00:26Welcome, and thank you, to Tarun.
    • 0:00:29TARUN PRASAD: Thanks so much, Bernie, and thank you all for joining.
    • 0:00:32Very good afternoon to all of you.
    • 0:00:36So like Bernie said, the topic that we'll be talking about today
    • 0:00:39is using this command-line tool called Git
    • 0:00:43for version control and collaboration.
    • 0:00:48So before we start talking about Git is or what we can do with it,
    • 0:00:52consider the following two scenarios.
    • 0:00:55The first scenario is that you're working on a CS50 problem set,
    • 0:00:59say Finance.
    • 0:01:00And you're able to get some portions of the P set working perfectly,
    • 0:01:03so things like register, and quote, and buy.
    • 0:01:06But you're confused as to how to complete index and display
    • 0:01:09a table of stocks that the user owns.
    • 0:01:12And while attempting to make more progress,
    • 0:01:14you accidentally mess up the working code that you already had.
    • 0:01:18And so now all that you see are internal server errors everywhere,
    • 0:01:21no matter what you try to do.
    • 0:01:23So in hindsight, what are some things that you
    • 0:01:25could have done to prevent this?
    • 0:01:27And feel free to use the chat to send in your answers,
    • 0:01:30and we can talk about some of them.
    • 0:01:44What are some things that you could have done to prevent this from happening?
    • 0:01:47How could you have?
    • 0:01:50You could have used some sort of version control, the version control.
    • 0:01:53Yes, use Git.
    • 0:01:57You could have made some backups.
    • 0:01:59Some of you are suggesting using some sort of backup,
    • 0:02:01so that could be a good idea.
    • 0:02:02You could have copied over your entire codebase, zip it into a ZIP file,
    • 0:02:08store it on your desktop.
    • 0:02:09And full disclosure-- I've definitely done this in the past.
    • 0:02:14You could absolutely do that, and maybe you would do that once every day.
    • 0:02:18At the end of every day, you just create a ZIP backup of your entire code space.
    • 0:02:23The main problem with doing something like that
    • 0:02:25is, especially if your codebase is really large--
    • 0:02:29imagine you have a really large number of images and videos
    • 0:02:34within your codebase--
    • 0:02:36you would have to make multiple copies of that.
    • 0:02:38And so this can very quickly become very large and take up a lot of space
    • 0:02:44unnecessarily.
    • 0:02:46Now, one of you is suggesting that you can take a note of the changes
    • 0:02:50that we made.
    • 0:02:51So that could be another really good idea.
    • 0:02:53Maybe we just open a Google Doc.
    • 0:02:54And maybe every single day, we write down, OK, I added lines 23 to 30
    • 0:03:01as these specific lines of code.
    • 0:03:04I deleted line 15, and then I modified line 14
    • 0:03:07by adding a semicolon at the end.
    • 0:03:09And that could be another really useful way
    • 0:03:11of managing this sort of a situation, where we don't actually
    • 0:03:15use up as much space.
    • 0:03:20So thank you for the ideas, and let's go on to scenario two.
    • 0:03:27So let's say you decide to team up with a friend for your CS50 final project,
    • 0:03:30and you want to build a web app.
    • 0:03:33The two of you are trying to decide how to split up tasks.
    • 0:03:35You really want to design the home page, using HTML and CSS,
    • 0:03:38including the fonts, the styles, the colors, the text, et cetera.
    • 0:03:42But your friend really wants to implement
    • 0:03:44the sign-up and log-in workflow, so the HTML form,
    • 0:03:47as well as some of the JavaScript, as well as the Flash backend.
    • 0:03:52So given that you both want to edit the same files, but in different ways,
    • 0:03:56what are some ways to deal with this?
    • 0:04:01And again, feel free to send messages in the chat, and we can talk through them.
    • 0:04:12You can use an IDE that has real-time collaboration.
    • 0:04:14Yeah, that absolutely works.
    • 0:04:20Communication before doing any changes.
    • 0:04:24Some of you are suggesting Git branches, which is a really good idea, which
    • 0:04:27we'll come to later today.
    • 0:04:39Any other thoughts?
    • 0:04:41Git branches?
    • 0:04:48Using Replit.
    • 0:04:49Yeah, using some sort of a collaborative code writer.
    • 0:04:51Maybe even in the worst case, Google Docs, maybe
    • 0:04:55copying over your entire file into Google Docs,
    • 0:04:58and manually spacing everything and typing everything
    • 0:05:00until everything looks OK.
    • 0:05:02That might work.
    • 0:05:03But I mean, some other ideas might also be using something like--
    • 0:05:09or just taking turns sitting at the same device.
    • 0:05:12And maybe one person types code first, and then the other person takes over.
    • 0:05:16And again, you can see that many of these have disadvantages.
    • 0:05:19Either these ideas are somewhat slow, or maybe two people
    • 0:05:24work on the two different things simultaneously.
    • 0:05:26And then one person sends over their changes to the other person via email,
    • 0:05:31and the other person then merges them in by going through it line by line
    • 0:05:34and seeing what changed.
    • 0:05:38Yeah, so thanks again for the great ideas.
    • 0:05:43A lot of these involve a lot of manual work
    • 0:05:46and can often be slow or time-consuming.
    • 0:05:49And that's where this command-line tool called Git comes in.
    • 0:05:55Git is essentially a command-line version control system,
    • 0:05:58which means it automates a lot of the ideas
    • 0:06:01that we just spoke about, storing differences
    • 0:06:04between different versions of your codebase,
    • 0:06:08or allowing collaboration, allowing different people to work
    • 0:06:13on the same files in different locations,
    • 0:06:16and enabling you to merge them together in a very easy and straightforward way.
    • 0:06:23So in Git, each project is stored as a repository.
    • 0:06:28And each saved version of the repository is called a commit.
    • 0:06:34A local repository on your device can be associated
    • 0:06:37with other repositories hosted elsewhere, like on GitHub and GitLab.
    • 0:06:40And these repositories hosted on other servers are called remotes.
    • 0:06:46So your repository consists of both a history of the commits that you made,
    • 0:06:50so all of the previous versions of your codebase,
    • 0:06:54as well as the latest version.
    • 0:06:58Each commit stores the changes made since the previous commit,
    • 0:07:01and is identified through a commit hash.
    • 0:07:04And so I'm sure most of you have heard of hash functions,
    • 0:07:06and so that's essentially what's used over here.
    • 0:07:09Each commit stores what changes you've made since the previous commit.
    • 0:07:13And then that information is somehow hashed
    • 0:07:15to give you a hexadecimal number.
    • 0:07:19And any time you want to refer to a commit,
    • 0:07:21you can identify it, using this commit hash.
    • 0:07:25The normal directory structure on your local system, along with the files
    • 0:07:28it contains, as opposed to previous versions, is called a working copy.
    • 0:07:34The set of tracked changes that will be saved in the next commit
    • 0:07:37is called the staging area.
    • 0:07:41And so this is a diagram from another class called CS61.
    • 0:07:45And this gives you an example of what the repository contains.
    • 0:07:49It contains what's called the version repository, which
    • 0:07:53consists of all of the commits that you made previously,
    • 0:07:55so all of the previous versions of your codebase,
    • 0:07:57along with the version that you are working on right now,
    • 0:08:00called the working copy.
    • 0:08:04So I know these were a lot of terms just forced onto you,
    • 0:08:07but hopefully, this will be useful in understanding how Git works.
    • 0:08:12And we go through the details of how exactly to use Git next.
    • 0:08:21A quick note on the installation.
    • 0:08:23If you're using Codespaces, like you do for your CS50 problem sets,
    • 0:08:27then you don't actually have to install anything.
    • 0:08:29Git should come pre-installed.
    • 0:08:31If you do want to develop locally, then you can install it,
    • 0:08:35using this link on Windows.
    • 0:08:37Or in MacOS, it should probably be installed, but if it's not,
    • 0:08:40then you can run git --version and it should prompt the installation.
    • 0:08:44These links are in the slides, so you can definitely
    • 0:08:49download the slides from the CS50 website,
    • 0:08:51and you can download Git if you want to.
    • 0:08:57Now let's go on to the Git commands.
    • 0:09:02The first set of commands that are useful to know
    • 0:09:04are the getting-started commands.
    • 0:09:06So how do you get started with a Git repository?
    • 0:09:10There are a couple of ways.
    • 0:09:11And which one you use depends on whether you're
    • 0:09:13working with an existing repository that someone's already published,
    • 0:09:16or if you're creating a new code space completely from scratch.
    • 0:09:21For your final project, you probably will use the latter
    • 0:09:24because you will be starting a new project from scratch.
    • 0:09:27And in such cases, you will use the command, git init,
    • 0:09:31which means just initialize the folder that you're in right now
    • 0:09:34as a Git repository.
    • 0:09:36On the other hand, if you want to download an existing remote
    • 0:09:40repository-- for example, something that you found on GitHub for whatever
    • 0:09:43reason--
    • 0:09:44then you can use git clone.
    • 0:09:47I show you a demo of all of this at the end.
    • 0:09:49But the idea is to just copy the URL.
    • 0:09:52You git clone URL, and then it'll download the entire repository
    • 0:09:56and all of the files and directories into the folder
    • 0:09:58that you're in right now.
    • 0:10:04The next set of commands that we're going to go over
    • 0:10:07are for saving changes.
    • 0:10:09And these three commands, in my opinion, are by far the most important commands
    • 0:10:13in today's seminar.
    • 0:10:15So even if you don't get anything else out of this,
    • 0:10:17I want you to take back this one slide.
    • 0:10:20The first one is git add, which specifies which files to track.
    • 0:10:26And so it tracks these files by adding them to what we call the staging area.
    • 0:10:30And like we mentioned before, the staging area
    • 0:10:32is what controls the files and changes that will be saved in the next commit
    • 0:10:38that you make.
    • 0:10:41So you can specify, for example, git add hello.py, or git add mario.c.
    • 0:10:47And you can list out the files, separated by spaces,
    • 0:10:50and this will track those files by adding them to the staging area.
    • 0:10:55So the next commit that you make will then
    • 0:10:57save the changes that have been specified by git add.
    • 0:11:00So for example, if you change two files, but you only git added one file,
    • 0:11:05then only that one file will be saved in the next commit.
    • 0:11:08And so this is useful for specifying exactly what goes into each commit.
    • 0:11:12The second command for saving changes--
    • 0:11:14and this is, arguably, the most important--
    • 0:11:17is git commit, which actually creates the commit by saving the track
    • 0:11:21changes in the form of a commit.
    • 0:11:24The -m flag specifies a commit message, and so you
    • 0:11:27can say git commit, -m, and then whatever commit message
    • 0:11:31that specifies what changes you made.
    • 0:11:33So for example, this could be something like fix x bug,
    • 0:11:37or implement y feature, or something like that.
    • 0:11:43And finally, the last saving-changes command that you need to know
    • 0:11:47is git push.
    • 0:11:49So technically, git push is an optional command,
    • 0:11:53because if you're working entirely locally,
    • 0:11:55if you don't have a remote associated with your Git repository,
    • 0:11:58then you can absolutely just do git add and commit,
    • 0:12:01and everything will be saved in your device.
    • 0:12:04But if, for whatever reason, let's say, you want to collaborate with someone
    • 0:12:07and you want somebody else to have access to your git repository,
    • 0:12:12then you would add a remote, maybe on GitHub or something,
    • 0:12:16and push your commits, your changes, onto the remote repository.
    • 0:12:20And you would do that, using git push.
    • 0:12:27OK.
    • 0:12:28And if you have any questions, please send them in the chat, and Bernie
    • 0:12:31will stop and let me know if there are any questions.
    • 0:12:36Undoing changes.
    • 0:12:39The most important command for undoing changes
    • 0:12:41is git revert, which lets you undo a commit by essentially creating
    • 0:12:46a new commit that does exactly the opposite of what
    • 0:12:49the incorrect commit did.
    • 0:12:52So for example, if you decided to make some design changes to your web app
    • 0:12:57that you were building, and so you add a bunch of CSS,
    • 0:13:02maybe you create a new CSS file.
    • 0:13:03And you add a bunch of CSS that specifies the fonts, and the styles,
    • 0:13:06and the colors, and stuff like that.
    • 0:13:09But then you decide to talk about this design with the other people
    • 0:13:12in your group, and then you realize that, OK, maybe this
    • 0:13:16isn't the best way forward for your website.
    • 0:13:19And so you want to undo the changes.
    • 0:13:21So one way to undo it would be to manually go
    • 0:13:23back and see what changes you made, and then
    • 0:13:26manually delete those lines and each of the files that you made the changes in.
    • 0:13:29But the advantage of using Git is that, because each of these sets of changes
    • 0:13:33is stored in a commit, you can directly undo all of those changes
    • 0:13:37by just doing exactly the opposite of what that previous commit did.
    • 0:13:42Now, how do you specify this commit in the command?
    • 0:13:46So like I said earlier, each commit has associated with it
    • 0:13:50a commit hash, which is basically a big hexadecimal number.
    • 0:13:55And so you can specify this commit by using the commit hash.
    • 0:13:58In fact, you don't even need to specify the entire commit hash.
    • 0:14:01Usually, the first, say, five or six digits
    • 0:14:03will suffice, because that's enough to uniquely identify this commit.
    • 0:14:09You can also specify the commit by using the HEAD~n syntax.
    • 0:14:16HEAD represents the latest commit, so HEAD~n would be the nth last commit.
    • 0:14:21So let's say you wanted to get rid of the commit
    • 0:14:23that you did five commits ago.
    • 0:14:25Then you would just say HEAD~file.
    • 0:14:30And that's how you undo changes, using Git.
    • 0:14:35And there are some other general, useful commands-- git
    • 0:14:38status, which displays the state of the repository and the staging area, git
    • 0:14:42log, which displays a log of the previous commits in the currently
    • 0:14:45checked-out branch.
    • 0:14:46And we'll talk about branches in a bit, but just
    • 0:14:50think of this as a log of the previous commits that you made.
    • 0:14:54And finally, git diff displays the changes that you've made.
    • 0:14:57So for example, if you just do git diff, then it'll show you--
    • 0:15:01using the appropriate colors, green or red--
    • 0:15:05what changes that you've made since the last commit.
    • 0:15:08You can also specify the commit hashes of new commits
    • 0:15:12to ask for the changes between two commits.
    • 0:15:15So maybe you want to go back and look at what changes
    • 0:15:17that you made in a specific commit.
    • 0:15:19You just specify git diff, the first commit hash, the second commit hash,
    • 0:15:24and it'll show you whatever changes you made.
    • 0:15:28BERNIE LONGBOY: I'll go ahead and read a couple of questions, Tarun.
    • 0:15:32So first is, do I need to download anything on Mac to have Git?
    • 0:15:36Actually, you don't, correct?
    • 0:15:37Is that correct?
    • 0:15:38TARUN PRASAD: You don't need to download,
    • 0:15:40but you can double-check that you have it installed, using git --version.
    • 0:15:45So just run this in your command line, and it should probably say something
    • 0:15:48like Git Version 2.25 or something.
    • 0:15:51BERNIE LONGBOY: Yeah.
    • 0:15:52TARUN PRASAD: And--
    • 0:15:52BERNIE LONGBOY: And I think you answered this one,
    • 0:15:54but does GitHub count with a visual aid to understand
    • 0:15:56how many commits we're using?
    • 0:15:58I'm finding the timeline branches a little confusing.
    • 0:16:02TARUN PRASAD: Yeah.
    • 0:16:03I mean, both Git and GitHub do have a list of commits.
    • 0:16:10You can do this locally without even using GitHub, using git log.
    • 0:16:14And so that'll give you a list of the commits that you made,
    • 0:16:17along with a timestamp of when you made the commit, who made the commit,
    • 0:16:24and other information, what changes were actually made in that commit.
    • 0:16:28About branches, we will talk about that in about 5 or 10 minutes,
    • 0:16:31after this demo.
    • 0:16:32So hopefully, that will clear things up a little more.
    • 0:16:41BERNIE LONGBOY: OK.
    • 0:16:42Those were--
    • 0:16:44TARUN PRASAD: OK, awesome.
    • 0:16:45BERNIE LONGBOY: --good questions they had.
    • 0:16:46TARUN PRASAD: Yeah.
    • 0:16:47We will go ahead to a demo right now, so that I can just
    • 0:16:51show you the basics of what we covered.
    • 0:16:53And then we'll come back and talk a little bit more
    • 0:16:55about some of these commands.
    • 0:17:11OK.
    • 0:17:14So what I'm going to do here is, I am going
    • 0:17:16to create a new folder, which I will call Git Seminar.
    • 0:17:22This is just CS50 Codespaces, so feel free to pull it up and follow along,
    • 0:17:25if you like.
    • 0:17:27You may have to create this folder in the workspace directory,
    • 0:17:30so you might have to go up one directory to avoid
    • 0:17:34messing up CS50's own Git commands or the Git repositories that they have.
    • 0:17:41But feel free to follow along, if you'd like.
    • 0:17:44So I have what I call Git Seminar, so presumably,
    • 0:17:46you could be using this folder for keeping track of your final project.
    • 0:17:52Go ahead, whatever work that you do for your final project.
    • 0:17:56So let me cd and do git-seminar.
    • 0:17:59And let's see.
    • 0:18:01This is currently an empty folder.
    • 0:18:04So what I'm going to do now is, I'm going to create a file called hello.py
    • 0:18:08and open that up.
    • 0:18:11And let's say I do print Hello World.
    • 0:18:21So let's say this represents some set of initial changes
    • 0:18:24that I made to my codebase.
    • 0:18:26And now I realize, OK, this might be a good point
    • 0:18:28to stop and save my work, using a commit.
    • 0:18:32So right now, this codebase is just a directory.
    • 0:18:35It doesn't have a Git repository associated with it.
    • 0:18:38So how do I get started?
    • 0:18:40How do I begin by initializing this repository as a Git repository?
    • 0:18:50And feel free to send in what you think in the chat.
    • 0:18:53git init.
    • 0:18:53Yes.
    • 0:18:58OK.
    • 0:18:59So it says, initialized empty Git repository,
    • 0:19:02in the folder that I'm in right now.
    • 0:19:05So before I do anything else, let me just
    • 0:19:07run git status, which is one of the final commands that we saw.
    • 0:19:11And this tells me the status of the repository.
    • 0:19:14It says that there are no commits yet.
    • 0:19:16And there is one unchecked file called hello.py.
    • 0:19:21There's also nothing that's been added to the commit,
    • 0:19:23but untracked files are, in fact, present.
    • 0:19:28So now that I have this information, how do I begin by creating a commit?
    • 0:19:36What do I need to do to actually set up before I can create a commit?
    • 0:19:43And in fact, the git status output itself gives you some advice.
    • 0:19:47You can use git add.
    • 0:19:48Yes.
    • 0:19:49So I'm going to do git add.
    • 0:19:51Now, there are a couple of ways I can do this.
    • 0:19:53I could do git add hello.py to specify or delegate
    • 0:19:57that I want to track this one file called hello.py.
    • 0:20:01But very often, you might have made changes across multiple files,
    • 0:20:04and maybe you just want to track everything.
    • 0:20:06And so another thing that you could do is just
    • 0:20:08git add dot, which would add everything in the current folder.
    • 0:20:12Dot just refers to the current directory, the one
    • 0:20:14that you're in right now.
    • 0:20:15And so git add dot just adds everything in the current directory, all
    • 0:20:19the untracked changes, into the staging area.
    • 0:20:24Let me run git status again really quick.
    • 0:20:26There's still no commits, but now it is tracking this one file called hello.py.
    • 0:20:31And this is the change that will be committed in the next one.
    • 0:20:35And so like somebody sent in the chat, the next command
    • 0:20:37is just git commit -m, commit message.
    • 0:20:41And so let me say hi.
    • 0:20:45OK, and doing this commit then returns some output.
    • 0:20:50These few digits that you see over here are the first few digits
    • 0:20:54of the commit hash.
    • 0:20:57And you can see the commit message over here,
    • 0:20:59the author, and other information about what the changes you made were.
    • 0:21:07Let me run git log, just to show you what the output of this looks like.
    • 0:21:14Git log specifies a list of the previous commits that you made.
    • 0:21:18Right now, there exists only one commit, and this is the entire commit hash
    • 0:21:22of that commit that we just made.
    • 0:21:25This is the commit message, say hi.
    • 0:21:27And it also specifies the author, their email, the date, and so on.
    • 0:21:34OK.
    • 0:21:38So that hopefully gives you an idea of how to add in commit,
    • 0:21:42but now let me try the very last step of saving changes, which is git push.
    • 0:21:50But if I try to do that, it gives me an error.
    • 0:21:53It says, fatal.
    • 0:21:54No configured push destination.
    • 0:21:57Either specify the URL from the command line,
    • 0:21:59or configure a remote repository, using git remote add.
    • 0:22:03So the reason for this is that, so far, everything that we've done
    • 0:22:06lives entirely on our own device, on our local codebase.
    • 0:22:11So far, we haven't associated this with anything on GitHub at all.
    • 0:22:16And so what I'm going to do right now is exactly that.
    • 0:22:19I'm going to show you to create a GitHub repository
    • 0:22:21and then associate the two things so that whenever you make commits,
    • 0:22:25you can then push them to the remote repository.
    • 0:22:28The main advantage of doing this is that, one, if your own device crashes,
    • 0:22:33like if you're developing locally, but your device crashes--
    • 0:22:36maybe your hard drive fails--
    • 0:22:37you will still have a backup of everything stored on GitHub.
    • 0:22:41And perhaps more importantly, storing it on GitHub
    • 0:22:43will allow other people, maybe your team members, to look at it.
    • 0:22:48Or maybe if you're working on an open-source project, maybe somebody
    • 0:22:51else looking, Googling something, might end up on your repository
    • 0:22:54and may want to use your code, or download or contribute to it.
    • 0:23:01So how do we create a repository?
    • 0:23:05So just go on to GitHub.com, and again, feel free to follow along if you want.
    • 0:23:10You should see a New Repository button on the left sidebar, so just click
    • 0:23:15on that.
    • 0:23:20I can specify a repository name.
    • 0:23:21This can be anything.
    • 0:23:23In my case, I'm just going to call it git-seminar.
    • 0:23:26You can choose whether you want to release it publicly
    • 0:23:28or you want to keep it private.
    • 0:23:30I will choose private in this case.
    • 0:23:34And I'm going to leave all of this unchecked,
    • 0:23:36and I'm going to click Create Repository.
    • 0:23:42OK, so now it's created this repository.
    • 0:23:45You can look at the URL.
    • 0:23:47It has my username, followed by git-seminar.
    • 0:23:51And it also provides some setup commands,
    • 0:23:54which tell you how to link the two repositories together.
    • 0:23:58And again, there are a couple of ways of doing this, depending on
    • 0:24:01whether you're creating a new repository or linking an existing one.
    • 0:24:05In our case, we're just pushing an existing repository
    • 0:24:07from the command line because we already have a Git repository set up locally.
    • 0:24:12You would follow these commands if you wanted to start one from scratch,
    • 0:24:16but in our case, we just need to do these three things.
    • 0:24:20While you're doing this, make sure you choose the SSH
    • 0:24:22option if you set up with SSH, which most of you on Codespaces
    • 0:24:27probably have.
    • 0:24:31But the first command that you need to put in
    • 0:24:33is the command that adds this GitHub URL.
    • 0:24:39And let me paste that in here.
    • 0:24:45So it adds this remote, which I'm calling origin,
    • 0:24:49and it's linking it to this URL on GitHub,
    • 0:24:52github.com slash my username slash git-seminar.git.
    • 0:24:57So now the two repositories have been linked,
    • 0:25:00and now I can specify the name of the main branch.
    • 0:25:03And again, we'll talk about branches in a bit, so don't worry about this right
    • 0:25:06now.
    • 0:25:09And finally, I can do a git push.
    • 0:25:11Now, if I just do git push on its own, it again
    • 0:25:14will complain because GitHub doesn't already know
    • 0:25:18there exists this branch called main.
    • 0:25:20And so the very first time that you push,
    • 0:25:22you'll have to do the set-upstream flag.
    • 0:25:26You have to use the set-upstream flag.
    • 0:25:30And so I will copy that in, paste that in, and hit Enter.
    • 0:25:36And that's about it.
    • 0:25:38Once it's done pushing, it'll tell you that a new branch
    • 0:25:40has been created on GitHub.
    • 0:25:42And this branch has been set up to track this remote branch called main
    • 0:25:46from origin.
    • 0:25:47And again, origin is the name of the remote, which is the remote on GitHub.
    • 0:25:52So let me go back to the GitHub repository and refresh this page.
    • 0:25:59And now you can see that it looks more familiar, like something that most
    • 0:26:02GitHub repositories usually look like.
    • 0:26:04It gives you a list of whatever folders and files
    • 0:26:07that exist in your repository, along with the commit history.
    • 0:26:11And so clicking on one commit, for example, will show you
    • 0:26:14a list of commits that you made so far.
    • 0:26:17And you can then click on any specific commit
    • 0:26:19to have a visual representation of the changes that you made.
    • 0:26:22And in this case, the only change that I made
    • 0:26:24was to add this one line that says, print Hello World.
    • 0:26:29And now I can go back to Code.
    • 0:26:31I can also see I can open up any file and look at the existing
    • 0:26:35version of that file on GitHub.
    • 0:26:44OK.
    • 0:26:44Again, if you had any questions about that process,
    • 0:26:46feel free to send it in the chat, and we can go over it in more detail.
    • 0:26:51BERNIE LONGBOY: So Tarun, one of the questions early on was about--
    • 0:26:59although I believe one of our audience-- difference between GitHub and git
    • 0:27:04clone.
    • 0:27:06I think you might have mentioned that, if you want to just go over that again?
    • 0:27:09TARUN PRASAD: Yes.
    • 0:27:10So I guess I'll talk about the difference between Git and GitHub
    • 0:27:14first.
    • 0:27:15Git is a command line tool that lives entirely locally on your device,
    • 0:27:20or in this case, it's on Codespaces.
    • 0:27:23So Git is just the name of the command-line tool itself.
    • 0:27:27And GitHub is essentially the name of a website or a company
    • 0:27:31which provides some services, which lets you store these Git
    • 0:27:34repositories on their server.
    • 0:27:38And so when you do git clone, git clone is a very specific Git command
    • 0:27:43which lets you download an existing GitHub repository,
    • 0:27:47because GitHub repositories don't live on your device unless you created them.
    • 0:27:53So maybe if you wanted to look at the GitHub repository of a classmate,
    • 0:27:59maybe a classmate has been working on a personal project,
    • 0:28:03and maybe you want to check it out.
    • 0:28:04Maybe you want to look at the code.
    • 0:28:06So what you can do is then is go onto the GitHub.com link, the URL,
    • 0:28:11and then use git clone along with this URL.
    • 0:28:17So if you click on the green Code button on GitHub,
    • 0:28:19it'll specify a URL for the repository.
    • 0:28:23And again, it's preferable to use SSH.
    • 0:28:28And you can basically download this, using the command, git clone,
    • 0:28:31so git clone, followed by the URL.
    • 0:28:36BERNIE LONGBOY: OK.
    • 0:28:37Next question is from Daniel.
    • 0:28:39Just to be clear, the command line refers
    • 0:28:42to the Terminal on MacOS and PowerShell on Windows, correct?
    • 0:28:47TARUN PRASAD: Yes.
    • 0:28:48On Windows, you can use either PowerShell or Command Prompt.
    • 0:28:52But on Mac, it is the Terminal, yes.
    • 0:28:54BERNIE LONGBOY: OK.
    • 0:28:56And Amy asks, so will our files be saved on our computer and GitHub,
    • 0:29:00or only on GitHub?
    • 0:29:02TARUN PRASAD: Yes, that's a really good question.
    • 0:29:04And again, that brings up the distinction between using--
    • 0:29:06BERNIE LONGBOY: Local.
    • 0:29:07TARUN PRASAD: --git locally and pushing things to GitHub.
    • 0:29:11So as long as you just do git add and git commit and git add and git
    • 0:29:14commit and make changes, it's only going to be saved on your computer.
    • 0:29:17But as soon as you do git push, after you add the remote and the URL
    • 0:29:21and everything, then all of your changes are going to be pushed to GitHub.
    • 0:29:25And then it'll be stored on both the local device, your computer,
    • 0:29:29and on GitHub.
    • 0:29:31BERNIE LONGBOY: And then this question came up from Austin,
    • 0:29:35and I believe Anjalee also asked it.
    • 0:29:38Why SSH and not HTTPS?
    • 0:29:43TARUN PRASAD: Yeah, also a good question.
    • 0:29:45So far, I think GitHub has been allowing both HTTPS and SSH as possible ways
    • 0:29:52of downloading code and authenticating.
    • 0:29:55So essentially, they're both means of authenticating yourself
    • 0:29:57to allow you to, for example, push to a repository
    • 0:30:00or to download a repository and so on.
    • 0:30:03But recently, I think GitHub has decided for security reasons
    • 0:30:07to switch entirely to SSH.
    • 0:30:09It's supposed to be more secure than using HTTPS.
    • 0:30:14So that's the reason we're also pushing towards SSH these days as well.
    • 0:30:38OK.
    • 0:30:38If there are no other questions, we can continue.
    • 0:30:43BERNIE LONGBOY: Let's see.
    • 0:30:49What is SHH and HTTPS?
    • 0:30:55TARUN PRASAD: Yeah.
    • 0:30:56So SSH and HTTPS--
    • 0:30:58I might have mentioned this before--
    • 0:30:59are essentially ways of authenticating yourself.
    • 0:31:02And they specify different protocols for authentication
    • 0:31:07as well as downloading, and pushing forward, and so on.
    • 0:31:11BERNIE LONGBOY: And can we just take this last one,
    • 0:31:14and then we'll go into the next part?
    • 0:31:16And then I will come back to the questions again.
    • 0:31:19We could see your first line of code in the first commit.
    • 0:31:22Did you create the file with no code in it and pushed it,
    • 0:31:26or with the included line of code?
    • 0:31:29And that was--
    • 0:31:30TARUN PRASAD: So I--
    • 0:31:30BERNIE LONGBOY: --from Bruno.
    • 0:31:31TARUN PRASAD: Yeah.
    • 0:31:32I created the file, and then included the line of code,
    • 0:31:35and then pushed the two things together.
    • 0:31:38And so that was the order I did it in.
    • 0:31:40I created the file, included the line of code,
    • 0:31:43then did the whole git add, git commit, git push.
    • 0:31:46And then that change, the change where I essentially created the file
    • 0:31:50and added the line of code, was represented on GitHub.
    • 0:32:00BERNIE LONGBOY: OK, Tarun.
    • 0:32:04TARUN PRASAD: OK, awesome.
    • 0:32:06So let's go on to the next portion of today's seminar.
    • 0:32:10And this is the main portion which actually focuses on collaboration.
    • 0:32:15So so far, we've seen that we can save changes, and track changes, and undo
    • 0:32:20commits, revert changes, and so on.
    • 0:32:23And that's all well and good when you're the only person working
    • 0:32:26on your repository.
    • 0:32:27But in most of your projects, you're probably working with a partner
    • 0:32:30or with a team member.
    • 0:32:33And in such cases, it's very useful to know
    • 0:32:36of ways which will help you collaborate together,
    • 0:32:40pushing different code to different files,
    • 0:32:44so even modifying the same lines of code in different ways.
    • 0:32:49And Git allows you to do all of this in a very seamless way.
    • 0:32:53The first command that's very useful for this is git pull.
    • 0:32:57So git pull downloads changes and commits
    • 0:33:00that have been pushed by others to the remote,
    • 0:33:03and merges them into your own local repository.
    • 0:33:06And this is very useful when collaborating with others because you
    • 0:33:09won't be the only one pushing code.
    • 0:33:12So for example, let's say you're the one who did the git init,
    • 0:33:16you made some changes, you added the remote,
    • 0:33:19you created the GitHub repository, and you push all of your changes.
    • 0:33:23But in the meanwhile, let's say that your group member
    • 0:33:28decided to go onto your GitHub URL, your GitHub repository.
    • 0:33:33They decided to do a git clone, so they downloaded all of the files
    • 0:33:36that you pushed, and then they made their own changes.
    • 0:33:39And they also did the whole git add, git commit, git push,
    • 0:33:42and now their changes have also been pushed into the GitHub repository.
    • 0:33:47In such a case, GitHub knows about these changes because they pushed it.
    • 0:33:51But the local version of the code that lives in your device
    • 0:33:55or that lives on Codespaces doesn't know of those changes
    • 0:33:58because all of these changes are only on GitHub.
    • 0:34:02But how do you sync your version of the code, your local version of the code,
    • 0:34:06with the changes that have been pushed by others?
    • 0:34:08Well, you use git pull.
    • 0:34:11So what git pull does is it downloads all of these changes
    • 0:34:13and then merges them, adds those commits on top of whatever commits you already
    • 0:34:18made, and then merges them together.
    • 0:34:21So technically, git pull is actually a combination
    • 0:34:24of two other commands called a fetch and a merge.
    • 0:34:29We won't be talking about that in too much detail today,
    • 0:34:31but do feel free to look that up if you want to learn more about this.
    • 0:34:39OK, coming to possibly one of the more important topics and very useful topics
    • 0:34:43of today's seminar, branches.
    • 0:34:45And there were some questions earlier about branches as well,
    • 0:34:48so hopefully this will clear things up a little bit.
    • 0:34:52So what exactly are branches?
    • 0:34:55Like in the XKCD comic at the very beginning, it's really pretty simple.
    • 0:34:59Just think of branches as pointers to commits.
    • 0:35:04So what does that mean?
    • 0:35:05I think this illustration will help clear things up a little bit.
    • 0:35:09Each of these hexadecimal numbers that you see in these white boxes, each
    • 0:35:13of those represents a commit.
    • 0:35:15And each commit points to the previous one.
    • 0:35:19So maybe the 98ca9 commit was made first, and then the 34ac2 commit,
    • 0:35:24then f30ab, and then 87ab2.
    • 0:35:30But you also see these other red boxes, which point at commits.
    • 0:35:34And these red boxes are essentially what branches are.
    • 0:35:39In most cases, you'll have some default branch,
    • 0:35:42usually called something like main.
    • 0:35:44But you can also create other branches, which
    • 0:35:47will be very useful when testing experimental features
    • 0:35:50or when fixing a bug, because you don't want to mess up the main branch.
    • 0:35:54So for example, if you have a working version on your main branch, which
    • 0:35:58other people who are also working on this project are using,
    • 0:36:01then you don't want to push potentially buggy commits onto the main branch.
    • 0:36:07What you can do instead is create a separate branch.
    • 0:36:11I will see the commands to do that in a minute.
    • 0:36:13But you can create a separate branch, commit to that branch,
    • 0:36:18and then push those commits to that branch on GitHub.
    • 0:36:22And so the main default branch will be unaffected,
    • 0:36:25and anybody else can also clone the repository
    • 0:36:27and pull code and all of that onto their own main branch
    • 0:36:29without it affecting anything.
    • 0:36:31But then once you're completely done with your feature,
    • 0:36:34once you're sure that everything works in your feature branch,
    • 0:36:37then you can decide to merge it back into the main branch.
    • 0:36:41And in fact, this is a very common workflow, as we will see in a second
    • 0:36:44as well.
    • 0:36:46Any time you work on a big project, especially when
    • 0:36:48you're collaborating with many other people,
    • 0:36:50this is a very common workflow that you'll use.
    • 0:36:55Now, what are the actual commands to work with branches?
    • 0:37:00The first one that's very useful is, how do you create a branch.
    • 0:37:04So for example, let's say I want to create a branch called feature.
    • 0:37:09Then I can do that by running the command, git branch,
    • 0:37:13followed by feature or whatever branch name you want to specify.
    • 0:37:18So git branch feature creates that branch
    • 0:37:21and makes the branch point to the commit that you're at right now.
    • 0:37:26So for example, let's say that the latest commit
    • 0:37:29that I made was this f30ab commit.
    • 0:37:33And that's what main is pointing at because that's
    • 0:37:36where the main branch was.
    • 0:37:38But now, if I create a new branch by using git branch feature,
    • 0:37:42then feature will also point to f30ab over here.
    • 0:37:50But any further commits that I make will be associated
    • 0:37:53with the main branch and not the feature branch,
    • 0:37:55because git branch doesn't actually change or switch
    • 0:37:57which branch you're in right now.
    • 0:38:00If you do want to switch the branch as well,
    • 0:38:02then you use what's called git checkout, so git checkout with the -b flag,
    • 0:38:06followed by the branch name.
    • 0:38:08-b just specifies that you're creating a new branch.
    • 0:38:14So git checkout, -b, followed by feature, and that'll do the same thing,
    • 0:38:18but also, any further commits that you make
    • 0:38:19will be associated with the feature branch and not the main branch.
    • 0:38:24Once you've created a branch, each time you create a new commit,
    • 0:38:29the pointer will also advance, along with the commits themselves,
    • 0:38:33the pointer of whatever branch that you're in right now.
    • 0:38:37So for example, if I'm in the feature branch
    • 0:38:39and it's pointing to the f30ab commit, then creating a new commit
    • 0:38:43will essentially result in what it looks like right now.
    • 0:38:46It'll create this 87ab2 commit, and then it'll also move the feature branch
    • 0:38:50to point at the latest commit.
    • 0:38:53Now, notice that the main branch pointer doesn't actually move,
    • 0:38:56and that's because you're not in the main branch.
    • 0:38:58And so if you go back and look at the main branch,
    • 0:39:00it'll still look exactly like what the repository looked like when you last
    • 0:39:06made the f30ab commit.
    • 0:39:08And so the changes in this last 87ab2 commit
    • 0:39:10will not actually be reflected in the main branch,
    • 0:39:12and that's exactly what we want because we don't want to mess with the working
    • 0:39:16version of the code in the main branch.
    • 0:39:23You can also switch between branches, using just git checkout
    • 0:39:25without the -b flag.
    • 0:39:28And you can just do git checkout, followed by the branch name,
    • 0:39:30and that'll change the branch you're in right now.
    • 0:39:34You can also push a new branch to GitHub,
    • 0:39:38and we saw this earlier with the main branch.
    • 0:39:42But the way you do it the very first time
    • 0:39:44is, you use this -u or this set-upstream flag,
    • 0:39:47which tells GitHub that a new branch is coming in.
    • 0:39:51And so you can use git push, -u, origin space, the branch name.
    • 0:39:57So hopefully that makes sense, but again, we'll
    • 0:39:59see a demo of this in a bit.
    • 0:40:06This is a term that you would have heard of very often,
    • 0:40:08any time you look at a GitHub repository,
    • 0:40:10or maybe if you've done an internship in the past, or something like that,
    • 0:40:15pull requests.
    • 0:40:17So pull requests are not a Git feature, which
    • 0:40:20means they're not something that you would work with on the command line.
    • 0:40:24But rather, they're a feature that's specific to GitHub, but very useful
    • 0:40:27in collaborative repositories.
    • 0:40:30And so other remote providers like GitLab or Bitbucket
    • 0:40:34might also have analogous features, but possibly with different names.
    • 0:40:37I think GitLab calls it a merge request.
    • 0:40:42So a pull request is essentially a request to merge in the changes
    • 0:40:46that you've pushed to a branch back into the main branch, or any other branch,
    • 0:40:50but usually the main branch.
    • 0:40:53So for example, once you've completed the changes
    • 0:40:57that you want to make in your feature branch,
    • 0:40:59you can push your feature branch, then go into GitHub,
    • 0:41:03and you'll see a Pull Request tab.
    • 0:41:04And over there, you can click on the Create Pull Request button,
    • 0:41:08and then choose which branch you are merging from
    • 0:41:11and which branch you're merging into.
    • 0:41:13And then what that will do is it'll create a request
    • 0:41:16to merge those changes in.
    • 0:41:18And so a very common workflow when working in a group
    • 0:41:21is to always commit to a feature branch and never directly to main,
    • 0:41:24and then to push the branch to the remote, open up a request,
    • 0:41:27have somebody else in the team review the pull request,
    • 0:41:30and either approve it or request changes.
    • 0:41:33And then once the changes have been approved,
    • 0:41:35you can then merge it into main, and you can usually do this directly
    • 0:41:38on GitHub itself.
    • 0:41:42And again, we'll see how exactly to do that in a minute.
    • 0:41:48BERNIE LONGBOY: Tarun, is this a good break to take--
    • 0:41:50TARUN PRASAD: Yeah.
    • 0:41:50BERNIE LONGBOY: --a couple of questions from the audience?
    • 0:41:52TARUN PRASAD: Yeah, we can take--
    • 0:41:53BERNIE LONGBOY: OK.
    • 0:41:54TARUN PRASAD: --those questions.
    • 0:41:54BERNIE LONGBOY: All right.
    • 0:41:55So, our fantastic audience, I did not forget you here.
    • 0:41:59So I am going now to--
    • 0:42:03let's see.
    • 0:42:05I think, Leo, we answered yours.
    • 0:42:07Bruno.
    • 0:42:09This question comes from Bruno.
    • 0:42:10I'm trying to use Git in VS Code, but it appears you
    • 0:42:14are in a repository managed by CS50.
    • 0:42:16Git is disabled.
    • 0:42:18So that's not really a question, but the more I think,
    • 0:42:21is that problem still going on?
    • 0:42:24TARUN PRASAD: Yes.
    • 0:42:24If you face that, one thing that I would suggest is just going up one folder,
    • 0:42:27so maybe using cd..
    • 0:42:31And then you'll be in your workspaces folder.
    • 0:42:34And then you can essentially create a new folder altogether,
    • 0:42:37so make something else, like make the project or something.
    • 0:42:41BERNIE LONGBOY: This is--
    • 0:42:42TARUN PRASAD: And once--
    • 0:42:42BERNIE LONGBOY: --something else--
    • 0:42:42TARUN PRASAD: --you do that--
    • 0:42:43BERNIE LONGBOY: --that our students always--
    • 0:42:44so it's common, common.
    • 0:42:47TARUN PRASAD: Yeah.
    • 0:42:49BERNIE LONGBOY: OK.
    • 0:42:50Let's see.
    • 0:42:51What else do we have here?
    • 0:42:55Let's see.
    • 0:42:56From Leo, so is commit 87ab2 just a copy of f30ab
    • 0:43:02to create a new branch with feature, or are they
    • 0:43:06actually based on different versions?
    • 0:43:09TARUN PRASAD: Yeah, good question.
    • 0:43:11So let me go back to that slide.
    • 0:43:15So when you create a new branch, there are no new commits that are created.
    • 0:43:19So the first time that you create the feature branch,
    • 0:43:21it will still point only at the f30ab, and this 87ab2 commit
    • 0:43:26doesn't exist yet.
    • 0:43:28What happens is that if you're on the feature branch,
    • 0:43:31and you then do a new commit, like you actually make some changes
    • 0:43:37and you actually do git commit, that's when
    • 0:43:39this 87ab2 commit might be created.
    • 0:43:42And then the feature branch moves forward
    • 0:43:44to point at that commit instead of the original commit.
    • 0:43:48BERNIE LONGBOY: OK, and this one is just a good one to probably clarify, Tarun.
    • 0:43:55I did it in a direct message, but it's probably good for the entire audience
    • 0:43:59to know. git clone is a part of GitHub.
    • 0:44:05I believe the question was, do we require an account on git clone,
    • 0:44:09like we need a GitHub account, or we are just using it online?
    • 0:44:14So it's really the same account, but I'll let Tarun go ahead
    • 0:44:18and maybe further elaborate on that one.
    • 0:44:22TARUN PRASAD: Yeah.
    • 0:44:22If I understood that question correctly, you
    • 0:44:26don't generally need a GitHub account to do a git clone.
    • 0:44:31You should be able to usually just do git clone if it's
    • 0:44:35a public, open-source repository.
    • 0:44:38But you may need a GitHub account if you want
    • 0:44:40to clone a private repository that only you have access to.
    • 0:44:44Maybe if it's a repository that your project partner created and you decided
    • 0:44:47to make it private, then you would need to log in, authenticate using GitHub,
    • 0:44:54and then once you do that, you can then do git clone, whatever URL,
    • 0:44:58and that should download everything.
    • 0:45:02Let me know if I didn't answer the question correctly,
    • 0:45:05but I will try again.
    • 0:45:12BERNIE LONGBOY: This question is from Sarah.
    • 0:45:15Actually, she asks, could you please repeat what branches do?
    • 0:45:19TARUN PRASAD: Yes, of course.
    • 0:45:21Branches are one of the more confusing features in Git.
    • 0:45:25So branches, again, are essentially pointers to commits,
    • 0:45:29and the point of using branches is to separate different things
    • 0:45:35that you're working on currently.
    • 0:45:37So for example, let's say that, simultaneously, you
    • 0:45:40have some existing working version of your entire codebase.
    • 0:45:45So let's say you're working on a web app,
    • 0:45:46and you have some preliminary version ready to go
    • 0:45:49and working on the main branch.
    • 0:45:51And you're afraid that any time you push some
    • 0:45:53commits to that, you might mess it up, things might stop working,
    • 0:45:57and so don't want to push anything to the main default branch.
    • 0:46:00So what you can do to get past this is, essentially, create a new branch
    • 0:46:08and do all of your work in this experimental branch.
    • 0:46:11So think of this as sort of copy-pasting your entire codebase in a completely
    • 0:46:16different directory and just messing with whatever
    • 0:46:21changes that you want to make, whatever box you want to fix in the copied,
    • 0:46:25duplicate version.
    • 0:46:26And then, once everything is working, then
    • 0:46:28you go back to your original directory and copy over the changes.
    • 0:46:31That's essentially what you're doing with the branches workflow.
    • 0:46:35BERNIE LONGBOY: And just to keep things moving forward,
    • 0:46:37I just want to reiterate that we will have a recording available,
    • 0:46:41so the questions that were answered previously.
    • 0:46:45And let's see.
    • 0:46:50Let's see.
    • 0:46:51Oh, thanks, Anais.
    • 0:46:52She just put in a great resource there.
    • 0:46:55OK.
    • 0:46:57Tarun, do you want to continue?
    • 0:46:58We're in our last--
    • 0:46:59TARUN PRASAD: Yeah.
    • 0:47:00BERNIE LONGBOY: --few minutes here.
    • 0:47:01TARUN PRASAD: Thank you.
    • 0:47:01We have about 10 minutes left.
    • 0:47:06So I'll talk through this very quickly, but because this
    • 0:47:09is something that many people often have trouble working
    • 0:47:12with when they're first doing Git.
    • 0:47:14So usually, when you try to pull code or try
    • 0:47:17to merge in one branch with another, it will work completely fine,
    • 0:47:20especially if the changes are in completely different portions
    • 0:47:24of the codebase.
    • 0:47:25They're completely different files, for example.
    • 0:47:27But occasionally, you'll encounter that you've
    • 0:47:30made some changes to a specific file, but maybe somebody else
    • 0:47:34has also made some different changes with the same lines in those files,
    • 0:47:37but in some sort of a different way.
    • 0:47:40So Git in such cases won't know how to automatically pull the code
    • 0:47:43or to automatically merge them.
    • 0:47:45And this results in what's called a merge conflict.
    • 0:47:49So this is a code sample from, I believe, CS61.
    • 0:47:53CS61 also has a very useful Git tutorial available
    • 0:47:56online, so you should definitely check that out, if you can.
    • 0:47:58And this is a code sample from there.
    • 0:48:00And you can see that there are two very similar lines over here.
    • 0:48:04This pointers of i equals malloc of i or 1,
    • 0:48:08and pointers i equals malloc of i plus 1.
    • 0:48:12So in particular, the version of the code between these left-angle brackets
    • 0:48:17and the equals is one version.
    • 0:48:20And the incoming version is what's between the equals
    • 0:48:22and the right-angle bracket, so essentially between these two lines
    • 0:48:25and between these two lines.
    • 0:48:28And so when you encounter a merge conflict,
    • 0:48:30it will essentially insert these angle brackets and equals
    • 0:48:33lines into whatever files have those merge conflicts.
    • 0:48:36And then it's up to you to manually resolve them.
    • 0:48:40And how you do that is actually very simple.
    • 0:48:41You just get rid of these three lines, these three angle-bracket, equals,
    • 0:48:45angle-bracket lines.
    • 0:48:46And then you decide which of the two versions of the code to keep,
    • 0:48:50or in some cases, you might want to merge them together
    • 0:48:52in some more elaborate way.
    • 0:48:54And this is usually a good point to talk to the other person who
    • 0:48:57made the other changes and decide, OK, how exactly should we merge these two
    • 0:49:01changes together, like why did you make those changes,
    • 0:49:03why did I make those changes.
    • 0:49:05Maybe the actual one we want is some sort of a combination of the two.
    • 0:49:13And if you're using an editor like VS Code or Codespaces on the browser,
    • 0:49:16then it should also have very convenient graphical UI
    • 0:49:19elements that make this even easier.
    • 0:49:22So it'll show you the changes, using the appropriate colors, green or red,
    • 0:49:26and then you can choose one or the other, depending on which one you want.
    • 0:49:30And once the conflicts have been resolved,
    • 0:49:34just commit your resolved changes, using git commit as usual.
    • 0:49:39OK.
    • 0:49:40Let's very quickly go through a quick demo of this workflow
    • 0:49:44as well, just so we know what it looks like.
    • 0:49:47So let's say, hypothetically, I'm going to clear the commands.
    • 0:49:53So let's say that I'm not the person who made the original commits,
    • 0:49:56and maybe I'm somebody else in the same group.
    • 0:50:01So maybe I just did a git clone.
    • 0:50:02Maybe I just downloaded the entire codebase.
    • 0:50:05Maybe I do a git log to see the status right now.
    • 0:50:08I see that it's exactly one commit.
    • 0:50:11So let's say that I want to push another commit.
    • 0:50:15So let's, for example, make some changes here.
    • 0:50:20Before I do that, I don't want to push these changes to the main branch.
    • 0:50:24And so what I want to do instead is make the changes to some different branch.
    • 0:50:31So let's say I do git checkout -b, followed by whatever branch name.
    • 0:50:37In my case, I'm going to call the branch name add-comments.
    • 0:50:44So I switched to a new branch called add-comments, and maybe the changes
    • 0:50:47that I want to make involve just adding a comment.
    • 0:50:49So maybe I say, say hello.
    • 0:50:53And now let me run git status, just to show you what the status is right now.
    • 0:50:59So now I'm on branch add-comments, not on branch main.
    • 0:51:04And again, I have this modified file, hello.py.
    • 0:51:06I can do a git add.
    • 0:51:08I can do a git commit with some commit message, maybe add a comment.
    • 0:51:14OK.
    • 0:51:15And then, finally, I can do a git push.
    • 0:51:18Now, when I do a git push, again, it's going to give me an error.
    • 0:51:20It says, no, you'll have to do the set-upstream flag,
    • 0:51:23so I will use that flag and push it to GitHub.
    • 0:51:33So let me quickly go into GitHub, and I see here itself,
    • 0:51:36add-comments had recent pushes less than a minute ago.
    • 0:51:40And on GitHub, it also prompts me to compare create a pull request.
    • 0:51:44And that is what I want to do in this case, so let me go ahead
    • 0:51:47and click on this.
    • 0:51:52So I can open a pull request, which is basically a request
    • 0:51:56to merge in the changes in this branch called add-comments back
    • 0:51:59into the main branch.
    • 0:52:01And it says that this is able to merge.
    • 0:52:03These branches can be automatically merged, which
    • 0:52:05means there are no merge conflicts.
    • 0:52:07And on GitHub, I can specify a title.
    • 0:52:10I can specify any comments, if I have any.
    • 0:52:13And then I can create a pull request.
    • 0:52:17Once I do that-- and this might seem familiar if you've seen your feedback
    • 0:52:21pull requests in problem sets, because those use pull requests as well--
    • 0:52:26I can see in this pull request a list of the commits that
    • 0:52:29will be merged into the main branch when the merge happens.
    • 0:52:32And I can also see the changes that have been made.
    • 0:52:35In this case, there's only one change, the line
    • 0:52:38highlighted in green, which just adds this comment, saying, say hello.
    • 0:52:44Now, hypothetically, I could assign a reviewer for this pull request.
    • 0:52:48So maybe I want my team members to go through this code
    • 0:52:51and make sure that everything looks good before it gets merged back
    • 0:52:54into the main branch.
    • 0:52:56So if somebody else is also in your group,
    • 0:52:58you can specify their GitHub username over here.
    • 0:53:01You can ask them to review it.
    • 0:53:03And once everything has been reviewed, once everything looks good,
    • 0:53:07once you've tested everything and it's good to go,
    • 0:53:10you can then click on the Merge Pull Request button.
    • 0:53:13And you can optionally add a comment, and you can confirm merge.
    • 0:53:19So pull request successfully merged and closed.
    • 0:53:21The add-comments branch can be safely deleted.
    • 0:53:24So now you no longer need this pointer because the main branch
    • 0:53:27contains these commits that you added to this add-comments branch.
    • 0:53:32So I can safely delete this branch, and now if I go back into my main branch
    • 0:53:37and click on hello.py, I will see the changes over here.
    • 0:53:42Now, of course, you don't have to go through this entire process of creating
    • 0:53:45branches and pull requests and so on.
    • 0:53:47You could technically just directly push everything to the main branch.
    • 0:53:51But the reason we encourage doing this is just
    • 0:53:53to ensure that everybody on the team knows exactly what's going on.
    • 0:53:58And you also have this whole process of code review,
    • 0:54:00where different people look at the code and make sure
    • 0:54:03that everything is good to go before you merge it into the main branch, which
    • 0:54:06contains the working version.
    • 0:54:09BERNIE LONGBOY: OK, and Tarun, we're in our last four minutes
    • 0:54:14here, so if we have other questions or comments.
    • 0:54:23Here's one from Jim.
    • 0:54:24If a merge is done to the main branch and a bug is discovered later,
    • 0:54:29what is the best way to handle the bug fix?
    • 0:54:33TARUN PRASAD: Yeah, that's a really good question.
    • 0:54:36So there are a few ways of handling bug fixes.
    • 0:54:41If it's something that you want to undo, like maybe it's one very specific buggy
    • 0:54:46commit that you want to undo, you can then
    • 0:54:48use git revert, like we saw earlier.
    • 0:54:50You can do git revert, followed by the commit hash of the buggy commit.
    • 0:54:55And then you can then push those changes back into the main branch.
    • 0:55:00If it's more detailed than that, maybe it's more specific.
    • 0:55:04Maybe a bunch of commits are all buggy, or maybe you
    • 0:55:08want to completely get rid of the history
    • 0:55:10of the existence of that commit itself.
    • 0:55:12There are ways of doing that as well, which we don't quite have time
    • 0:55:16to go through now, but I'll just send over a couple of commands
    • 0:55:19that you can look at, that you can definitely look up,
    • 0:55:27and you can learn more about exactly how to work with these.
    • 0:55:30Two of them that'll be very useful include git reset and git rebase
    • 0:55:34-i, which is something called an interactive rebase.
    • 0:55:37And yeah, those should help you learn more about this.
    • 0:55:42BERNIE LONGBOY: What are your thoughts on GitHub Desktop App?
    • 0:55:46TARUN PRASAD: That's also a good question.
    • 0:55:49Lots of people find it very useful, especially when
    • 0:55:51you first start using or learning Git.
    • 0:55:55I personally wouldn't recommend it, just because I
    • 0:55:57think it's very useful to learn the commands themselves,
    • 0:56:00because that's what lets you understand, or it gives you
    • 0:56:05the full power of what Git can do.
    • 0:56:07But having said that, you can definitely download GitHub Desktop
    • 0:56:10and use that for making a lot of this easier, because then you
    • 0:56:13don't have to remember the commands.
    • 0:56:14You can just click on the Add button and the Commit button,
    • 0:56:17and that definitely makes things easier.
    • 0:56:19BERNIE LONGBOY: OK, last two.
    • 0:56:21One's a comment, and a question.
    • 0:56:23Is it considered best practice to--
    • 0:56:26oops.
    • 0:56:27Is it considered best practice to make our comments in code
    • 0:56:30and pull merge requests in present tense, rather than past tense, i.e.
    • 0:56:36add a comment versus added a comment?
    • 0:56:39TARUN PRASAD: Yeah, also a really good question, and different people
    • 0:56:41have very different conventions for this.
    • 0:56:44I personally use present tense, like add a comment,
    • 0:56:48because one way of thinking about commits is,
    • 0:56:51rather than what you did in the past, you
    • 0:56:53can think of a commit as what are the changes that will
    • 0:56:56be made when you apply this commit.
    • 0:56:58So when I apply this commit, it adds this comment,
    • 0:57:01and so you can write the message in present tense.
    • 0:57:04But of course, different people have very different opinions on this,
    • 0:57:07and there's no one right answer.
    • 0:57:09BERNIE LONGBOY: Thanks, Tarun.
    • 0:57:10TARUN PRASAD: Yeah.
    • 0:57:11Thank you all for coming.
  • 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