Placeholder Image

字幕列表 影片播放

  • COLTON OGDEN: All right.

  • Hello, Twitch.

  • My name is Colton Ogden and I'm joined today by Kareem Zidane.

  • Kareem, want to introduce yourself?

  • KAREEM ZIDANE: Yeah, hi, everyone.

  • My name is Kareem ZIdane.

  • I am a preceptor here at Harvard.

  • I work here with CS50, mostly doing software development stuff,

  • DevOps stuff, system administration.

  • COLTON OGDEN: Nice.

  • And some folks refer to you as Kareem the dream, is this correct?

  • Shout out to Spencer [INAUDIBLE].

  • KAREEM ZIDANE: [INAUDIBLE] yes.

  • COLTON OGDEN: Today we're doing the Kareem the dream stream.

  • KAREEM ZIDANE: OK, I did not see that coming.

  • COLTON OGDEN: And what are we talking about today on the stream?

  • KAREEM ZIDANE: We are going to be exploring a little bit

  • of the basics of git and GitHub.

  • COLTON OGDEN: OK, nice, nice.

  • For folks unfamiliar, what is git and GitHub sort of in a sentence or two?

  • KAREEM ZIDANE: So git is a distributed version control system, also known

  • as source control system, and git is usually

  • used to track changes in files and directory structures of our project.

  • And you can imagine this is quite handy for us developers

  • because we tend to do a lot of changes.

  • We always add features, fix bugs, refactor, improve stuff, and so on.

  • So you can imagine this gets quite handy to keep track of these changes,

  • be able to revert back to some of them, be able to build on top of them.

  • Git also stores these changes really efficiently.

  • It only stores the things that are necessary in this case,

  • so we don't have to worry about duplicating the whole codebase that we

  • have or duplicating all the files in our product.

  • It only stores the files that changed.

  • Another cool feature of git is that it also

  • allows us to work on different parts of the project, at once if you want to

  • or different features at once.

  • And this is also quite handy because, you can imagine,

  • we try to experiment with something or fix a bug or try to add a feature,

  • and we're not really sure that that's going to work out well or not.

  • So git really makes it easy as well to do this kind of thing.

  • And lastly, git also allows us to collaborate with other people

  • pretty easily when used, in particular, with a hosting service like GitHub.

  • COLTON OGDEN: Sure.

  • And I know we use GitHub all the time in CS50.

  • But for folks unfamiliar, do we want to show them what GitHub looks like

  • and maybe just give a couple of sentences of what GitHub itself is?

  • I'm going to pull up our other view here just so we can see.

  • That's actually your-- that is your computer?

  • KAREEM ZIDANE: That's my computer here.

  • COLTON OGDEN: Perfect.

  • KAREEM ZIDANE: And this is how GitHub looks like.

  • GitHub is a hosting service.

  • We're going to talk a little bit about GitHub later,

  • but this is what GitHub looks like.

  • If you don't really have a GitHub account

  • you should probably go ahead and create one.

  • Let me sign out of mine here.

  • And if the internet helps, we go to github.com/join you should be able

  • to create a new account if you don't have one.

  • COLTON OGDEN: OK.

  • And so git is what we use at the command line or whatever.

  • The actual tool.

  • And then GitHub is where we can push our code

  • and store it and let other people see it and work on it, right?

  • KAREEM ZIDANE: True.

  • We're going to discuss this in a bit more detail later on.

  • Git, yes, is mainly a command line tool, but it also

  • has graphical user interfaces if you'd like to use a graphical user interface.

  • I personally use it on the command line, which is easier for me.

  • But you can definitely download a graphical user interface for it

  • and use it.

  • COLTON OGDEN: OK, cool.

  • Well, let's get started.

  • KAREEM ZIDANE: So the first thing that we need to do

  • is, of course, get git installed.

  • COLTON OGDEN: Hi, Kareem and Colton.

  • Hi, Elias.

  • Good to see you again from Morocco.

  • KAREEM ZIDANE: Thank you so much.

  • COLTON OGDEN: Why don't you read--

  • I can't see what the--

  • it's in blue text.

  • Irene says-- why don't you read Irene's message there too?

  • KAREEM ZIDANE: If I'm not mistaken, if I recall correctly,

  • her name should be pronounced as I-re-neh.

  • COLTON OGDEN: Oh, I-re-neh.

  • KAREEM ZIDANE: Yeah, but maybe--

  • please correct me if I'm wrong.

  • COLTON OGDEN: TIL.

  • KAREEM ZIDANE: This is really exciting for me

  • as well because this is actually my first ever livestream.

  • I've never been on a livestream before, so this is exclusive to you, Colton.

  • COLTON OGDEN: Oh, yeah.

  • This is true.

  • Irene basically said, Kareem the dream stream on screen.

  • KAREEM ZIDANE: Oh, my god.

  • COLTON OGDEN: I'm just really building it up.

  • KAREEM ZIDANE: Why did you start this?

  • COLTON OGDEN: Hi, Kareem, good to see you here.

  • Hi, Colton.

  • Hi, Irene.

  • Good to see you.

  • Or I-re-neh, if Kareem's pronunciation is correct.

  • KAREEM ZIDANE: Yup.

  • COLTON OGDEN: OK, somebody from Egypt.

  • KAREEM ZIDANE: Oh, cool.

  • Great, Hi, good to see you.

  • I can't see the username quite well.

  • [INAUDIBLE] I think I know.

  • I think I know him.

  • [? Muhammad ?] [INAUDIBLE].

  • All right, that's great.

  • Hello from Spain.

  • We have different people from all around the world.

  • COLTON OGDEN: And [INAUDIBLE] is as regular as well.

  • He's been on the game [INAUDIBLE].

  • Good to see you.

  • Thanks for coming in again today.

  • All right.

  • KAREEM ZIDANE: So the first thing that we

  • need to do in this case is, of course, download and install git.

  • Git has installers for at least Mac OS, Windows, and Linux.

  • I'm going to be using the Linux, specifically Ubuntu 18.10.

  • I don't know.

  • Maybe 18.10.

  • I don't think it should make a difference how you install git

  • on this, on Ubuntu in general.

  • So the first thing that you need to do, if you haven't done this already,

  • is to download and install git.

  • Maybe follow the documentation here on how to do that.

  • In my case, I'm just going to apt-get update to make sure that I have

  • the latest--

  • to make sure that my package manager knows about the latest versions

  • of packages that are available.

  • apt-get install git.

  • This is how I think you would install git on Linux.

  • Yes, I'm sure I want to install all these dependencies, excuse me.

  • And once this is done to verify that git is installed,

  • you can just to git --version and it should tell you that you have git.

  • COLTON OGDEN: By the way, just included the chat box.

  • We ere missing the chat box there in the video.

  • KAREEM ZIDANE: OK, that's great.

  • So now that we have git installed, the first thing that we want to do

  • is create a git repository or initialize a git repository to be specific.

  • And I think there are two cases here.

  • The first case is you are starting from scratch

  • and you have an empty directory.

  • Let's call this project or my project or whatever.

  • And you can just go inside of this directory using the cd command.

  • And the way to initialize this git repository or project--

  • or in other words say, hey, git, I want you

  • to track the changes in this project--

  • is by running git init.

  • And git should reply, initializing the git repository in root,

  • workspace, the path to your project.

  • and then creates this .git directory that we're not going to really worry

  • about it too much for now.

  • But this is how we initialize a git project.

  • This should work pretty much the same if you already

  • have a project in this case.

  • So let me try to remove this project first, and I do have a thing froshims.

  • I'm going to use David's froshims example from lecture.

  • So I'm just going to copy this recursively here.

  • Now I'm going to get in it to initialize this project.

  • And now we have git tracking this project or this folder.

  • A question that you would find yourself asking pretty frequently

  • is hey, git, what's the status of this project.

  • What changed, what didn't change, and so on?

  • COLTON OGDEN: I lose track, definitely, all the time if I'm making changes

  • to files over and over again.

  • KAREEM ZIDANE: Yeah.

  • So the way to do this is actually literally by running git status.

  • And in this case, git you tell us what changed and what not in this case.

  • COLTON OGDEN: So if we installed git, we run git init first,

  • which basically says, OK, this is a new git project.

  • I want to be able to start tracking the files.

  • And then, once I start editing, then it can call git status

  • and then that will show me basically what I've made changes to.

  • KAREEM ZIDANE: Yeah, you can pretty much run git status at any point.

  • You don't have to make a change.

  • You can just [INAUDIBLE].

  • I run git status all the time to see if I made a change or not at some point.

  • COLTON OGDEN: Sure.

  • We've got a couple of messages in the chat.

  • It says I-re-neh--

  • I got to get used to pronouncing that.

  • Kareem pronounced it perfectly, I-re-neh,

  • but I'm using the English pronunciation too.

  • I'll try to remember that.

  • It's going to take me a little bit of breaking the habit.

  • And then, [INAUDIBLE] says we can use the [INAUDIBLE] IDE

  • and not worry about the installation process.

  • That's true, right?

  • KAREEM ZIDANE: Yeah, that's a great point.

  • Git is already preinstalled inside of the CS50 IDE,

  • so if you want to get started right away without having

  • to worry about installing this, you can just go to CS50 and login

  • into your workspace.

  • COLTON OGDEN: And [INAUDIBLE] I think is maybe alluding to the same thing.

  • He says, glad to be here.

  • Downloaded it, yet to install on Windows 10.

  • He opened the IDE for now.

  • So I think maybe he's saying he wasn't able to get it all working on Windows

  • 10 and he's using the CS50 IDE.

  • KAREEM ZIDANE: Yeah, that's great.

  • If you want to follow along right now and you don't have it installed,

  • feel free, of course, to log into your CS50 IDE

  • and you should have git installed there.

  • COLTON OGDEN: OK, cool.

  • So we talked about installing it, we talked about git init

  • and then git status.

  • So now that we be able to track, I'm guessing it's a--

  • KAREEM ZIDANE: So the first thing that I wanted

  • to explain before we go deeper into this is

  • to understand the difference between these three main parts.

  • Can we see all this?

  • COLTON OGDEN: I think we can switch to--

  • oh, I don't know if we have just a--

  • I can move us.

  • I can move us.

  • KAREEM ZIDANE: I can also resize my window [INAUDIBLE]..

  • COLTON OGDEN: Let me go to the editor and then just do a little bit of this.

  • Just move us right off screen.

  • And then I'll move the chat box as well.

  • Let's try that.

  • KAREEM ZIDANE: OK.

  • This sounds great.

  • So this image is from the official git documentation,

  • and it shows us the difference between three areas or three

  • states in which the files can be in.

  • The first one of them on the left is the working directory,

  • and this is pretty much our folder where we make changes to our file.

  • There is a second place called the staging area,

  • or the index as it's sometimes called, and this

  • is where we say mark these changes.

  • Mark these changes to be committed in the next commit, or save these changes

  • or mark them.

  • Hey, I'm going to save a snapshot of this when I do [INAUDIBLE] next time.

  • And then finally, we have the git repository

  • is where we have these changes actually saved.

  • So it's important to understand the difference between these three areas.

  • So once again, just quickly to recap.

  • Working directory is where we have our files, where we modify our files when

  • we work on our project.

  • Staging area is where we mark changes, and the git repository

  • is where our changes are saved.

  • COLTON OGDEN: So we stage the files but they're not actually saved--

  • git's not saving them permanently.

  • It's kind of like I'm putting down some files to potentially save later

  • as being part of my .git folder.

  • KAREEM ZIDANE: Correct.

  • Yes.

  • And in this case, I think one of the things that this allows us to do

  • is make a whole bunch of changes and only save actually some of them

  • in history.

  • I forgot to mention this, but git keeps track of changes

  • by means of taking snapshots of your project, every time you do git commits,

  • as we'll see soon.

  • So in this case, we could have a bunch of changes

  • and we only want to save some of them in history.

  • In this case, we only stage these changes and then commit them.

  • COLTON OGDEN: OK, cool.

  • That makes sense.

  • KAREEM ZIDANE: All right.

  • COLTON OGDEN: Do you want me to move us back into the view?

  • KAREEM ZIDANE: Actually, let's actually look at this first

  • as well because it's also important to understand some of this.

  • You might have noticed earlier when I did git status, git said that hey, I

  • have these untracked files right here.

  • COLTON OGDEN: And so those are files that were in the folder already.

  • And then you called git init and then it was

  • able to recognize, oh, there's some files in there

  • that I'm not actually tracking yet.

  • KAREEM ZIDANE: Correct.

  • So these are files that exist in your git repository, or project--

  • we're just going to start calling it repository now--

  • that git knows they're there but it doesn't track them.

  • COLTON OGDEN: So it scans the folder and says,

  • oh, I don't actually have a reference to these files yet.

  • KAREEM ZIDANE: Right.

  • COLTON OGDEN: But in case you want to add them or you want to stage them,

  • here they are.

  • KAREEM ZIDANE: That's exactly right.

  • The second state in which a file can be in is unmodified, and in this case,

  • it's not showing in the git status because this is a file

  • that we pretty much didn't touch.

  • The copy that we have is exactly the same as the one in the repository.

  • COLTON OGDEN: But that's a file that we previously were tracking

  • and it's saying, oh, you haven't changed this since the last time you tracked--

  • the last time you basically did whatever.

  • Committed it or whatnot.

  • KAREEM ZIDANE: That's true.

  • And third, we have modified.

  • And these are files that we made some changes to them.

  • So modified files.

  • We're going to see some of these.

  • And lastly, we have staged, and these are

  • the files that are in the index area or the staging area in this case.

  • COLTON OGDEN: OK, that makes sense.

  • KAREEM ZIDANE: It would be useful to get this visualization in mind

  • before we start working with things.

  • So in this case, I have these untracked files,

  • or specifically I have an untracked file in an untracked folder in this case.

  • The first thing that I want to do before committing them or saving them

  • in the history is add them to the staging area.

  • COLTON OGDEN: He's got a question.

  • KAREEM ZIDANE: Yeah.

  • COLTON OGDEN: [INAUDIBLE] says, staged is in our terminal, right?

  • KAREEM ZIDANE: So git takes care of all this.

  • You don't have to work on a terminal to have these three areas.

  • This is how git works.

  • So this is not related to what environment you're using to access git.

  • If that answered the question.

  • COLTON OGDEN: It makes sense.

  • That would bring us back into the view here.

  • KAREEM ZIDANE: OK, there we are.

  • Perfect.

  • So the first thing that I want to do is presumably run git add,

  • but the problem is git seems to be complaining.

  • Nothing specified, nothing added, so it seems that I need to specify something.

  • And I could definitely git add application.py,

  • or maybe add templates, or do git add application.py on its own line,

  • and then git add templates in its own line.

  • But the good thing is that there is actually

  • a command line option that allows me to add everything that's

  • changed or untracked in this case.

  • And I only know this by looking at the documentation.

  • If you do git help add--

  • whoops.

  • Actually, man git add, is it?

  • OK, so we don't have man installed, so let me show you on my own terminal.

  • So if you do git help add, assuming you installed all of git,

  • you're going to see this manual page.

  • And it lists what the command does and how

  • to use it with the different options and how these options change

  • the behavior of this command.

  • In this case, I'm really looking to add all the files in this case,

  • and if I keep searching I can find a- or --all dash in this case.

  • So it seems to me that if we do git add --all, that would add everything.

  • We see nothing, which is good.

  • Previously we saw a complaint.

  • So if we do git status again, now we see these files in green.

  • COLTON OGDEN: So now they've gone from the untracked and now they're in the--

  • KAREEM ZIDANE: Staging area.

  • COLTON OGDEN: --staging areas.

  • They're not part of the unmodified because they're new files,

  • but they are being staged.

  • KAREEM ZIDANE: So now they've gone from the working directory, to be specific,

  • to the staging area.

  • COLTON OGDEN: They basically skipped a couple of those steps of the diagram

  • effectively.

  • KAREEM ZIDANE: So we're referring to the first diagram here in this case.

  • So right now they were in working the working directory in this case.

  • Actually, I'm not really sure if they would

  • be considered part of the working directory

  • if they are initially untracked.

  • But yes, OK, let's say they are in the working directory.

  • And once we git add them, they move to the staging area in this case.

  • COLTON OGDEN: Sure.

  • I guess I was looking more to that second diagram.

  • KAREEM ZIDANE: So the second diagram is more about this thing on the left here.

  • So this said, new file.

  • Previously, it said that this file was untracked,

  • or actually, it probably showed it up here.

  • So these are changes to be committed in the staging area,

  • and it's saying that, hey, all of these are new files.

  • We're going to see when it's going to show modified--

  • it's probably going to show it like here on the left instead of new file.

  • COLTON OGDEN: So we can use git add and then the name of the file

  • that we want to add, and this is a file that we aren't tracking yet.

  • Or we can do git add --all and it will just

  • add everything that's untracked in the current directory?

  • KAREEM ZIDANE: Yes, but I believe everything that's untracked or modified

  • in your working directory.

  • COLTON OGDEN: OK.

  • KAREEM ZIDANE: It's going to add it.

  • COLTON OGDEN: Gotcha.

  • KAREEM ZIDANE: But again, you can always add specific things.

  • So if you just want to add certain untracked files or certain modified

  • files only, you can just do that.

  • In this case, we just want to add everything so we did that.

  • And the next thing is--

  • do you recall what the next step is?

  • COLTON OGDEN: Well I know that when I have a file that I've just added

  • and I want to get it ready to push to GitHub and I want to stage it,

  • I usually use git commit, the function git commit.

  • KAREEM ZIDANE: That's exactly right.

  • So now I want to tell git, hey, git, save this

  • as a snapshot in my repository or as a commit in my repository.

  • COLTON OGDEN: Sure.

  • It's kind of like taking a picture of all the files in their current state

  • that you can then maybe recollect or pull back from GitHub or from someone

  • else's computer in the future.

  • [INAUDIBLE]

  • KAREEM ZIDANE: Yeah, in this case, we don't really

  • have any connection with GitHub yet, but yes, this saves--

  • this is actually a perfect analogy.

  • It saves a picture of the state of your project or repository

  • right now that we can use later in any number of ways.

  • COLTON OGDEN: GeekUSA says, hi.

  • Hi, GeekUSA.

  • Good to have you with us.

  • KAREEM ZIDANE: OK, so git commit.

  • And again, git seems to be complaining about lots of stuff here.

  • Particularly, it tries to tell me, hey, you want to set your email

  • and name all of these information.

  • So the thing is here that git doesn't only keep track of files

  • and what changed and what not.

  • Git also keeps track of information about who

  • changed these files, which you can imagine this is also useful in case

  • we're working on a big project--

  • that we are 10 or maybe 100 developers working on the same project.

  • You want to check which developer changed this particular part

  • or added this particular part.

  • COLTON OGDEN: Who to blame for a broken piece of source code.

  • KAREEM ZIDANE: There is actually git blame command that does this.

  • So who to blame.

  • If you just want to maybe email them and ask them about something

  • or insult them maybe--

  • I don't know-- in case you don't like the changes.

  • Please don't do that.

  • COLTON OGDEN: [INAUDIBLE] question.

  • Maybe you want to read it off there.

  • KAREEM ZIDANE: Sure.

  • If you have lots of files, for example 100 files, and we want to add only 98

  • of them, in this case git add will add all the files.

  • This isn't what we want.

  • And adding every file separately with git add filename with this,

  • it will be hard to do git filename 100 times.

  • This is actually a great point.

  • I don't really see a use case where you'd

  • have 100 files in the same directory and 98 of them you want to add

  • and two you don't want add.

  • But the good thing is that you can actually--

  • if you don't want to group these files under one directory

  • and add this as a directory, one thing you can do

  • is use some of bash features, which is the shell that we're using here,

  • to actually specify certain patterns for files to add.

  • So for example, I could tell git, hey, git, git add

  • all the files that start with the prefix foo, for example.

  • COLTON OGDEN: [INAUDIBLE] foo star.

  • KAREEM ZIDANE: Yeah, exactly.

  • Git add foo star.

  • You can really play with this logic and customize it however

  • you want to fit your use case.

  • COLTON OGDEN: So it's kind of on the developer at that point

  • to be smart about making sure all the files start with some common identifier

  • or have a common file type, file suffix.

  • KAREEM ZIDANE: That's exactly right.

  • Yeah, I personally imagine it's going to be a pain

  • to have to manually add like 100 files, of course.

  • So maybe there is some criteria that you can just match all these files with

  • and it should be pretty easy to use this criteria to select these

  • or to add these to the staging area.

  • COLTON OGDEN: Make sense.

  • [INAUDIBLE] has a question as well.

  • Can I get some link of the project for testing?

  • Do you have this project public [INAUDIBLE] by chance?

  • KAREEM ZIDANE: So we haven't pushed this to GitHub yet.

  • We're going to push it at a later point.

  • And I am probably going to also zip all the source code that we're using here

  • and maybe upload it if you want.

  • The point is, you can work on any project you want.

  • I don't really see anything necessary about using

  • this specific project because I'm literally starting from scratch.

  • COLTON OGDEN: Cool.

  • Makes sense.

  • Yeah, definitely follow along using the same commands as Kareem does.

  • And you can even just put in your own dummy files, right?

  • More or less works.

  • KAREEM ZIDANE: Yeah, exactly.

  • But these are a little tweaked versions from the froshims example from

  • David's lecture, which I believe you can find on cdncs50.net/2018 actually,

  • [INAUDIBLE] lectures seven.

  • COLTON OGDEN: So you're getting partially cut off too.

  • I don't know if you want to maybe come a little bit more this way [INAUDIBLE]

  • KAREEM ZIDANE: --seven.

  • I think--

  • COLTON OGDEN: Move your chair a little bit.

  • KAREEM ZIDANE: Oh, sorry.

  • COLTON OGDEN: No, you're good.

  • There we go.

  • KAREEM ZIDANE: So if you're curious about using some of these,

  • there are these and there are many other source code

  • examples from lectures that you could download and use.

  • This is part of what I'm using, or I'm using part of this actually.

  • So we missed the--

  • COLTON OGDEN: Right.

  • We were going to talk about git commit because we have the untracked files

  • and we've added them with git add --all.

  • And so the next stage, like you said, we're going to take a snapshot--

  • basically the directory as it is right now.

  • KAREEM ZIDANE: Correct.

  • We need to save the changes that we have into the repository in this case,

  • but before we do that, we need to tell git who we are.

  • And in this case, specifically, we should at least

  • configure the email it seems and the name.

  • So I'm going to do exactly that.

  • And notice that git is really helpful in giving me the exact commands that I

  • need to use, so I can just copy these.

  • In this case, I'm just going to specify an email.

  • [INAUDIBLE] cs50.harvard.edu.

  • OK, perfect.

  • And then, actually, no, the other one-- git config --global user.name.

  • And notice you have to specify quotes if your name has special characters just

  • to make sure that it gets it right.

  • So I just configured my email.

  • I just configured my name.

  • It's a little bit ugly because it splits on two different lines, but that's OK.

  • And now, maybe I should try to do a git commit again.

  • And this is actually a text editor that I see open right now.

  • It's Vim, if you're familiar.

  • And git is basically telling me, hey, what did you change?

  • I need a description of the changes that you just made.

  • And this is--

  • COLTON OGDEN: And they'll be able to tell which snapshot is which

  • if you're doing 50 a day.

  • KAREEM ZIDANE: Yeah, exactly.

  • You need to be able to--

  • if you're looking at the commit history or the log, as we will soon see,

  • you're going to see a bunch of different comments.

  • And it would be really useful to see, just

  • by a quick look, what this commit did.

  • COLTON OGDEN: Sure.

  • That makes sense.

  • KAREEM ZIDANE: In this case, you should ideally be more descriptive,

  • but I'm just going to say first commit.

  • This is my first commit.

  • And save.

  • This is how you in Vim if you're curious.

  • And exit.

  • And now it tells me that, hey, I had to five

  • files and all these different information

  • about the modes for the files.

  • We don't really have to go into these details right now.

  • This is permissions of the files and so on, but it seems to have worked.

  • COLTON OGDEN: Looks like [INAUDIBLE] has a question for you as well.

  • KAREEM ZIDANE: Sure.

  • So what's the difference between add and commit?

  • That's a great question.

  • Add marks the changes that we have as changes

  • that we want to commit when we do git commit next, if that makes sense.

  • So the staging area is an intermediate step

  • where we mark all the things that we want to save in history

  • permanently before actually saving them in history, if that makes sense.

  • COLTON OGDEN: Cool, and commit actually is

  • like taking the picture of the directory and saving that so that we can then

  • look at it later and figure out what our repo look like in the past

  • and then revert back.

  • KAREEM ZIDANE: Yes, that's exactly what commit does.

  • Commit looks at the staged changes, in this case that we added by git add,

  • and then takes all of them and saves them permanently in history.

  • COLTON OGDEN: Cool, makes sense.

  • KAREEM ZIDANE: Hey, do you have more questions?

  • OK, perfect.

  • What do we want to do next?

  • COLTON OGDEN: So we've committed everything, right?

  • KAREEM ZIDANE: Yup.

  • COLTON OGDEN: So now everything is I guessed saved,

  • so if we did it again we'd have two snapshots.

  • If we did it again we'd have three snapshots.

  • I guess then it'd be a matter of demonstrating either maybe

  • how we go back to a snapshot or maybe how we'd publish it.

  • KAREEM ZIDANE: So for that, I think we need more than one snapshot

  • or more than one commit to be able to go back to the previous commit.

  • Right now we just have one of them, so this

  • is going to be a little bit tricky because essentially we tell git

  • in this case, hey, forget everything.

  • We didn't do anything.

  • But we will actually demonstrate this later.

  • One thing you might be interested in is looking actually at the commit history

  • so far.

  • COLTON OGDEN: Sure, yes.

  • KAREEM ZIDANE: So one way we can do this is

  • using the git log command in this case.

  • COLTON OGDEN: Right, OK.

  • KAREEM ZIDANE: And it shows this long, weird yellow--

  • COLTON OGDEN: Hide the chat there just for a second

  • so we can see the full thing.

  • KAREEM ZIDANE: All right.

  • So we see this first line this weird, long string,

  • and this is actually an identifier for this commit.

  • It's a hash generated using an algorithm--

  • I think it's SHA-1--

  • that actually uniquely identifies this commit.

  • And we could actually use this hash to refer to the commit later.

  • COLTON OGDEN: [INAUDIBLE] has your author information that you

  • put in that git config command as well.

  • KAREEM ZIDANE: Exactly, yes.

  • So [INAUDIBLE] as the author.

  • It says this is my email.

  • It also lists the date and the time in which

  • these changes happened, and of course, the commit message in the end.

  • COLTON OGDEN: That seems super useful.

  • KAREEM ZIDANE: So let's actually make some changes.

  • So I have all this right now, so let me actually--

  • I have changes that I pulled from lecture from before.

  • So let me actually copy from source froshims1, I believe.

  • Everything here into this directory.

  • So you can simulate this by essentially opening your file

  • and making actual changes.

  • In this case, I actually copied files that are

  • different into my current directory.

  • I didn't show you what application.py was initially, so we should probably

  • take a look at this.

  • And we're going to learn about this command later,

  • but let's get clean here.

  • git checkout application.py.

  • COLTON OGDEN: So what does git clean do?

  • KAREEM ZIDANE: This is discard any untracked files in my working area.

  • We're going to explain this later.

  • I just want to show you first what application.py

  • looks like in our previous one.

  • So if we do git log again, this is the only commit that we have.

  • And if you do git status nothing's changed.

  • So I'm opening application.py now and here's what I have.

  • And this is not really about code specifics,

  • so we can not really care much about this.

  • But here's a file.

  • COLTON OGDEN: Just a super simple flask app

  • KAREEM ZIDANE: Super simple flask app that

  • expects to git parameter, [INAUDIBLE] in this case,

  • and renders a template called failure.html if you don't provide

  • any of these or render success instead.

  • So again, not really interesting in this case.

  • I'm going to copy updated application.py from froshims1.

  • And again, you don't have to copy stuff.

  • You can do this directly in application.py in this case

  • if you just copy everything in this directory in here.

  • If I do git status now, now it shows that application.py is modified,

  • and it shows a new untracked file, templates/register.html in this case.

  • So one question that might come to mind here

  • is what changed about application.py?

  • And the way we can do this is literally doing git diff application.py.

  • And you can see this nice diff view provided

  • by git coloring the lines that were removed in red

  • and putting a minus in front of them.

  • And the lines that were added in green and putting a plus in front of them.

  • In this case, I specifically changed the first line, the importing stuff,

  • added this array.

  • I'm just scrolling down.

  • Added a few variables and added a function.

  • COLTON OGDEN: So this is froshim0 before,

  • and then you copied froshim1 and overrode it

  • and now it's showing you the changes?

  • KAREEM ZIDANE: Yup.

  • This might be a little bit confusing.

  • I could have done exactly the same thing by actually opening

  • the application.py in this directory and making the changes to it.

  • I'm probably going to do this next time.

  • But in the meantime, we just changed the application.py and git showed me

  • that application.py was modified.

  • And when I did git diff application.py it showed me what actually changed.

  • COLTON OGDEN: OK.

  • [INAUDIBLE] the green lines are something that you added to the file,

  • and then red ones are ones that you deleted from the file,

  • or changed in that file, right?

  • KAREEM ZIDANE: Correct.

  • COLTON OGDEN: OK, makes sense.

  • It's like a nice visual indicator of the changes

  • that you made if you're exactly sure and you're only at the command line.

  • And there's other tools.

  • GitHub will show you differently, right?

  • KAREEM ZIDANE: Correct.

  • It's actually going to show a pretty similar view to this.

  • I'm not really sure if you can show the diff side by side here.

  • GitHub does allow you to show the diff side by side.

  • There might be a way to do it using git.

  • I'd need to look at the documentation for this,

  • but this is what you see when you do git diff.

  • COLTON OGDEN: Some text editors even now, like VSCode and Atom,

  • will show you embedded GitHub views so you can see which files are changed.

  • Usually they'll have changed being blue and then

  • they'll have deleted lines being red and new lines being green.

  • So even text editor's now have built in git integration, which is really cool.

  • KAREEM ZIDANE: Yeah, I'm sure text editors

  • and IDEs, if they don't even have this as a built in feature

  • I'm sure there's some extension or plug-in that adds this feature.

  • But in case you're not using a text editor

  • that supports this, or you just want to work directly from the command line,

  • here's how you do it.

  • COLTON OGDEN: Awesome.

  • Looks really cool.

  • KAREEM ZIDANE: Notice if we do git diff as well.

  • It still shows us the changes only in application.py

  • and not anything about templates register.html, which if you recall,

  • was [INAUDIBLE] untracked file.

  • And this is because it's literally untracked.

  • It doesn't know anything about it yet.

  • COLTON OGDEN: It doesn't have a prior history

  • snapshot or whatever to compare the new one to tell you what's changed.

  • KAREEM ZIDANE: Correct, exactly.

  • So again, the way we add these--

  • suppose we are ready now and we we'd like to commit all these changes

  • or save them in our repository.

  • The way we do this is running git add --l

  • or in short -A. If I do git status again, it shows me that both files are

  • staged.

  • One of them is actually modified and one of them is a new file.

  • COLTON OGDEN: Yeah, it'll tell you, actually,

  • whether you haven't tracked it before at all so you can say,

  • oh, this is the file that I changed and this is a completely new file.

  • KAREEM ZIDANE: Correct.

  • COLTON OGDEN: So it's kind of nice.

  • It gives you that feedback there.

  • KAREEM ZIDANE: The good thing is when we did git diff earlier,

  • it actually compared the changes in our working directory

  • to the changes that are saved in a repository, if I remember.

  • When we saw this nice diff screen, it was actually

  • comparing the application.py that were saved in the repository against mine

  • in the working directory.

  • COLTON OGDEN: Right, because it had that snapshot from before,

  • and it saves that in the .git folder, right?

  • KAREEM ZIDANE: Yes.

  • Now if you do git diff, it's not going to show you anything.

  • COLTON OGDEN: Interesting.

  • KAREEM ZIDANE: And this might be a little bit confusing,

  • but this is because by default, git diff compares the changes in your working

  • directory to the changes in the staging area

  • or through the repository if there are no changes in the staging area,

  • I think.

  • So the way to compare the changes in the staging area

  • to the repository, if you want, is by running git diff --cached or staged.

  • COLTON OGDEN: OK, that makes sense.

  • KAREEM ZIDANE: And also, I know this only by looking at the documentation.

  • There is no way that I could have known this.

  • COLTON OGDEN: It says we didn't commit those files.

  • There was no history so it had no diff information to give us, basically.

  • The files that we have now.

  • KAREEM ZIDANE: Yes.

  • In this case, I'm comparing the changes that

  • are marked as saved in my staging area, or marked as

  • to be committed in my staging area, to actually the snapshot that's

  • in the repository, if that makes sense.

  • COLTON OGDEN: [INAUDIBLE] has another question as well.

  • KAREEM ZIDANE: Sure, let's take that first.

  • So we add a file, make changes, and then commit.

  • Slightly inaccurate.

  • We make changes, add the file, and then commit, and it gets updated on GitHub.

  • We haven't gotten yet to the GitHub point,

  • but we're going to discuss this pretty soon.

  • But I hope I made these two points clear.

  • COLTON OGDEN: And GitHub is kind of like--

  • it doesn't have to necessarily go on GitHub.

  • There's other places, other websites that git can push too.

  • KAREEM ZIDANE: Yeah.

  • So I mentioned in the beginning that git is a distributed version control

  • system, and what distributed really means

  • is that if you're more than one developer working

  • on a particular project, then each of you

  • is going to have a copy of the project.

  • And it's like history [INAUDIBLE].

  • Previously, if you're familiar with other version control systems

  • like Apache Subversion, SVN for short, that

  • was actually a centralized version control system.

  • Which means there was actually one copy on the server,

  • and all these developers interacting with this copy

  • are just maintaining references to the files and changes in this copy.

  • And you can imagine one side of this is that if you're offline then

  • you're disconnected.

  • There's no way you can commit changes.

  • In case of git, that's not the case.

  • Git is distributed so each one of us is going

  • to have a copy of the whole project plus the history,

  • so we can just work completely offline without needing

  • GitHub or any other service.

  • COLTON OGDEN: And so a company using Subversion, if their server goes down

  • everybody is kind of screwed, right?

  • KAREEM ZIDANE: Yeah, I'm not sure many companies use Subversion right now,

  • but yes, that was I think one downside.

  • I'm not an expert in Subversion myself.

  • I've just used it very, very briefly.

  • COLTON OGDEN: So the principle is, if you and I have the same project

  • and we both have a copy of it, if your laptop gets wiped you can at least get

  • the copy off of my computer because I've maintained

  • all the references through all the snapshots that have ever taken place up

  • until the point that I cloned the copy on my computer.

  • KAREEM ZIDANE: Correct.

  • COLTON OGDEN: --copy it onto my computer.

  • KAREEM ZIDANE: Or even better, if we have a third party service like GitHub

  • or Bitbucket or any number of other services,

  • I can just fetch a copy from this service immediately as we'll see.

  • COLTON OGDEN: And even if GitHub goes down,

  • because thousands or even millions of people

  • have cloned some big projects or any project,

  • they can just re-upload it to GitHub.

  • Any one person can upload that project at the point that they cloned it

  • and just refresh them.

  • KAREEM ZIDANE: Well, if GitHub goes down and lost data

  • that's a bigger issue at this point.

  • Essentially, yes.

  • COLTON OGDEN: It's kind of a safe I guess.

  • KAREEM ZIDANE: You just want to make me go to you to get the copy anyway.

  • Sure, I can do that.

  • All right, do we have other questions?

  • COLTON OGDEN: I'm bringing the chat back because I realized it's not [INAUDIBLE]

  • little to--

  • KAREEM ZIDANE: Do you want me to get this closer to you maybe?

  • COLTON OGDEN: No, that's fine.

  • I can read it pretty well from there.

  • KAREEM ZIDANE: All right.

  • COLTON OGDEN: Here we go.

  • We got a question from [INAUDIBLE] or [INAUDIBLE]..

  • GitHub is equal to Bitbucket if you put double equals, not triple equals.

  • In JavaScript, I believe that's like type equivalence, the type

  • equivalence operator.

  • So equal but not quite equal.

  • KAREEM ZIDANE: I guess that's true-ish.

  • I mean, GitHub might have features that Bitbucket doesn't have

  • and the opposite, so it's not necessarily

  • that they're all equivalent.

  • You just want to do a little bit of research

  • and see which one would be best for you.

  • COLTON OGDEN: So can we see the changes other developers are making when

  • they make changes to the same file?

  • KAREEM ZIDANE: We will get to that, yes.

  • COLTON OGDEN: Awesome.

  • KAREEM ZIDANE: But good point.

  • So now, once again, we ran git diff --cached.

  • This could also, I believe, be --staged.

  • Yep, it's going to show me the same thing,

  • and it's going to compare the changes that I have in my staging area

  • right now to the repository.

  • And notice now that it's actually also listing

  • information about templates/registered.

  • Previously it didn't show anything when you just did git diff

  • and it was in the working directory.

  • And this is because now it is in the staging area.

  • So it's a new file added to the staging area,

  • and it shows what this new file adds to your repository in this case--

  • COLTON OGDEN: Nice.

  • KAREEM ZIDANE: --which is all--

  • COLTON OGDEN: What command did you run to put it in the staging area again?

  • KAREEM ZIDANE: Git add.

  • COLTON OGDEN: OK, [INAUDIBLE].

  • KAREEM ZIDANE: --all or -a.

  • COLTON OGDEN: I know plenty about git, however

  • I want to get better at two things--

  • solving merge conflicts and knowing how to remove a commit for a certain file

  • that you have accidentally committed to be pushed to a repo.

  • How can I do that?

  • KAREEM ZIDANE: These are two great questions.

  • We're going to answer them pretty soon when we get to branches and merging.

  • But long story short, the way you resolve git merge conflicts usually

  • is by literally opening the file that has a merge conflicts

  • and removing some symbols from it and removing

  • the snippets that you don't want in it.

  • And just to clarify a little bit, a merge conflict

  • happens when you and I are working on the same file potentially

  • and we modify the same line or same lines in two different commits

  • and then we try to merge these changes back together.

  • The problem is when you merge these changes,

  • git doesn't know do you need your changes or my changes?

  • And so we have to resolve these manually.

  • COLTON OGDEN: Rather than flipping a coin.

  • KAREEM ZIDANE: Exactly, yes.

  • So we're going to get to that.

  • Hopefully we remember these two questions to answer them

  • when we get to git merging.

  • Now that I have these, I can commit them.

  • And previously, I just did git commit and open a text editor.

  • For me, the good thing is that you can just

  • pass a commit message on the command line

  • by specifying -m and then the commit message.

  • So in this case, I added a students' list.

  • So this is an example of a commit message.

  • It should be short and descriptive.

  • I believe it shouldn't be--

  • theoretically I think it can be longer than that,

  • but I think the good practice is that it shouldn't be longer

  • than 50-ish characters.

  • But if you find yourself wanting to add more details,

  • then you can just do git commit, get back to the text editor view,

  • add a short description on the first line, and then a couple of lines

  • later you can just add a more detailed description

  • if that's something that you want.

  • So in this case, I'm just going to commit the changes.

  • Git is going to tell me what changed briefly.

  • So just to verify, I'm going to do git log again,

  • and now I see these two comments.

  • COLTON OGDEN: Nice. and it shows the most recent one it looks like on top.

  • So at a glance you can see immediately what the most recent commit was.

  • KAREEM ZIDANE: Yeah.

  • COLTON OGDEN: [INAUDIBLE] says, all we're doing

  • is staying between our PC and GitHub as in the staging area?

  • KAREEM ZIDANE: Not quite.

  • So still we have no connection to GitHub whatsoever.

  • All these three areas are areas that are used by git completely locally when

  • you're working within your project.

  • It just uses it to separate between the different things that we talked about.

  • So nothing that has to do with GitHub at this point yet.

  • All right, so we see our git log.

  • We verified that our latest commit got added.

  • One thing you might be wondering at this point, hey,

  • what if I made a stupid change to a file?

  • I just added foo to application.py here.

  • I should have probably done this using text editor.

  • But I just added a stupid line here.

  • COLTON OGDEN: Would love to have you do a Linux terminal command

  • tutorial as well for people.

  • KAREEM ZIDANE: We probably should.

  • So if you do git status, we can see that application.py changed,

  • and then if you do git diff, or git diff application.py in this case,

  • it's just going to show me, hey, this line

  • got added and here's the line that got added.

  • But suppose I don't want to do this.

  • Suppose I want to discard this change.

  • One way I can do this is using git checkout, so I can do git checkout

  • and then dash dash, and then the filename-- in this case,

  • application.py.

  • And then I hit Enter.

  • If I do git status again nothing changed.

  • My working directory matches what's in the repository right now.

  • And if I open the file again, scroll back to the bottom,

  • I don't see my line anymore.

  • COLTON OGDEN: So git checkout just erases any changes that you've staged?

  • KAREEM ZIDANE: Correct.

  • Yes, discards the changes in this case.

  • COLTON OGDEN: OK, cool.

  • That makes sense.

  • Looks like Andre from Facebook is in the chat, if you want to read his question.

  • KAREEM ZIDANE: Sure.

  • Hi, Kareem.

  • Great to see you.

  • Thank you.

  • Great seeing you here too.

  • Is there a way to avoid merge conflict symbols being

  • entered into a file that's been automatically generated?

  • Removing merge conflicts from auto generated XML can be quite tedious.

  • Is there a way around this?

  • I'm not really sure if there is a way to remove these symbols

  • or even to change them.

  • What I do know, though, is that I know there

  • are merge tools that exist that you could use that would help make

  • the merging process easier for you.

  • And I also know that there are certain command line

  • options that you could use to tell Git, hey, Git, use the changes from x

  • or use the change from y and don't care about the other changes

  • if a merge conflict happens.

  • COLTON OGDEN: Makes sense.

  • KAREEM ZIDANE: I hope that answered your question,

  • but I should probably look into this more.

  • COLTON OGDEN: [INAUDIBLE] has a question, or a statement.

  • Git checkout can be dangerous, meaning it will erase all your work and cannot

  • be recovered.

  • KAREEM ZIDANE: That's true.

  • So you want to be careful when using git checkout.

  • That's a good point actually, unless you preserve the history in some other way.

  • For example, if you're text editor preserves history

  • then they could be recoverable in this case.

  • But otherwise, you want to be careful using this

  • because you could literally lose the work that you did.

  • And this is why, actually-- this is a good point.

  • This is why committing changes frequently

  • is a good idea because you can just pretty easily revert back

  • to the previous version.

  • OK, what else do we have here?

  • So you have a bunch of things, actually.

  • You said this is going to take longer and it seems to be taking longer.

  • But what if I change my mind?

  • What if I want to do something like, hey,

  • update the commit message of the last commit in this case?

  • And so one way to do this is using git commit --amend -m,

  • and again, I know this by looking at the documentation.

  • And then mention the new commit message.

  • New commit message.

  • Of course, it should be more descriptive than this.

  • COLTON OGDEN: I actually didn't know that was a thing.

  • This is the first brand new thing that I've seen so far.

  • Git commit amend.

  • KAREEM ZIDANE: So if you do git log, in this case you

  • can see that the new message is now new commit message,

  • instead of added students.

  • COLTON OGDEN: OK, that's awesome.

  • I might actually start using that if I screw up.

  • KAREEM ZIDANE: Another thing.

  • Actually, take a look at the commit SHA in this case.

  • I think it's going to change if you do this.

  • Every time we do commit--

  • right now It starts with fa14a--

  • blah, blah, blah.

  • So if we do git commit --amend -m--

  • let's go back to our original commit message.

  • Added students list.

  • git log.

  • COLTON OGDEN: Oh, you're right.

  • It did.

  • KAREEM ZIDANE: It changed.

  • So this is actually one of the great features about git

  • is that it really has a great integrity, or ensures that the data has integrity

  • in this case.

  • So it seems to be that the commit message is actually

  • part of the input or part of the data that's hashed

  • when calculating or computing this.

  • COLTON OGDEN: So is it deterministic, such that if you were to do it again,

  • the git amend with the other message you just

  • had, would it be the fa14 or whatever?

  • KAREEM ZIDANE: I thought the time was taken into account too.

  • COLTON OGDEN: Oh, that makes sense.

  • KAREEM ZIDANE: But let's actually double check this.

  • This is a good point.

  • What?

  • Commit message?

  • Is that what you did?

  • I think it started with F last time.

  • COLTON OGDEN: Yeah, fa14.

  • OK, that makes sense.

  • It would make sense for them to put the time in there

  • because if it was deterministic people could all write the same file if time

  • weren't take into consideration.

  • Then they would get the same commit.

  • KAREEM ZIDANE: So what I meant by integrity, just to briefly explain,

  • is that if we're both on the same commit that has the same unique identifier,

  • then we exactly have the same state in our project.

  • That's what I meant.

  • COLTON OGDEN: OK, makes sense.

  • KAREEM ZIDANE: There's one thing you could do.

  • Another thing you could do is temporarily or permanently

  • revert back to a previous snapshot.

  • I think you alluded or asked about this earlier.

  • And one way to do this is using the git reset command.

  • Before using git reset I think we should have explained something

  • about this weird blue or cyan head on the top right, and master as well.

  • So these are pointers, or references if you're familiar with these terms,

  • and head is just a pointer that always points to the commit I'm on right now.

  • Master in this case happens to be the same thing as head, but in this case,

  • head and master are both two references that point to the topmost commit.

  • In this case, which is d615-- blah, blah.

  • Does that my sense?

  • COLTON OGDEN: Is head always the topmost commit?

  • KAREEM ZIDANE: Head is always--

  • not the topmost commit.

  • Head is always where you are [INAUDIBLE]..

  • COLTON OGDEN: OK, I see.

  • KAREEM ZIDANE: So you could be standing on--

  • we're going to talk about git branches later, but imagine we have 10 commits.

  • We could stop on the third one or change our state

  • to be the same as the third commit as it was in the third commit.

  • In this case, head is going to be pointing to this commit.

  • Branches on the other hand, are always point to the tip of this branch.

  • So in this case.

  • We have a branch called master, and the reference master

  • is always pointing to the top commit in the branch master

  • COLTON OGDEN: OK, that makes sense.

  • We have a couple of questions in the chat.

  • KAREEM ZIDANE: How can we change the second commit message?

  • This is actually a little bit more tricky,

  • and the reason this is more tricky is because of the same point.

  • The integrity of data.

  • So you can't really change the contents of a commit in the middle

  • without actually changing all history that follows that.

  • Because I think also part of the information of the commit,

  • like the commit SHA, whatever, is also taken into account

  • when calculating or computing this hash.

  • COLTON OGDEN: So it'd have to propagate to all the commits after that one

  • basically?

  • KAREEM ZIDANE: Correct.

  • The good the good news is that there is actually a relatively easy way

  • to do this.

  • We're not really going to talk a little bit about git rebase,

  • but essentially you could do git rebase -i,

  • and of course it's not working right now.

  • I think it's going to be HEAD is it?

  • Nope, no head.

  • Let's see.

  • git log.

  • Oh, I think we need to get rebase on the first commit, which the SHA starts

  • with 6facd something, something.

  • So I think we need to git rebase -i 6f8d, right?

  • COLTON OGDEN: cd I think.

  • 6facd.

  • KAREEM ZIDANE: And in this case, it shows us only the commit after this,

  • in this case.

  • And notice here there's a bunch of comments

  • about what we can do with this commit.

  • So in this case, I want to change the commit message of this,

  • so I need to change pick to reword or just R for short if I want.

  • I'll just get rid of this, change it to R, save.

  • And what do you want to change the commit message to in this case?

  • COLTON OGDEN: [INAUDIBLE] or who was it?

  • That was the person that said it.

  • KAREEM ZIDANE: Like this?

  • Save, git log.

  • Notice the commit SHA.

  • This is not going to be really obvious in this case

  • because we just have two commits, but in this case

  • the commit message did change.

  • Can we change the commit message of the very first commit?

  • That's interesting.

  • If I do this, is that going to work?

  • No.

  • I'll need to look this up, but I don't know

  • how to rebase or change the commit message of the first commit

  • without actually doing something more fancy.

  • COLTON OGDEN: Deceptively complex thing to do.

  • KAREEM ZIDANE: It is.

  • It's really one of the things that are relatively annoying,

  • but it's good that we have at least a way to do this.

  • COLTON OGDEN: [INAUDIBLE] had another question.

  • It says, is there any other way without losing

  • changes made, but see older version?

  • I think he's talking about git checkout.

  • KAREEM ZIDANE: So yes.

  • So you want to see the older versions in the repository while you have changes,

  • is that what you're talking about?

  • I don't know.

  • COLTON OGDEN: I think that's what he's talking about.

  • I guess like keeping changes that you currently have

  • but seeing the file as it used to be.

  • KAREEM ZIDANE: That's a good point.

  • I think you can do git show.

  • So if we git log in this case, suppose we

  • want to show what changed in the first commit.

  • Maybe you can do it git show 6facd, and this

  • shows you the contents of application.py and the other file.

  • Maybe you can do git show application.py.

  • Is that possible?

  • Yep.

  • COLTON OGDEN: That's pretty cool.

  • KAREEM ZIDANE: So you can just see the changes.

  • I think you can also check them out, if you want, to a different file

  • altogether.

  • And the way to do this would be git checkout.

  • Let's see, what was the commit SHA?

  • So instead of this that would be git checkout, the commit hash, and then

  • the file name into old.py.

  • That's wrong, of course.

  • Maybe I'm missing something, but there is a way to check out the file.

  • We're going to have to look this up.

  • 6facd.

  • Yep, there you go.

  • So the reference that you want should be before the dash dash in this case.

  • So now if I do cat old.py, I don't see anything because that was empty.

  • I guess I did something wrong.

  • Anyway, we're going to look at this later.

  • This is not the way to do it apparently, but I'm pretty sure

  • there's a way to concatenate or copy the contents

  • of the file of a previous commit--

  • COLTON OGDEN: Powerhouse of the cell--

  • shoutout to Nick Wong-- says git stash?

  • KAREEM ZIDANE: Git stash.

  • That's actually a good point.

  • Git stash actually temporarily discards the changes in your working directory.

  • So I guess we could have used actually git stashed.

  • That's really a good point.

  • Thanks for bringing that up.

  • So suppose we do the same stupid thing, echoing foo to application.py.

  • Now if I tail application.py in this case, I see foo in the end.

  • If I do git status I see that this changed.

  • If I do git stash, notice that this is also I

  • think going to temporarily save the change, even in the staging area,

  • to some fourth area that we didn't talk about.

  • The stash in this case.

  • So if you do git stash, it tells us that, hey, I

  • saved these changes [INAUDIBLE].

  • If I go git status again, nothing's here.

  • So presumably, if you open application.py now

  • it actually matches what's in the repository.

  • And the way to get these changes back is using git stash pop like this.

  • I do git status.

  • Now I see application.py with the changes that I made.

  • COLTON OGDEN: That's pretty cool.

  • [INAUDIBLE] like a sketch pad to work with I guess.

  • KAREEM ZIDANE: Yeah, that's a good question.

  • That's a great point.

  • There are other ways to revert back to a previous point in history,

  • in this case, using the git reset command.

  • And I think there are three distinct ways to use git reset.

  • One of them says, hey, I don't care about anything that I have right now

  • in the repository.

  • Just reset the state of my repository to a particular commit,

  • and this will be git reset --hard the reference to this commit.

  • The SHA for example, or whatever that we want.

  • COLTON OGDEN: And this is basically reviving that old snapshot

  • and making the directory reflect that snapshot.

  • KAREEM ZIDANE: Exactly.

  • It's forgetting about any change that you

  • have right now in the repository and force

  • resetting the state to the same state as it was.

  • COLTON OGDEN: And just like checkout this

  • will erase all current changes, right?

  • KAREEM ZIDANE: This will erase all current changes, yes.

  • The good thing is that it allows you to revert

  • to a completely different commit.

  • All the files, all the folder structure, is

  • going to be the same as in this commit.

  • While with checkout, I guess you can just check out

  • certain files from that commit.

  • There should be a way to check out everything,

  • but I think it's going to be a little bit more complicated to use

  • than using git reset [INAUDIBLE].

  • So I referred to head earlier, and the reason I

  • did that is that head is actually-- right now if I do git log,

  • head is actually the same as aa7d9 whatever, which

  • is the SHA or the hash of the first commit.

  • Not the first.

  • The top commit, rather, in this case.

  • And the cool thing about this is that we can actually

  • refer to commits without necessarily hard coding their SHA or hashes using

  • simple arithmetic with head.

  • So for example, if you want to reset back to the commit that's the parent

  • of the current commit, I could do git reset HEAD^ like this.

  • And notice that now, if we look at git status,

  • it shows that application.py is modified.

  • Templates register as untracked, which was the case when we first

  • added these files.

  • If I look git log right now, I see that the commit that I had--

  • the second commit disappeared and now head is 6facd dot, dot, dot.

  • COLTON OGDEN: Makes sense.

  • KAREEM ZIDANE: So this is one way.

  • I don't want you to get lost, but we mentioned that there

  • are three ways you can git reset.

  • You can force reset everything.

  • You can just do git reset without any flags in this case.

  • So not hard, not soft.

  • If [INAUDIBLE] force change back you can do git hard.

  • If you want to change back but maintain the changes, like in this case,

  • you can just to git reset.

  • Or if you want to go back but maintain the changes in the staging area,

  • that's going to be good.

  • Reset [INAUDIBLE].

  • So I guess we could demonstrate each of these.

  • There's another cool command that--

  • another cool feature is that when you do that,

  • git actually doesn't permanently forget about the commit.

  • You can do git reflog and see where head was before.

  • And apparently the commit that we lost, which was aa7 something, something,

  • we could just check this out now.

  • So git checkout aa7d9 something, something.

  • And of course, we have changes.

  • Let's stash these for now.

  • So let's do this again.

  • git clean -fd.

  • Discard any of these changes.

  • Let's try this one more time.

  • And now I'm on the [INAUDIBLE] head.

  • If I do git log now I can see my commit back in this case.

  • So I haven't lost it permanently in this case.

  • I believe after a while git might garbage collect this.

  • I'm not quite sure.

  • I know for sure that old commits on GitHub, which we'll get to in a while,

  • are actually--

  • [INAUDIBLE] commit like abandoned commits--

  • are erased after a while.

  • So in this case, we can get to our own commits.

  • So when we did git reset to the parent commit,

  • what happened is that our changes were maintained from that commit,

  • aa7 something something, in our working directory.

  • If I do git reset--

  • same command but add --soft to it, [INAUDIBLE] head,

  • I do [INAUDIBLE] again.

  • Now our changes are still maintained but instead they're in the staging area.

  • So you can imagine this is useful because if you change

  • the same files in your working directly right now,

  • this is not going to overwrite these changes, if that makes sense.

  • And finally, let's git reflog.

  • Let's git stash again for now.

  • We don't have anything, so let's git checkout, git reflog.

  • Let's actually do git reflog here and git checkout aa7d9,

  • and then again, we have the same commit.

  • Now, if we do git reset --hard to the parent commit of head in this case,

  • it's actually you're going to force reset, it actually [INAUDIBLE] again.

  • We don't have any changes.

  • So this is going to force the state of your repository

  • to be in the same state of this commit.

  • COLTON OGDEN: And this is where we are with froshim0 when we committed it.

  • So it's basically going to be at the very beginning?

  • KAREEM ZIDANE: Correct.

  • You can always check where hit is by using git log, and in this case

  • we're on the first comment.

  • COLTON OGDEN: Nice.

  • There's a lot of different ways to reset the [INAUDIBLE]..

  • To reset head, I should say.

  • KAREEM ZIDANE: Yeah, do you have any questions so far?

  • I imagine this is quite a mouthful.

  • COLTON OGDEN: Haven't gotten any messages in the chat

  • yet, but if anybody does have any questions,

  • definitely toss them in the chat there.

  • We'll take a look at it.

  • We're monitoring in real time.

  • But if anybody doesn't have a question, I

  • guess we can move on to the next topic.

  • KAREEM ZIDANE: All right.

  • Let's see.

  • What do we have here?

  • We talked about git stash.

  • We talked about git checkout.

  • Suppose you would like to--

  • first of all, I think we lost a commit here.

  • Are we on master?

  • Now we're on master.

  • Can we merge the commit that we lost again?

  • Because in this case we lost it from master.

  • Can we do this?

  • What was the commit again?

  • aa7d.

  • Can we do git merge aa7d?

  • OK, cool.

  • Now we've got our commit back.

  • So now master matched exactly the same state

  • that we left it on before doing all this crazy stuff.

  • So one thing you might be interested in doing is actually removing one file,

  • and there are more than one way to do this.

  • The easiest, of course, is to actually remove this file.

  • So suppose I want to remove application.py.

  • I do git status again.

  • Git is going to tell me, hey, this file is deleted.

  • And you can literally add this to the staging area

  • like we did with any other change.

  • Application.py git status.

  • Same thing.

  • And then we can commit this like last time.

  • The other way-- and I'm going to stash these for now.

  • Now if I check again I have my application.py.

  • The other way I can do this is using git rm, so git rm application.py.

  • And I believe this is going to stage it automatically for me,

  • so it doesn't require two steps in this case.

  • COLTON OGDEN: Nice.

  • Looks like [INAUDIBLE] has a question for you as well.

  • KAREEM ZIDANE: Sure.

  • [INAUDIBLE]

  • Use all these commands--

  • OK.

  • Do you, Kareem, use all these commands in your everyday life,

  • or is there some basic commands you use?

  • Another question, how does [INAUDIBLE] work?

  • OK, so these are two questions.

  • One of them is way, way beyond the scope of this stream,

  • which is how [INAUDIBLE] works, but I'm going

  • to try to explain the basic details of how that works.

  • COLTON OGDEN: We can also do maybe a separate stream someday

  • where we go into [INAUDIBLE] in a lot more detail and have time.

  • But maybe if you want to them a couple sentences I guess that might be--

  • KAREEM ZIDANE: Yeah, certainly.

  • For the first question, do I use all these commands?

  • I want to say yes, I do use all these comments and more.

  • But the catch is I didn't really sit at some point

  • and read the whole git documentation.

  • I just learned things as I went.

  • So if I want to add something to the staging area, I just googled that.

  • How to add this?

  • And I just found git add, git commit, git reset, git reflog, and all these.

  • COLTON OGDEN: Stack Overflow.

  • KAREEM ZIDANE: Exactly.

  • If you find yourself trying to memorize these

  • you're probably doing something wrong.

  • I think what you should do is just learn about

  • what's out there if you can get a basic idea, and then as you go,

  • as you need to do something, just Google how to do this.

  • And over time, if you use this again and again,

  • you're actually going to develop a muscle memory

  • and use these pretty easily.

  • COLTON OGDEN: And certainly some commands

  • are used a lot more often than other ones too.

  • KAREEM ZIDANE: Yeah, definitely.

  • COLTON OGDEN: Elias also says, best git tutorial he's ever seen.

  • Thanks.

  • KAREEM ZIDANE: Thank you so much.

  • That's so sweet.

  • So let's discard these now that we talked about git rm.

  • Of course, we need to commit these changes if you want

  • to actually save deleting this file.

  • But it's also sometimes the case that I want to ignore some files.

  • So suppose I need temporary files for credentials

  • that I have and I don't really want to save this in the repository.

  • If I do git status now, it's going to show us untracked.

  • The problem is sometimes if I have even more changes

  • and I try git add --all or git add --a, this file

  • is going to get added to the staging area as well

  • and eventually going to be accidentally, or not accidentally,

  • committed, which is not what I want.

  • So one thing I can do is [INAUDIBLE] once you

  • see this file or this folder or these particular files or folders.

  • Don't care about them.

  • Ignore them.

  • And the way to do this is by creating a file called .gitignore in the current

  • directory.

  • And on each line in this file, you're going

  • to specify a file name or path or a pattern for these for git

  • to match against [INAUDIBLE].

  • So in this case, I specifically want to ignore the credentials files,

  • so what I can do is open this in a text editor.

  • I could do this in one step.

  • Ignore and then say, hey, credentials I want to ignore that file.

  • Save an exit.

  • If I do git status again, I don't see credentials but I see .gitignore,

  • which is OK.

  • We want to keep track of .gitignore in our repository.

  • Now I should probably just git add this, ignore, git status.

  • Verify what's in the staging area before committing.

  • Git commit -m added, or it's more descriptive.

  • Ignore credentials.

  • There you go.

  • COLTON OGDEN: Easy.

  • KAREEM ZIDANE: Yeah.

  • So this is actually a feature that's frequently used of git,

  • and I think we should be ready to talk about branches, unless we

  • have questions first.

  • COLTON OGDEN: Cool.

  • Awesome.

  • KAREEM ZIDANE: OK.

  • I don't see any.

  • You?

  • COLTON OGDEN: The stream takes about 10 seconds for them to hear it,

  • so I'll monitor and I'll let you know if I see anybody ask any questions.

  • KAREEM ZIDANE: Makes sense.

  • Do you have any questions in the meantime?

  • COLTON OGDEN: No, I'm excited to get to branching.

  • Let's do it.

  • KAREEM ZIDANE: OK.

  • So branching is also one of the cool features of git

  • that allows you to work on different parts of the project pretty easily,

  • or experiment with things pretty easily without really

  • missing the state of your project or repository.

  • It also makes it way easier to work with people when we get to GitHub later

  • because you can imagine each of us can have their own branch, whatever that

  • means for now, and work separately.

  • And then when we're ready we just merge these changes back together.

  • COLTON OGDEN: So up to now we've worked with the master branch, right?

  • KAREEM ZIDANE: Up to now, the default branch in this case

  • is the master branch, and usually that's the main or the default

  • branch in any git repository.

  • Of course, it doesn't have to be the case.

  • It's just a convention.

  • And usually this branch should be always in a good enough state, in this case,

  • or a near perfect state.

  • We don't want anything to be messed up in this branch ideally.

  • So just explain what a branch is in short,

  • a branch is just a sequence of commits.

  • So we have how many commits now, three?

  • So these three commits represent the master branch in this case.

  • The way to list the branches that I have is using git branch,

  • and right now it says you have one branch called master.

  • And it's marking it in green and putting an asterisk in front of it,

  • saying that, hey, you're currently on this branch actually.

  • So one way to create a new branch-- suppose you want to add a feature

  • or fix a bug or improve something or you want to experiment,

  • you can just create a new branch using git branch.

  • Same command but then mention the branch name.

  • So let's call this new-feature.

  • If I do git branch again, it's going to say, hey,

  • I created a new branch for you.

  • It's here, new-feature, but you're still on master.

  • COLTON OGDEN: That's what the asterisk and the green text

  • are representative of I'm guessing?

  • KAREEM ZIDANE: Exactly.

  • So the way to switch to this branch actually is git checkout new-feature.

  • Now if I do git branch again, it says we're on new-feature.

  • Interestingly, though, if I do git log it shows the exact same thing,

  • and shows on the top here that new feature

  • is also pointing to the same commit.

  • And this actually sort of supports the point

  • that we talked about earlier that git does this efficiently.

  • When you create a new branch, git doesn't really

  • copy everything that you have into a separate place and just

  • gives you a branch to work with.

  • But rather, if git can refer to something from before,

  • it's just going to use a reference to it.

  • In this case, all three references head--

  • new-feature and master-- are pointing to this specific commit.

  • COLTON OGDEN: Makes sense.

  • KAREEM ZIDANE: Now you might find it a little bit

  • boring to use two commands to create and switch your branch.

  • Usually when you want to create a branch you want to switch to it immediately.

  • So the way to do that is using git checkout

  • -b, a flag that influences the behavior of git checkout in this case.

  • Let's call this new-feature1.

  • And now if I do git branch again, I actually created new-feature1,

  • as you can see, and switched to it immediately.

  • COLTON OGDEN: Cool.

  • So any features now that you write in new-feature1

  • aren't going to necessarily be in master or in new-feature,

  • just in new-feature1?

  • KAREEM ZIDANE: Correct.

  • So let's actually verify this.

  • So suppose I add a file called foo to my repository right

  • now on new-feature1 branch.

  • So git add, git status.

  • I see my new file git commit, added foo.

  • It's nice.

  • Everything's OK.

  • If do git log, notice here it updated actually.

  • I can scroll through this, but notice here it says both head

  • and new-feature1 are referencing this commit,

  • but master and new-feature, which are the old branches,

  • are referencing this commit.

  • COLTON OGDEN: Makes sense.

  • KAREEM ZIDANE: The cool thing, though, is

  • that if I do ls to list the files on my current directory, I see foo.

  • But if I switch to master, I don't see foo.

  • COLTON OGDEN: Nice, OK.

  • KAREEM ZIDANE: So it's that easy literally

  • to switch between different states of your project.

  • So if you do git log again I don't see new-feature1 at all here

  • and I only see my commits from earlier.

  • So this is also one of the really handy features of git.

  • COLTON OGDEN: So [INAUDIBLE] says, how can we

  • think of branching, like a new path?

  • KAREEM ZIDANE: You can think of branches as a sequence of commits.

  • We don't really need to get into the details of how these are exactly stored

  • or how they are handled by git for now.

  • This is probably for an advanced git tutorial.

  • But for now, yes, you can think of a branch as simply a sequence of commits.

  • COLTON OGDEN: So if I wanted to make a feature in our repo

  • separately from you, I can make my own branch

  • and you can keep working on your own branch or on master.

  • And then later on we can sort of mix them together.

  • KAREEM ZIDANE: Correct.

  • That's exactly right.

  • COLTON OGDEN: That makes sense.

  • So that way you and I aren't working on the same exact branch--

  • KAREEM ZIDANE: Correct.

  • COLTON OGDEN: --and then having merge conflicts.

  • KAREEM ZIDANE: Yeah.

  • If we have time actually we're going to demonstrate this pretty soon.

  • So what else do we want to do?

  • We showed creating branch.

  • We showed switching to a branch.

  • You might want to delete branch.

  • So you were experimenting with something and you figured, hey,

  • we don't need this branch anymore.

  • We don't need any of these changes anymore.

  • So me list my branches one more time using git branch.

  • Suppose I want to delete the new-feature1 branch in this case.

  • So the way to do this is git branch --delete and then

  • the name of the branch, which is new-feature1.

  • But git prints an error in this case, saying the branch new-feature1 is not

  • fully merged.

  • If you are sure you want to delete it run git branch -D, capital D,

  • new-feature1.

  • And git is trying to be protective and helpful here in this case

  • because it knows that some of the commits that I made on new-feature1

  • don't really exist in any other branch yet.

  • It doesn't want me to lose any of these changes unnecessarily.

  • So it prevents me from deleting this branch if I do git branch again.

  • All branches are still there.

  • But it tells me, if you're absolutely sure that you

  • want to get rid of this branch you can just do git branch -D new-feature1,

  • and now we deleted a branch.

  • Just confirm.

  • There you go.

  • COLTON OGDEN: Nice.

  • OK, pretty easy.

  • Looks like Andre has a question in the chat.

  • Larger text.

  • KAREEM ZIDANE: So branches are in fact stored locally on a machine

  • so you can switch between various branches of your project

  • without actually having a connection to a git server?

  • Yes, that's absolutely right.

  • [INAUDIBLE] all repository history are stored on your local [INAUDIBLE] system

  • and you can switch between any of them anytime you want.

  • COLTON OGDEN: I guess it would come into play if you

  • had your own branch on your computer and I had a branch in my computer

  • but we hadn't pushed it to GitHub yet.

  • That's when we would have issues actually.

  • We wouldn't be able to communicate our changes that way.

  • KAREEM ZIDANE: Correct.

  • COLTON OGDEN: [INAUDIBLE] distribute them or centralize them

  • somewhere so that we can grab each other's information.

  • KAREEM ZIDANE: Yeah, so my copy of the project and its history

  • is completely separate from the copy that you

  • have of the project in its history.

  • I can create however many branches on my local [INAUDIBLE] system

  • and you don't see them until I push to GitHub.

  • Then if you sync your local copy, then you're going to see them.

  • COLTON OGDEN: Good question from Andre.

  • KAREEM ZIDANE: That's a follow up question.

  • You're not getting it wrong.

  • This is exactly right.

  • OK, what else do we want to do?

  • We showed deleting a branch.

  • Let's actually show merging changes in this case.

  • So let's switch back to our new-feature branch, and then, I don't know,

  • let's copy files.

  • We could do from froshims.

  • That would be, let's see, five maybe?

  • Let's actually do [INAUDIBLE] file.

  • In this case, create a dummy file, add it, commit it.

  • Status [INAUDIBLE] verify, commit it.

  • Now if I want to merge these-- now recall

  • that if I checkout master again and switch back to master.

  • And ls the files, I don't see foo, my new file.

  • If I want to merge all the changes from my new-feature branch, all I got to do

  • is git merge new-feature while I'm a master.

  • COLTON OGDEN: [INAUDIBLE] says take whatever is in this branch

  • and try to combine it with wherever I currently am, basically.

  • KAREEM ZIDANE: Correct.

  • And in this case, git verifies that the changes were merged.

  • And if I do git branch again I'm still on master.

  • If I do ls I see foo now.

  • COLTON OGDEN: And there was no conflict because it was a separate file that

  • didn't exist, right?

  • KAREEM ZIDANE: Yeah, that's actually a great idea.

  • Let's demonstrate a merge conflict.

  • So now let's get rid of--

  • actually, by the way, let's demonstrate this first.

  • If you do get branch --delete--

  • I think there is a shortcut for this.

  • I don't remember it.

  • Maybe dash lowercase d--

  • new-feature.

  • Remember that previously [INAUDIBLE] complained about this, having

  • changes that were not merged yet.

  • Now that we've merged these changes into another branch,

  • [INAUDIBLE] try and do this, it's just going to happily delete it.

  • COLTON OGDEN: Nice, OK.

  • KAREEM ZIDANE: So now I only have master and I am on master.

  • I could do git checkout -b.

  • Let's see.

  • I don't know, fix-bug.

  • Now I should be on fix-bug.

  • Now suppose I do foo.

  • I open foo and I add a new line here.

  • Save my changes, git status.

  • Hey, foo was modified. git diff.

  • Here is the line that was added.

  • And git commit.

  • What did I forget to do in this case?

  • I should add it first to the staging area,

  • so git add foo or git add all in this case

  • because foo is actually all essentially in this case.

  • Git status.

  • Hey, foo is in the staging area.

  • It's ready to be committed.

  • Git commit -m added new line.

  • Trying to be a little bit more descriptive here.

  • Git checkout master back.

  • If I open foo again I don't see my line because this line

  • was committed on another branch.

  • But suppose you're working directly on master, which is not recommended.

  • You should create your own branch.

  • But just for the sake of saving time here,

  • suppose Colton's working on master and he opened foo

  • and he added no my new line.

  • COLTON OGDEN: So greedily, yeah.

  • KAREEM ZIDANE: So here's how foo looks like now.

  • Do a git status.

  • Hey, foo was modified.

  • Git add foo.

  • Git status to verify that we have the things that already being committed.

  • Commit -m added Colton's.

  • Colton, new line.

  • Now if you do git log here is the commit.

  • Suppose we try to merge the changes from new-feature.

  • What do you expect is going to happen?

  • COLTON OGDEN: Probably bad things.

  • KAREEM ZIDANE: Probably bad things.

  • You have good intuition.

  • And not something we can merge.

  • COLTON OGDEN: That's a really bad thing.

  • KAREEM ZIDANE: Interesting.

  • That's weird.

  • That shouldn't have happened.

  • Git branch.

  • Oh, because we called our branch fix-bug not new-feature.

  • So git merge fix-bug now.

  • Still bad things happen.

  • But now git is telling me, hey, there is a conflict

  • and it's yelling at me that there is a conflict.

  • There is a merge conflict in foo.

  • Automatic merge failed, so git could have merged this automatically.

  • Fix the conflict and then commit.

  • So again, git is trying to be very helpful here.

  • If we take a look at foo now, notice this weirdness.

  • So there is a bunch of symbols and stuff, but we also see my line

  • and your line in both.

  • COLTON OGDEN: I think this is what Andre also was alluding to before with XML.

  • KAREEM ZIDANE: Yeah, maybe there is another format

  • where you could output these changes.

  • I think this should be easily machine-parsable as well

  • if you want to do this, but the point is not

  • about the format in which these merge conflicts are shown.

  • It's more about git is not sure which of these to take.

  • If it knew it would take these pretty easily,

  • but git doesn't know in this case.

  • So in this case me as a human I have to, or I have a human,

  • I have to fix this merge conflict manually.

  • And I can do this by favoring my line or Colton's language,

  • I'm going to do in this case.

  • So I'm just going to delete my line and these weird symbols,

  • save, git status, git commit in this case.

  • Sorry, git add foo first.

  • Git status.

  • All conflicts are fixed here.

  • If I do git status, git confirms that all conflicts are fixed.

  • Now all I need to do is git commit and it's going to open up text editor,

  • showing commit message, save, git log again.

  • Here is the merge commit that we had.

  • And if open foo, now Colton's new line is actually the one that's there.

  • COLTON OGDEN: Nice.

  • So I'm just moving the chat at [INAUDIBLE] request.

  • It's a little bit obtrusive, and it looks

  • like Elias also has a question too.

  • How do remove a file from git without removing it from your file system?

  • KAREEM ZIDANE: How do you remove a file from git without removing it

  • from the file system.

  • That's a good question.

  • I think you would need to do two things here.

  • The first one of them is actually remove the file from the repository using

  • git rm, and then ignore the file using gitignore to have git not

  • track this file again.

  • COLTON OGDEN: Sure, makes sense.

  • Is there a way to avoid git from actually even trying

  • to merge in that case--

  • referring to the merge that we just tried to resolve--

  • Or some way of detecting potential conflicts?

  • KAREEM ZIDANE: That's a great question.

  • I think there is a way to abort the merge in this case.

  • Let's see.

  • What are we looking at?

  • Try to reset the state of this to the previous commit maybe,

  • so let's git reset hard to the previous commit, which is 039d whatever.

  • Log.

  • That didn't work.

  • What are we going to do?

  • We're now on the previous commit in this case, which is--

  • foo didn't have anything.

  • Weird.

  • So let's do this again real quick.

  • I messed up something here.

  • New-line.

  • That was the one on master.

  • And if I switch back to--

  • let's add this.

  • Let's add this, commit this, add it, new line.

  • Switch back to fix-bug, check out fix-bug, git branch.

  • Now if I show what's in foo, I should see--

  • I should have added something else there.

  • Check out master.

  • Sorry about that.

  • My new line in this case.

  • My new line, checkout fix-bug.

  • So now if I try to merge this, I should still see a merge conflict.

  • OK.

  • I actually lost track of something.

  • Added a new line.

  • Which commit is this?

  • Oh, we're still on fix-bug, so we should probably

  • switch out to master first because that's

  • the branch that we want to merge into.

  • So git checkout master, git merge fix-bug.

  • In this case, I should still see the merge conflict, and I think--

  • is there git merge --abort?

  • Yep, there you go.

  • So if you do git merge --abort, I think it just canceled the merge

  • and not show any merge conflicts right here.

  • COLTON OGDEN: So that will just keep whatever was in master?

  • KAREEM ZIDANE: Yes, correct.

  • COLTON OGDEN: OK, that makes sense.

  • So this merge conflict is done when two people are working on the same file.

  • Am I getting it right?

  • KAREEM ZIDANE: That's correct.

  • Same file and actually same part of the file.

  • Because if you're working on different parts of the file,

  • git knows how to merge these changes.

  • That's great.

  • So we resolved merge conflicts.

  • I wanted to actually briefly demonstrate collaborating with someone.

  • So working on GitHub essentially.

  • And for that we're going to need to have accounts.

  • So I have mine here, which is a fake account.

  • COLTON OGDEN: You want me to collaborate with you in this case.

  • KAREEM ZIDANE: I hope GitHub doesn't flag us.

  • COLTON OGDEN: That would be unfortunate.

  • KAREEM ZIDANE: So the main thing that we need to understand about GitHub

  • is that it's a hosting service, which means

  • what GitHub does for us is actually allow

  • us to have a remote copy of our repository and history on their servers

  • so that everyone can sync with that, remote copy,

  • push changes to it to save it somewhere else so it's not just

  • on your local system.

  • Fetch new changes from it and so on.

  • So for that we're going to need a GitHub account.

  • If you're new to this you should go to github.com/join to create your account.

  • I just signed into mine here.

  • And the way to create a new repository I think

  • is by clicking on this little plus icon here and then choose new repository.

  • And I hadn't thought about the name, so I'm just going to call it froshims.

  • In this case, I'm going to make it a public repository.

  • I think GitHub might allow you one free private repository.

  • I don't remember.

  • I have to check this out.

  • COLTON OGDEN: Yeah, I think it was a limited amount.

  • Two or three or something like that.

  • KAREEM ZIDANE: So if you'd like your repository

  • to be private, not publicly accessible on the internet,

  • you should probably mark it as private.

  • In this case I just don't care, so I'm going to have it as public.

  • Create a repository.

  • COLTON OGDEN: [INAUDIBLE] cool, that's a lifesaver for the git merge abort,

  • or whatever it was.

  • KAREEM ZIDANE: Yep, definitely.

  • Yeah, definitely.

  • It's definitely a completely valid case that you want to change your mind

  • and I don't care about these changes anymore.

  • So you can just abort them as easily.

  • So now that we have this remote copy of our repository,

  • it doesn't have anything in it, obviously.

  • And GitHub is trying to be helpful here and giving us some instruction

  • on how to get started with this.

  • In most cases, people might have actual code on their local file systems,

  • and we just need a way to tell GitHub hey, GitHub--

  • or we need a way to tell our local repository that hey,

  • you should be syncing up with this remote repository from GitHub.

  • And the way to do this is by adding a remote.

  • And the way we add a remote is git remote add,

  • I think, and then we should choose a simple name for this remote.

  • By default, it's going to be origin I think.

  • And then the URL of the repository.

  • So we can just copy this from here, paste it here.

  • Git remote add origin and then this.

  • If this works as expected, you should do git remote -v

  • to list the remote repositories.

  • And in this case git is saying, hey, I'm going

  • to be syncing with this particular GitHub repository from GitHub.

  • COLTON OGDEN: Nice, and so now we've established that connection.

  • We can push to them and get code from them.

  • KAREEM ZIDANE: Correct.

  • And notice that git is actually listing these separately for fetch and push,

  • and this is because it's actually possible to read from some repository

  • and push to some other repository.

  • COLTON OGDEN: [INAUDIBLE] server or something that you want--

  • KAREEM ZIDANE: Yeah, we're going to briefly talk about forking soon.

  • But suppose you want to contribute to some open source project on GitHub.

  • You want to ideally sync with this project, as well as your project.

  • [INAUDIBLE] literally set the fetch URL to be the upstream,

  • or the original project, on GitHub.

  • And instead of pushing to that one, which ideally wouldn't be allowed,

  • you can just push to yours or your copy of it.

  • Your fork.

  • COLTON OGDEN: Looks like we have a couple of comments.

  • [INAUDIBLE] if I'm pronouncing that right.

  • He says, whoa, is that David Blaine on the right?

  • Do you know who David Blaine is?

  • Are you Familiar

  • KAREEM ZIDANE: No idea, I'm sorry.

  • COLTON OGDEN: Real quick.

  • This is very important.

  • This is David Blaine right here.

  • He's a very famous magician.

  • KAREEM ZIDANE: Oh, interesting.

  • He's not bald though.

  • COLTON OGDEN: Go to my screen for a second

  • so we can see some pictures of David Blaine.

  • KAREEM ZIDANE: Wow.

  • COLTON OGDEN: I think he has been bald occasionally.

  • [INAUDIBLE]

  • KAREEM ZIDANE: How did he get rid of it?

  • COLTON OGDEN: I don't know.

  • Maybe he was never bald.

  • Maybe he just had really short hair at times.

  • KAREEM ZIDANE: Maybe.

  • That's fair.

  • COLTON OGDEN: David Blaine and GitHub everybody.

  • KAREEM ZIDANE: I also think I have short hair all the time.

  • But anyway--

  • COLTON OGDEN: Another comment.

  • GitHub is basically like a storage facility for our files.

  • So can we both put stuff there without sharing our user name and password?

  • KAREEM ZIDANE: Definitely, yes.

  • I mean, if you have to share your username and password every time

  • you put something on GitHub that wouldn't really be ideal.

  • So yes, you can put stuff there without sharing any usernames or password.

  • You can give people access to it without sharing your username and password

  • with them, which is a neat feature as well.

  • But GitHub is actually not just a storing facility.

  • GitHub has a lot of features.

  • We'll hopefully explore them briefly.

  • So we're going to see about this.

  • So now that I let my local repository know that hey, you should be syncing up

  • with this remote repository on GitHub, one thing I can do

  • is simply push my current branch, which is master in this case.

  • So the way to do this is git push origin, which is the name of my remote

  • as you can see here on the left, and then

  • master, which is the name of my local branch.

  • So if I do this--

  • hopefully if the internet cooperates in this case.

  • So I'm seeing a prompt right now for my username and password

  • because obviously, I don't like anyone to be able to push to my repository.

  • So in this case, I'm going to provide my username, which is cs50student2--

  • my password, which I'm not going to say.

  • COLTON OGDEN: [INAUDIBLE].

  • Kareem the Dream 1990.

  • KAREEM ZIDANE: It's something like that.

  • So now git confirms that it pushed my changes to my remote repository.

  • If I refresh this page, I should hopefully

  • see my master branch has exactly the same content as my local master

  • branch has at this point.

  • COLTON OGDEN: Like a file system view of all the files on that snapshot

  • [INAUDIBLE] snapshot.

  • KAREEM ZIDANE: Not just that.

  • I think you can actually work directly within GitHub

  • and edit files and stuff, which is really--

  • COLTON OGDEN: Oh, that's true.

  • Use the little pencil icon.

  • The chat's blocking it.

  • KAREEM ZIDANE: Yeah, it's a really cool interface to browse your repository

  • or browse other people's repository without necessarily

  • having to have a local clone of them.

  • COLTON OGDEN: [INAUDIBLE] other things like issues,

  • pull requests, projects, a lot of different features too.

  • KAREEM ZIDANE: Yeah, we can briefly introduce some of these features.

  • Before we do that, though, I wanted to mention a point

  • on cloning a repository.

  • So suppose Colton is completely new to this

  • and he wants to make some contribution to my repository,

  • or just wants to get a local copy for my repository to experiment with it.

  • The way to do this is by clicking this, getting

  • the URL of the repository-- copying it essentially.

  • And if I go to a separate directory here, temp, I can do git clone,

  • paste the URL, enter, and it cloned my repository.

  • And notice it also cloned the history of my repository, which is really neat.

  • And this is what we meant earlier by this [INAUDIBLE]

  • version control system.

  • COLTON OGDEN: Everybody, whoever downloads your repo,

  • has all of the history in there for their own version of the entire version

  • control system.

  • KAREEM ZIDANE: That's exactly right.

  • And the cool thing though is that you are actually in control of this,

  • so you can actually clone only certain branches or even

  • only a certain number of commits from these branches without--

  • imagine a huge repository with a huge history.

  • It's going to be really difficult to download on some networks,

  • so you can just clone a limited number of these.

  • COLTON OGDEN: Sure.

  • Makes sense.

  • KAREEM ZIDANE: All right.

  • So do you want to switch to your computer now to make a tiny change?

  • COLTON OGDEN: Sure, OK.

  • So [INAUDIBLE] go to mine.

  • Let me go to my GitHub.

  • By default it's going to show my dashboard here.

  • So I want to go to your repo, so what's the URL of your repo again?

  • KAREEM ZIDANE: The URL of my repo is github.com/cs50student2

  • COLTON OGDEN: cs50student2--

  • KAREEM ZIDANE: Slash froshims.

  • COLTON OGDEN: Slash froshims.

  • KAREEM ZIDANE: And we mentioned earlier that random people on the internet

  • won't have-- not that Colton is random people but--

  • any other username or GitHub username won't have push access

  • to this repository.

  • So what probably Colton wants to do at this point

  • is actually fork this repository or create his own copy on GitHub first.

  • So the first thing you need to do is actually

  • click on the fork button on the top right.

  • COLTON OGDEN: OK, so this button right here.

  • KAREEM ZIDANE: Yup.

  • I don't think it shows up here.

  • COLTON OGDEN: Oh, it's not visible on the chat there.

  • We'll just hide the chat just for a second.

  • [INAUDIBLE] says, I can't believe that's Colton from the lectures.

  • Can you edit the code from Docker?

  • [INAUDIBLE] thanks for tuning in.

  • KAREEM ZIDANE: I'm actually using the Docker container right now.

  • I'm inside of a Docker container.

  • So yes, you can use git or edit your code inside of a Docker container.

  • COLTON OGDEN: Thanks for joining us.

  • I'm going to go ahead and hide the chat box just

  • for a second so that we can see the web browser in its entirety.

  • And then, you said click this fork button right here.

  • KAREEM ZIDANE: Yup.

  • COLTON OGDEN: OK, I'm going to click that fork button [INAUDIBLE]..

  • I'm an owner of multiple organizations on GitHub.

  • We won't talk about that.

  • I'm not an owner but an admin, rather.

  • I'm going to fork it.

  • KAREEM ZIDANE: That's gonna take a while.

  • COLTON OGDEN: --personal account.

  • So now I can just clone it, like you said.

  • Go down here.

  • And now I'm seeing that now it says, github.com/coltonoscopy/froshims,

  • no longer cs50student2.

  • KAREEM ZIDANE: Exactly because this is your own, as you mentioned, copy

  • of this repository on GitHub.

  • COLTON OGDEN: Nice.

  • So when I make push changes to this, you won't be able to see them, will you?

  • KAREEM ZIDANE: Nope.

  • I won't be able to see them until you actually create something called a pull

  • request, as we see.

  • So the way to do this is to switch where you want to clone this.

  • COLTON OGDEN: I'm in the game stream folder from yesterday.

  • So I'm going to go into my dev.

  • I'm just going to-- oh yeah, and streams,

  • and then I'm going to I guess clone it right here.

  • So git clone, which is a command that you showed before.

  • KAREEM ZIDANE: Correct.

  • COLTON OGDEN: And then I just paste in that .git URL and then clone it,

  • and then boom, I have everything.

  • So now if I hit ls, I should see I have the froshims folder.

  • I can cd into that froshims folder, hit ls again,

  • and I notice that I do have all the files that were in that repo.

  • KAREEM ZIDANE: So now maybe you can make any changes, like opening the files,

  • adding new lines, or add new files.

  • Colton can forward the same workflow that we have been following so far.

  • COLTON OGDEN: So I don't think I have a fancy CLI editor,

  • but I'll use nano on application.py maybe, which is--

  • KAREEM ZIDANE: I honestly don't know how to use nano except for saving.

  • COLTON OGDEN: It's a pretty bare bones editor,

  • but let's just say that I wanted to maybe add

  • a comment at the top or something.

  • So I go up here, do that, and then Colton's version.

  • And then I can save it with Control X, Y, Enter.

  • KAREEM ZIDANE: Git status to see what changed.

  • COLTON OGDEN: Right.

  • And now we see the same red message from before which says modified,

  • although it's red here and I think it was green.

  • Was it green for you before?

  • KAREEM ZIDANE: No, it becomes green when it's added to the staging area.

  • COLTON OGDEN: Oh, right.

  • KAREEM ZIDANE: So you can do git diff actually to see what changed.

  • COLTON OGDEN: Right.

  • So git diff, and then we'll see indeed.

  • Since my terminal color scheme is green--

  • KAREEM ZIDANE: Which shows a plus sign in this case in front of it.

  • COLTON OGDEN: So Colton's version and then this blue stuff.

  • I forget exactly what this means.

  • KAREEM ZIDANE: I think this refers to ranges of the file that are changed.

  • So in this case, I think the first line, the third column?

  • Or I don't know.

  • The first line I guess, or move three characters,

  • added five characters or whatever.

  • I don't know.

  • COLTON OGDEN: Yeah, I'm not sure either.

  • KAREEM ZIDANE: But it refers to certain ranges of line numbers and columns

  • in the file, Essentially.

  • COLTON OGDEN: Cool.

  • So then now I've done it.

  • [INAUDIBLE] git status.

  • [INAUDIBLE] made the change but I haven't actually

  • committed it, which is what we did before.

  • KAREEM ZIDANE: Correct.

  • Before you commit [INAUDIBLE].

  • [INTERPOSING VOICES]

  • COLTON OGDEN: It looked like the video signal chopped off.

  • So now I want to commit, right?

  • KAREEM ZIDANE: You have to stage it first I think.

  • COLTON OGDEN: I think you can just commit, right?

  • KAREEM ZIDANE: You can do this in one step, but usually people do it in two.

  • COLTON OGDEN: I don't.

  • I usually commit directly.

  • That's OK.

  • Walk me through.

  • KAREEM ZIDANE: So git add application.py.

  • And now if you do git status again, you should see this in green.

  • COLTON OGDEN: [INAUDIBLE]

  • KAREEM ZIDANE: Now this is staged.

  • This is ready to be committed.

  • If you do git commit -m and then your commit message.

  • COLTON OGDEN: So Colton's version.

  • KAREEM ZIDANE: You don't have to add the a.

  • The a is actually--

  • COLTON OGDEN: To add as well.

  • - KAREEM ZIDANE: --to add as well, yes.

  • COLTON OGDEN: OK, so that's why I guess I always commit,

  • because I always do the -a flag.

  • KAREEM ZIDANE: Yeah, the downside of -a I

  • think is that it doesn't account for untracked files.

  • COLTON OGDEN: Oh, I always git add those manually,

  • so I guess my workflow's a little bit different.

  • KAREEM ZIDANE: If you think [INAUDIBLE] to git add [INAUDIBLE]

  • you can obviously do this.

  • COLTON OGDEN: Maybe it's better practice to do it

  • the way that you're describing.

  • KAREEM ZIDANE: I personally always do git add first.

  • COLTON OGDEN: I don't think I've set my--

  • I thought I set my config yesterday but I guess it's not set.

  • But that's OK.

  • KAREEM ZIDANE: You can just copy these commands if you want.

  • COLTON OGDEN: Global user [INAUDIBLE].

  • KAREEM ZIDANE: While you're doing this I'm

  • going to try to answer this question.

  • So suppose I clone something from user 1, made changes

  • as commits to save on the main person's stuff.

  • Won't it mess up the original repository?

  • I don't think so.

  • This is completely going to be on Colton's copy,

  • both locally and remotely.

  • And we'll see now, what if Colton later wants to actually propose these changes

  • to the original repository?

  • So we'll explore this in a bit.

  • So I guess you're all set up with--

  • COLTON OGDEN: So I committed and I can push now if I want to.

  • KAREEM ZIDANE: Can I see git log just to verify that you committed?

  • COLTON OGDEN: Oh, sure.

  • KAREEM ZIDANE: Awesome.

  • Great.

  • So there is your commit.

  • Now you can exit this queue and git push.

  • So it pushed right now.

  • Previously, I was more verbose and specified origin master.

  • Truth is, git doesn't always know what the default remote branch should

  • be that would be synced with this current local branch because, recall,

  • they are separate.

  • And so you can always configure this using--

  • my computer got locked here.

  • You can always configure this using git push -u, lowercase u, or --set-upstream

  • I guess to sync local and remote branches with each other.

  • So now that Colton pushed, can we check your GitHub repository?

  • COLTON OGDEN: Sure, let me switch the view to my laptop right there,

  • go back to Chrome, and then refresh the page.

  • It still kept the John Harvard name on this account for some reason.

  • Git config doesn't seem to be working on this user.

  • I have to figure that out.

  • KAREEM ZIDANE: There are multiple levels of configuration,

  • so probably you have a narrower scope.

  • So now that Colton has--

  • can you open application.py just to verify that it has your comment in it?

  • So suppose Colton thinks that these changes

  • should be actually added to my repository,

  • my copy of the repository on GitHub.

  • One way Colton can do this is by actually opening a new pull request.

  • And the way to do this is if you go back to the repository,

  • there's a new pull request, as you can see here.

  • COLTON OGDEN: Oh, sorry.

  • [INAUDIBLE]

  • Creating a new pull request.

  • KAREEM ZIDANE: And notice that it's recognizing my repository right here

  • on the top left.

  • COLTON OGDEN: Oh, yeah.

  • The base fork.

  • KAREEM ZIDANE: So it's saying that, hey, it's

  • going to try to apply these changes to this branch

  • from the original repository.

  • And now Colton can create a new pull request.

  • COLTON OGDEN: It also shows the change here too.

  • KAREEM ZIDANE: Exactly.

  • And this is also one of the nice features about GitHub.

  • It shows you a graphical user interface for what we practically

  • were able to see using git log--

  • sorry, git diff in this case.

  • So if verify [INAUDIBLE] new pull request,

  • you're going to have to give it a title by the [INAUDIBLE] commit message,

  • and you can specify more details if you want.

  • And the nice trick about this is that GitHub actually

  • uses some version of markdown here.

  • So if you, for example, type something-- type anything.

  • Like suppose it's a more specific description

  • for your pull request in this case.

  • If you click on Preview, this is what's going to show.

  • If you go back to write and then add a hash in front of this,

  • it's going to convert it to a heading.

  • COLTON OGDEN: Nice.

  • KAREEM ZIDANE: There's actually a GitHub guide on these markdown tricks

  • that you can do to format your detailed pull request in a neat way.

  • So once you're happy with all your changes,

  • you could just click create pull request one more time.

  • Now, ideally, I'm going to see this if I have notifications actually enabled.

  • I should receive an email about this.

  • But ideally notice that pull requests here are-- one, if I go to this tab,

  • I'm going to see Colton's pull request.

  • And also, a few neat features of GitHub, I

  • can assign this pull request to certain people to take care of.

  • I can review this pull request.

  • I can give it certain labels if I want.

  • I can add custom labels too, and so on.

  • So these are some--

  • COLTON OGDEN: You can add continuous integration,

  • which we might talk about next week.

  • KAREEM ZIDANE: We might talk about continuous iteration deployment maybe.

  • That will be also me.

  • So I can also comment on the pull request.

  • This has nothing to do with the code whatsoever.

  • We can just add, hey, Colton.

  • I am expecting this to be like this or that's good.

  • Good job.

  • Or any other number of comments that I could add about this pull request.

  • Once I'm happy with Colton's changes, notice

  • that I also can see what changed using the file change interface here--

  • button, tab.

  • If I go back to the conversation-- and then once I'm happy,

  • I can just click Merge, Confirm Merge, and now I've

  • actually merged the changes from Colton's remote repository.

  • If I go back to my repository, open up application.py,

  • I can see Colton's comments here.

  • So this is pretty much it for pull requests.

  • There are also features that Colton alluded to earlier.

  • These are more like if you want to create a bug reporter for something

  • in this project, or if you want to request a feature,

  • or if you want to ask a question even.

  • You can also use the Issue feature of GitHub to create a new issue.

  • And notice the interface is pretty similar to the one

  • that you had briefly for a pull request and also uses the same markdown version

  • so you can just also format it in a good way.

  • I think that's pretty much it for GitHub.

  • One more thing that I think we should show that I actually forgot is--

  • I guess we're at a perfect time to show this.

  • So now that I am in my--

  • let me get back to my repository--

  • froshims.

  • Actually, if I do git locally, I don't really

  • see Colton's commit here in this case.

  • So the way to sync up with my version of the repository on GitHub

  • is using the git pull command.

  • So if I do git pull origin master, or if you converted this,

  • it can do this for you by default--

  • if I do git pull origin master, hit Enter,

  • it's going to fetch the changes from the remote repository now.

  • I do git log again, and now it's your commit.

  • If I open application.py, go to the top line, I can see your comment.

  • COLTON OGDEN: And we're all synced up.

  • KAREEM ZIDANE: Yeah, we're all synced up.

  • So this is one workflow that people follow to collaborate.

  • COLTON OGDEN: [INAUDIBLE] original user has the final say.

  • That's very cool.

  • KAREEM ZIDANE: Yeah, definitely.

  • I mean, we have pretty much an infinite number of open source projects.

  • Imagine that anyone can do anything to them.

  • That would be pretty bad, so it's good to have this sort of permission model

  • and restrictions.

  • COLTON OGDEN: But you have the ability to contribute to anybody else's code

  • if they approve of it.

  • KAREEM ZIDANE: Correct.

  • Yes, that's absolutely true.

  • All right, I think that's all what I have for now.

  • We can stick around for a few more questions.

  • COLTON OGDEN: Yeah, let's stick around for just a couple

  • of minutes for some questions.

  • Thanks for coming in to give us a talk--

  • KAREEM ZIDANE: Thank you so much.

  • COLTON OGDEN: --on git and GitHub.

  • And thanks everybody who tuned in today.

  • We had 15 viewers here.

  • We had upwards of 20 at some point.

  • KAREEM ZIDANE: That's great.

  • COLTON OGDEN: That's some good numbers.

  • KAREEM ZIDANE: That's exciting.

  • COLTON OGDEN: A lot of regulars in here today too.

  • And so on the horizon, you see you might have some potential other topics

  • you want to talk about?

  • KAREEM ZIDANE: Yeah, at least we should probably

  • talk about some continuous integration deployment techniques and tools.

  • That will be interesting, I think, and that's something

  • that we are actually using besides git and GitHub here at CS50.

  • Long story short, the idea is we are able, through these tools,

  • to automate some of the testing and deployment of our projects,

  • which is really cool.

  • One thing that I just remembered is talking

  • about how check50 and submit50 work.

  • They are built on top of git and GitHub.

  • So they essentially do something like this, so committing your changes,

  • pushing them to a remote repository underneath the hood,

  • just in a slightly different way.

  • But they essentially use the same principle

  • to push your code to some of our organizations on GitHub

  • or accounts on GitHub.

  • And from there, we actually do some automation

  • to actually create these automatically.

  • COLTON OGDEN: I think a lot of people would probably

  • be interested in seeing a more thorough walkthrough of how

  • submit50 and check50 works.

  • KAREEM ZIDANE: By the way, there are actually open source as well on GitHub,

  • so you can go to github.com/cs50/check50 and see the latest version of check50

  • right now.

  • Or submit50 to see the latest version of submit50.

  • Submit.

  • Did I spell that right?

  • There you go.

  • So that's submit50 as well.

  • COLTON OGDEN: [INAUDIBLE] pushed the last the last commit there.

  • KAREEM ZIDANE: On August 15th.

  • COLTON OGDEN: Merged a pull request, which we just talked about.

  • We've got a couple of comments in the chat there.

  • Did you answer the question about suppose

  • I closed-- yeah, you did the clone one?

  • KAREEM ZIDANE: Yeah.

  • COLTON OGDEN: Does the repo have to be public, or original user

  • can share a link if it's private?

  • KAREEM ZIDANE: That's a great question.

  • So in case it's private, anyone that's going to try to clone this repository

  • is going to fail to do that.

  • Git is going to refuse to clone it.

  • GitHub is not going to allow this data to be given I guess.

  • So if I go back to my froshims-- if I go back to the sitting step--

  • suppose this is a private repository, which it's not in this case,

  • but suppose it's a private repository.

  • I can click on Settings, I can click on Collaborators here on the left,

  • and then here I can actually add usernames like coltonoscopy-- right?

  • Is that your--

  • COLTON OGDEN: Yeah, coltonoscopy.

  • KAREEM ZIDANE: Colton's--

  • COLTON OGDEN: You're missing a T.

  • KAREEM ZIDANE: Sorry.

  • COLTON OGDEN: Colonoscopy is slightly different.

  • KAREEM ZIDANE: Wait, colonoscopy?

  • COLTON OGDEN: It's a coltonoscopy.

  • I think you wrote colonscopy.

  • KAREEM ZIDANE: I did write Colton first.

  • COLTON OGDEN: O-S-C-O-P-Y.

  • KAREEM ZIDANE: That's not true.

  • Do you want to spell it?

  • COLTON OGDEN: It's not working?

  • KAREEM ZIDANE: Yeah, that's awkward.

  • There you go.

  • I was spelling it incorrectly.

  • COLTON OGDEN: I couldn't read it from here.

  • KAREEM ZIDANE: So I can specify Colton's username, add a collaborator,

  • and once Colton accepts this invitation--

  • COLTON OGDEN: I think I'd have to go into my--

  • KAREEM ZIDANE: Yeah, do you want to switch to yours first here?

  • COLTON OGDEN: Would I have to go into my email to do that?

  • KAREEM ZIDANE: Not really.

  • You can just go to the same repository, which is

  • mine in this case, slash invitations.

  • COLTON OGDEN: Slash invitations on the repo?

  • KAREEM ZIDANE: I think so.

  • There you go.

  • COLTON OGDEN: Nice.

  • KAREEM ZIDANE: And then you can accept.

  • I think you do receive an email about this as well.

  • COLTON OGDEN: Yeah, I think that's where I usually click it to accept it.

  • KAREEM ZIDANE: So now if you go back to my screen, if I reload the page,

  • now I see that Colton's actually a collaborator here.

  • COLTON OGDEN: Now I can actually push directly to--

  • KAREEM ZIDANE: Now he actually has push access to my repository in this case.

  • I remember there was once a menu that allows you to give

  • read only access to the repository.

  • COLTON OGDEN: I think I remember that as well.

  • KAREEM ZIDANE: I don't see it here, but it might be present in other contexts.

  • But usually there is a menu that lets you give people

  • read only access to this repository.

  • COLTON OGDEN: Irene has another question there too

  • if you want to read that one off.

  • KAREEM ZIDANE: Why would you recommend forking project as opposed

  • to creating a new branch?

  • So these are two different things.

  • Forking a project is creating a copy of some project

  • into your own GitHub account, while creating a branch

  • is something that we do within a project.

  • So these are slightly different if that makes sense.

  • COLTON OGDEN: And then can you change the GitHub name, like froshims?

  • I was not able to change it.

  • KAREEM ZIDANE: I guess if you go to Settings options

  • you should be able to change the repository name,

  • so long as you don't have a repository within your own account

  • with the same name.

  • So that should be possible as well.

  • So Settings options, and then repository name.

  • COLTON OGDEN: I think my mic has been dead this whole time.

  • I just realized, which is great.

  • KAREEM ZIDANE: Wow.

  • Nobody commented on that.

  • COLTON OGDEN: Yeah, Dan just Slacked me.

  • We're always at the end of the stream, so I'll just piggyback off

  • of your microphone, I guess.

  • KAREEM ZIDANE: It's interesting no one commented on that.

  • COLTON OGDEN: I'm not sure why.

  • KAREEM ZIDANE: Maybe it got, like, I don't

  • know-- it interrupted in the middle of the stream.

  • COLTON OGDEN: Pretty cool.

  • KAREEM ZIDANE: All right.

  • What other questions do we have?

  • COLTON OGDEN: Oh, we were talking about the things

  • you might work on in the future.

  • KAREEM ZIDANE: Yes.

  • So I think we briefly talked about this.

  • So we're going to be probably using a service like [INAUDIBLE]

  • to automate some of the testing and deployment of some of our projects

  • for us.

  • And by that I mean, suppose you have the CS50 library, for example.

  • We ideally want to add some unit tests to this library that

  • checks that the functionality of the library actually works as expected.

  • And ideally, every time someone pushes to this repository

  • it's going to automatically run these tests

  • and indicate some failure if one or more failed or success otherwise.

  • Then by deployment I mean, hey, once this is all ready,

  • we can just push a new version of this repository--

  • sorry, new version of this library to whatever service

  • [INAUDIBLE],, for example, in case of it's a Python library.

  • COLTON OGDEN: On Friday, I'll be doing another game stream, so the memory card

  • game.

  • And then one of our teaching fellows, Nick [INAUDIBLE],, who was in the chat,

  • might pop in potentially.

  • We're gonna talk about [INAUDIBLE] machine learning,

  • some AI stuff if anybody's interested in that.

  • But as always, if anybody does have any suggestions

  • for particular topics or streams or anything

  • that you'd like for us to do on camera or program on camera

  • what not, definitely let us know because we have quite a few folks who

  • have different specialties around here.

  • KAREEM ZIDANE: Last question.

  • What is an organization on GitHub?

  • That's a great question.

  • An organization is a slightly different type of account on GitHub.

  • So for example, in CS50 we have the CS50 Organization in this case,

  • and that's because we don't want to host all the projects that we work on

  • in someone's account.

  • So an organization allows us to do this--

  • host more than one repository without actually hosting them

  • in one individual account.

  • COLTON OGDEN: [INAUDIBLE] has another question too.

  • KAREEM ZIDANE: I want to know about [INAUDIBLE]..

  • Is that inside the [INAUDIBLE] 50?

  • Would it let me allow multiple terminals?

  • Can I do something like that on PC?

  • I'm not really sure about the PC options.

  • There might be something like [INAUDIBLE],, which

  • is a terminal multiplexer in this case.

  • I used one here on Linux, which is indicated

  • by this really green bar at the bottom of the screen, which

  • I don't think we can see right now.

  • But [INAUDIBLE] is a terminal multiplexer.

  • Essentially, it allows you to create more than one terminal window

  • within the same window.

  • And yes, it exists on [INAUDIBLE].

  • But I don't think you need it really on the IDE

  • because you can always create a new terminal tab pretty easily.

  • But yes, it should be installed by default in the IDE.

  • So is that a separate account?

  • Yes.

  • The CS50 Organization is actually--

  • you can think of it as a separate account type that more than one of us

  • has access to it.

  • I guess you could create a new organization somehow.

  • Let's Google this real quick.

  • So GitHub actually has a very useful help guide here

  • that lets you know how to create a new organization.

  • COLTON OGDEN: Is that a premium feature?

  • Can you do that with a free account or do you need to have a--

  • KAREEM ZIDANE: That's interesting.

  • So if I go to Settings--

  • COLTON OGDEN: I guess maybe it would be like you could have public repos on it,

  • but private repos are probably [INAUDIBLE] premium account.

  • KAREEM ZIDANE: Yeah.

  • I haven't actually tried to create one before, so let's experiment with this.

  • Froshims.

  • If we go to Settings--

  • or is it Account Settings?

  • It's Account Settings I think.

  • Why did I go to repository?

  • Organizations here.

  • New organization and then--

  • COLTON OGDEN: OK, it looks like you can free,

  • and then you have to pay for the other ones it looks like.

  • KAREEM ZIDANE: So it looks like it supports unlimited public repository

  • for private ones you'd have to pay.

  • COLTON OGDEN: Cool.

  • TIL.

  • All right.

  • It's going to be about 5 o'clock.

  • We'll probably end up closing it off here.

  • KAREEM ZIDANE: OK, thank you so much for having me.

  • This was really--

  • COLTON OGDEN: Yeah, thanks for coming on and doing it.

  • If anybody is watching this on YouTube after the fact,

  • definitely come follow us on twitch.tv/cs50tv,

  • where you'll be able to join the live chat in real time and talk with us.

  • And then maybe we'll do some collaborative stuff in the future.

  • David [INAUDIBLE] in the chat, everybody.

  • [INAUDIBLE] you can say hi to him right now.

  • KAREEM ZIDANE: Hi, David.

  • COLTON OGDEN: [INAUDIBLE].

  • Kareem and Colton, thank you for an interesting stream.

  • Thanks for coming, Bella.

  • Appreciate it.

  • Thanks, David, as well, and thanks [INAUDIBLE]..

  • Thank you.

  • Very informative, says [INAUDIBLE].

  • Thanks, [INAUDIBLE] as always.

  • And then Nick says, thanks guys.

  • Powerhouse of the cell.

  • KAREEM ZIDANE: Thank you so much.

  • COLTON OGDEN: There we go.

  • All right.

  • Cool.

  • Thanks, everybody.

  • We're going to close out now.

  • And again as a reminder, we're going to stream again

  • on Friday where we'll do the memory card game.

  • Last word, Kareem?

  • KAREEM ZIDANE: That's exciting.

  • I want to thank you all, and see you next time.

  • COLTON OGDEN: Cool.

COLTON OGDEN: All right.

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級

GIT和GITHUB教程--Twitch上的CS50,EP。4 (GIT AND GITHUB TUTORIAL - CS50 on Twitch, EP. 4)

  • 1 0
    林宜悉 發佈於 2021 年 01 月 14 日
影片單字