Transcript from the "Version Control with git" Lesson
[00:00:00]
>> Jem Young: All right, so our server is up and running. We have it mapped to our process, we have it mapped to the port, it rewrites everything. So now's let's do version control, cuz version control means that I can make changes, I can push it the GitHub or Stash or whatever repository you like.
[00:00:17] You can pull it down to work on your computer because, at this point, we're just in a Node environment, the server doesn't matter anymore. Version control, it just records changes to a file system to preserve its history. There's Git, Subversion, Mercurial, is there anything else I'm forgetting?
>> Jem Young: Nothing?
[00:00:36] Everybody just knows Git? Fun fact, what does GitHub or not GitHub, I think Facebook uses SVN, Subversion, or is it Mercurial? Facebook uses a monorepo, they have one repository for all of their code at Facebook. Because Git literally can't handle as much code as they have. There's like a maximum limit on it.
[00:00:55] And I think Google has their own custom repo version control as well. Weird fact, does not apply in any form or fashion, but it's just good to know. This is our final exercise, we're gonna push our repository up to a GitHub repo. But to do that, we need to go through a series of steps.
[00:01:13] Because hopefully for GitHub, you have your SSH keys enabled, not a password. And for most people, you have SSH keys. If you use it at work, they probably force you to use SSH. But we're gonna create a Git repository, which we already did. We're gonna create an SSH key, which we know how to do.
[00:01:29] We're gonna add that SSH key to the authorized keys directory, which we've done. We're gonna add the SSH key to GitHub. We're gonna add the the remote repo, and then we're gonna push it all. That was trickier than we thought it'd be. It was trickier I thought it'd be.
[00:01:45] And I've done this before, and it's still like, what a hassle. So let's walk through it now, because this is the final step. And once we do this, what we can do is we can code on our local machines. We don't need log in to a server. So that means we can use our IDEs, all the tools we wanna do, we can spin up the Node server locally.
[00:02:03] And then we can just push that all to GitHub, and then when we log into the server, we can pull it down. And then restart our server and then all the changes will be there. And generally, you're not gonna do any development on the server itself. So this is actually a kind of important step, but let's walk through on how to do it.
[00:02:19] So the first thing I did was I created a git repository. And I made this one. It's probably private right now, cuz that's what I always use by default. So don't go there, it won't mean anything. But what I did was, I went to my home page. And then, I forgot actually how to create a Git repository.
[00:02:41] Here we go, and I said New repository. Then you call it something Public or Private. If you don't have the Private option, you probably don't pay for GitHub Pro. That's okay, you don't need to, you can make it public. It's usually best to initialize this repo with a readme, it makes it easy to pull in.
[00:02:58] And add a .gitignore, if you haven't already, for node. So it's gonna ignore those node_modules, so you don't have to commit those every time. If not, we'll write one, or I'll show you how to write a .gitignore really quick. But generally, you don't wanna push your node_modules, cuz they can be megabytes and megabytes and megabytes of data, when we have NPM to do that for us.
[00:03:19] And then add a license if you want. And I already made a repo, so I'm not gonna make another one. Everybody, we got this far, right? Okay, next step was create an SSH key. And to do that, I'm gonna switch to cd ~/.ssh/. And then we're gonna use that command we used earlier on our other computer, but it still works here, ssh-keygen.
[00:03:47] And I've already made an ssh key, I'm not gonna make another one. But the steps follow is standard. You can just use id_rsa, because, it's a new server so you don't have any SSH keys on there. Unless you were just making SSH keys for fun, not going to judge you.
[00:04:02] So once we add that SSH key, I apologize, I made a mistake. We actually don't need to add it to the authorized keys. That's only if we wanna add SSH in using that server. So I'm gonna take this line out. I apologize. It's a work in progress. But because we created that id_rsa, it's the default key.
[00:04:20] When we use GitHub to SSH and push our files or pull our files, it's automatically going to look at this default. So we don't need to do anything to add it to the key chain or anything like that. Everybody, we're good so far. Didn't lose anybody? We generate a key.
[00:04:36] It gets a little trickier here. What we need to do is we need to add the SSH key to GitHub. And if we click this link, it'll take you to the Help page explaining exactly how to do it. But the way we do it is, I can go, just click my profile icon on any spot, go to Settings, go to SSH, and I can add a new SSH key.
[00:05:01] And just like we did last time, I'm gonna say cat id_rsa. Remember, it's the public key, .pub.
>> Jem Young: Good so far. We all got this far. And we can copy and paste that. And we put it in here. I've already done it. I can do it again, but there's no point to it.
[00:05:23] I give it a title for whatever you want, full stack front end. Delete me key, fake server key, doesn't matter. So you add that SSH key in. Then you'll have a new SSH. So this allows us to connect to GitHub, instead of using a password. Where you might have got hung up on was this part.
[00:05:42] And it's subtle, and you've probably done it and not even realized it. We need to add the remote to our new repo on our server. But we wanna use the SSH one. If we use HTTPS, it's gonna ask us for a username and password every single time. That's a hassle.
[00:05:59] And again, we generally don't wanna use passwords, we use SSH. So all this happens in the background. Now, most of you probably work with some sort of version control in your day to day job. And you probably have this all set up by default, and you didn't even realize it.
[00:06:12] But like I said, this class is going under the hood and seeing exactly what's going on. So use SSH. We wanna copy that over. So now I'm gonna switch, I'm still on my server. I'm gonna switch back to var/www/app/, and I'm gonna say, hmm, I have a repository, cuz I can do git status.
[00:06:33] And I know I'm in a repository. So what I wannna do is git remote add origin, I think that's correct. I'm gonna check the docs just in case. Git remote add origin, yeah. And I paste in the git config file that I pulled from GitHub for my new repo I just created.
[00:07:00]
>> Jem Young: Makes sense? Everybody with me so far? One thing, I already did this, so I had to make sure my instructions worked. One thing you're gonna run into is you're gonna add the remote, you can say git remote -v. Just to verify that you had it correctly, you probably did.
[00:07:17] Cool, one thing is we're gonna do git commit. And if you do git commit, it's gonna throw something in, like you need to configure your username, your global username, and your global name. That's just so when you push, when it lands on GitHub, there'll be someone attributed to it.
[00:07:31] Not some random person. You don't have to put in your real email, you don't have to put in your real name, be whoever you wanna be. But it's just so later when you're pushing, you know exactly where that push came from. So sometimes it's better to say git config.
[00:07:46] Jem dash, my own server, wherever, doesn't matter. It just tells you where it came from, rather than your home computer. So right now I'm gona add a .gitignore file just in case you didn't. So I can say vi .gitignore.
>> Jem Young: And there's already one in here. That was created automatically when I created this repo.
[00:08:11] But if your gitignore is blank, no worries, you can just say node_modules/. Yes?
>> Speaker 2: [COUGH] But if you've already commited, if you've already pushed and you didn't have that in place, don't you wanna blow those away first? Before adding it to your git commit, or .gitignore? Cuz otherwise you won't be able to-
[00:08:40]
>> Jem Young: You'll be stuck.
>> Speaker 2: It'll be ignored forever.
>> Jem Young: You could manually go on GitHub and delete that file, but that's not preferrable. So what you wanna do is before you make this ignore, you can comment it out. So this is for people who have already committed and they pushed their node_modules up to GitHub, which is fine.
[00:09:01] But what we wanna do is wanna delete those node_modules for now, then commit. And that commit will go up to GitHub, it'll remove the node_modules, and then we'll comment this back in. And if this falls under Jem's bad, it's the end of the day. I should have added this to the instructions to use a .gitgnore.
[00:09:17] But just in case you haven't, you can go and add it now. And .gitignore is great because, well, it ignores log files, all the dot files, things you don't actually need to commit. But just in case you haven't, that's what .gitignore does. But I'm gonna write quit right now.
[00:09:32] And I'll modify the .gitignore. So I'm gonna commit. So I can say git commit -am, is just adding everything that's being tracked, and it's just anything that's been modified. git commit Modify git ignore.
>> Jem Young: And then I can push. So I can say git push origin master. If you ran that commit command and it's saying you need to configure your username and password, just go ahead and do that now.
[00:10:04] You only have to do it one time.
>> Jem Young: And, we just pushed up.
>> Jem Young: Did anybody get stuck on any part? I will go back over it. Git can be tricky.
>> Speaker 2: I just created the .gitignore. But I commented out because I still have to blow away, my stuff.
[00:10:28]
>> Jem Young: Yes. Do you remember how to delete something?
>> Speaker 2: Well, it's rm.
>> Jem Young: Yes, but because we wannna delete everything, we use the recursive. So we say, rm -rf. Which is very dangerous [LAUGH]. Again, you're removing files, there's no trash can, it's just gone. But if you accidentally committed your node_modules, ignore that line in .gitignore, and then delete your node_modules.
[00:10:49] Commit that, and then push it up. There is an entire course on Git [LAUGH] taught someone much smarter than me. We will link that out. Cuz Git will get really messy. But we're okay for now. Okay, so you push origin master, the push should have went through to GitHub.
[00:11:11] So when we go back to GitHub to that repo.
>> Jem Young: We see I committed these things and now they're available for me.
>> Jem Young: Did everybody get this far? I know we're taxing, we have moved from Nginx configuration to Git tweaking. But now that I've pulled up, I'm gonna clone this repo again.
[00:11:41] And on my local machine, I'm gonna move into, I think I have a projects folder. I do have a projects folder. Is there one called Full-Stack-For-Frontend? I do. I've already cloned that, but I'm gonna remove that.
>> Jem Young: So in any sort of working folder you have, any sort of UI folder, do git clone.
[00:12:11] And we're just gonna, oops, I don't know why that didn't copy.
>> Jem Young: And I'm going to clone this. And git clone, paste that in. Did I not delete that? I did not.
>> Jem Young: Cool.
>> Jem Young: Now, we're gonna clone it in, for real this time. And all we're doing is we're pulling down what we just did.
[00:12:40] And if I wanna go into fsfev2. And now I can open that up in VS Code.
>> Jem Young: And now I have my app in a much easier environment, that's easier to modify. And now I can modify this app at will, like add semicolons. I don't know why, because I like semicolons.
[00:13:05] I can do whatever I want. I can commit this, push it up, and then on my server, I can just git pull, and pull that in, reload my server. And now I've modified my app fresh, and I can share this out with a bunch of people. So ten people can work on my app now and then run against the server.
[00:13:21] If we wanted to, I don't know, if we'll do that even tomorrow. But if you wanted to, we can set up a cron job that automatically pulls in the latest changes. I don't recommend doing that. That's a surefire way to get yourself into a corner if someone does something weird and then takes down the server cuz they configured something incorrectly.
[00:13:36] But for your own development server, it's a good way of doing things. That's how I do my jemyoung.com, it's configured like that. So I do development locally on a Python server, I push it up, and it automatically pulls it in once it's ready to go.