Transcripts
1. What Version Control Is: So let's talk a little bit about Git. What is Git? Git is version control and what is version control? Version control is essentially a history control. It's like an undo. It allows you to go back into your project if you've done something you wish you hadn't done and want to go back to the way it was. Version control lets you do that. It's a time machine in that regard. If you've never seen the classic 80s flick back to the future, this is the time machine that they have and that movie. I'll be referencing it maybe once or twice and so if you haven't seen it, you got to go watch it. What Git is going to do is let you go back in time. It's going to store snapshots of your project at a given time and then as you go through your project and you commit more and more snapshots, you've got these different points in time as you can go back to, should you decide that you want to undo something. That's not all, that version control does though. What version control is really great at is managing the way that multiple contributors interact in a project. So here we've got three contributors. They're all pushing contributions to a central codebase or any project really or it's called the repository and this is the perfect or at least the latest version of your project. One thing you can see about this model here is that it's very left to right. It's one-directional and these contributors don't really have a great way to interact with one another and share code and things like that. As a contributor, if you want to experiment a little bit with your project, you'd have to make a complete copy of it and play around with it and then come back and push your contributions to the perfect version. Git as an answer to that, it establishes this idea of distributed version control and what this is, is a way to break apart that linear flow and introduce something that's a little bit more collaborative. So here you've got three contributors and not only are they able to push their code up to the repo, but they can also share it between one another. They can share with each other, they can push up to the repo, they can even pull from the repo, they can pull from one another but as you can see, this can get pretty confusing. Things are going all over the place and without some way to manage this, you can get into a lot of trouble on a project. That's where this workflow comes in, and that's where we're going to be getting to on this subject and lessons.
2. Get Git Up and Running: What I'm going to show you right now is how to get down onto your machine. Probably the easiest way to do that is if you go to Mac.GitHub.com. GitHub is designed to really great client to use with git. I'm going to go through a simpler way to use it, because there's a lot going on here and if you don't understand exactly what you're doing, it can get pretty crazy. I'm going to walk you through step-by-step in the terminal, which is the window into the inner workings of your computer. If you ever seen any 80's hacker movies, this is what they used to hack into the mainframe. But the easiest way to get installed is to download the GitHub client from Mac. Don't worry about opening the app, feel free to go in there and poke around. If you don't have any Git repos setup already, you really won't see anything interesting happening, but it does bundle all the Git software with it, so go ahead and install that. If you don't want to download that, you can just go to the official Git website, git.scm.com and download it there as well, follow the instructions, it's pretty easy to get it going. Once you've got it download it, you could open up terminal. You can either command space to pull up the quick Finder there, or you can go through your applications down the terminal, see the utilities terminal right there, and open that up. By default, it's going to drop you in your user folder. I make a directory called workspace, to hold a lot of my active projects. Let's go there right now, it's cleared out for this demo, but usually there would be a bunch of projects in here. So let's create a new directory and we'll call it first repo, there we go and I'm just going to put something in there. Let's open text edit, and we'll put a hello world, save that. Hello.txt, there we go, and all that's really doing is putting something into this directory so that we can make a Git repo for it. The easiest way to make a Git repo is to type Git init, and that's short for initialized. The first thing I'm going to want to do is get into that directory I created. If you've never used the terminal before, there are a lot of commands that lets you make directories, delete directories, make files, delete files, jump around the directory structure. I'll give you a couple of the basics in the course of this lesson, and these are things that come in really handy. The first one I'm going to tell you about is CD, which has changed directory. So I'm going to CD into work space, and what I just did there was basically said from my user. So if I get back to user here, user where are you? See this is tilde, that's the squiggly there. Tilde is your home folder, testy is the username for my test account here that I'm working in for this demo, and there I am little house and there's my workspace and I created first repo. So when I said CD workspace, I was in tilde, which is my home directory here, and I said change directory to workspace and there I am, and now I'm going to CD into first repo. CD, first repo, no space. Once I'm in there, I can type ls, which means list and I can see my hello file that I created, and now I've got a place to start my Git Repo. The first thing I'm going to do is say git init. Anytime I'm typing commands that Git is supposed to recognize, I'm going to preface them with the Git keyword there. I'll be doing things like git add, git clone, git commit, most of the things that only work in the Git program. Git init is the first one you're going to use. It initialized empty Git repository, so with that command, we're tracking a file. Now if I go and make changes to that file, it's going to be tracked by Git and that's the very beginning of your Git experience.
3. Staging and Committing: Let's walk through some of the basic steps that you're going to use while you're asking GIT to help you save changes to your project. We talked about this idea of taking snapshots in time of your projects in case you want to go back to them. Every time you take one of those snapshots, you're committing your changes to this GitHub repo. So let's take a look at what happens. There are a few steps that happen in this bidding process. So first you typing your code, you're creating new content, whatever it is that you're doing. You get several files together, let's say that you decide you're ready to commit. You've gotten to a place where your project is working, or you're at a stage where you're ready to draw a line in the sand as it were and take a snapshot in time. You've gotten to the staging part of your project, which you are going to do is say, hey GIT, I have these particular files I'd like to get ready to commit. You may not want to commit all of your files. So the staging process lets you selectively add what you'd like to commit. Then you'll move on to actually committing it. I like in these two stages to prepping something for shipping where you're packing it in a box, and when you commit your ceiling it up and you're saying, "Remember all these things, take a snapshot of this point in time." So every time you're going through and doing one of those commits, you're packaging up a point in time and having GIT to remember that for you. So now we've talked a little bit about that adding, staging, committing process, let's take a look at what that looks like while you're in the terminal working with GIT. I've made an update to the Helloworld file. So let's do a Git status and see what Git has to say about our project here. So you see these two red entries are hello.rtf file, which you would expect to be modified since we've been working on it, and then this other untracked file,.ds store, that is a system file that Apple uses to track the way you've got your folder setup and when you look at it in the Finder window, anyway, it's not the file you would typically submit to a repo. There's no need to pass that on to other developers. This is where that add process comes in handy. It's going to let you selectively add things to your repo rather than just whatever's in the folder because there may be this is a file you wouldn't normally see, it's going to dot before it, there are other invisible files that you don't normally see that could get committed without you knowing about it. So let's just do a git add hello.rtf, do a git status, see what happen. So here we go. You can see that hello.rtf is in green now and ds stores still in red, it's listed as an untracked file. So that's good. We don't want to track that one. The one that we do want to track has been added in staged to be committed. So now, let's go ahead and commit that file. When you commit a file, we need to leave some message, you need to say what you did, what code you're adding, I mean, not necessarily code, in our example, it could be a recipe, it could even be Photoshop files. You can get just about anything to your repo, which you leave a message, so dash m is shorthand for message. The message has to be in quotation marks, updated hello message.Then I'll hit return. I get a whole bunch of stuff back from Git. You don't really have to pay too much attention to that as long as there's not an error then that okay, so now I can do Git status. All I see is by ds store file, it's on track. So that's little step through there, I worked on it, I added it, and then I committed it, I have this file is stuck the file on a box saying, hey, this is what I intend to commit. This is what I intend to leave behind and then I wrap that box up and left a message on it, and it's taken as a snapshot, it's a point in time that Git is going to remember for me. There is one other thing I want to call your attention to. If you go to do a commit, let's say we added something more here, we go through our process again. There we go. I do Git commit, if I forget to type the dash m shorthand, Git is still going to want a message for me and here's what's going to happen. I'm going to go into this thing called VIM and this is one of the oldest text editors out there, it goes way back, and it can be a little odd to use. So you start with this message, it says please enter the commit message for your changes. You can read that pretty well. What you would do is, something like this you say dated [inaudible] You'll notice that I'm an insert mode. This is word insert at the bottom. That's going to let you type. When you toggle out of that, you're just in a read mode. To get out, you type a colon. Oops not there though. You hit the escape key to get out of insert mode. There we go. Type a colon and write w for write, and q for quit. You may want to write that down because if you ever get warped into this VIMworld, it doesn't work. If you haven't spent the time, it can be difficult to get back out of, and it can be frustrating. So write down colon WQ. Remember that, let's press enter, I'm taken back to my terminal window, and I get that same message that I'm accustomed to seeing when I do a git commit dash m. I just want make you aware that in case you accidentally get warped into that VIM universe, we want to escape colon WQ, return. That will get you out.
4. Creating Alternate Futures - Branching and Merging in Git: Up till now, we've talked about what version control is, what Git is, how to install it, how to stage and commit files. We're going to move on and talk to some of the really great key features of Git, the concept of head, and then the practice of branching and merging. This gives us a chance to use our excellent "Back to the Future" time travel metaphors too. So here we go. You're familiar with this. We're going along, we're making snapshots at key points in our project so we can preserve those states. If we take a look at this timeline, it's called master. It's the default timeline that you get when you initialize a Git repo. You can see here if I do a Git status on branch master. So as we go along and make these changes and commit them, we're safe guarded against a real sticker by the ability of Git to let us go back to a previous point in time in our project and start over. Now you see the little triangle I popped up. That's where we are in this timeline. That's concept of head in Git, it's your time machine, it's where you are now in your project. As you go along, you make changes. The head is where you're at right now. So let's talk about branching. This is where we get into our Back to the Future metaphors. Back to the Future centers around Marty McFly, a teenager in 1985. His parents are shmacks and things aren't going that great. He wants to borrow the car to take his girlfriend out, but his dad's boss has borrowed it and wrecked it. So in the movie, what happens is Marty goes back in time to 1955 because this could have all been averted if his dad had only asked his mother to the enchantment under the sea dance and they'd fallen in love. He travels back to 1955 and sets up a set of circumstances in which they do meet at the under the sea dance and had their first kiss and fall in love. He sets up an alternate future and then when he gets back to 1985, everything is awesome. So in our projects, we do things like that. We start a new branch and at this branch is our alternate future. We work on our project, everything goes great and when we're at a point where we want to merge it back into the master branch, which is our perfect branch, we do that using a merge. So now in Back to the Future, we're back to 1985, everything is going great. George is a successful writer, Loraine is still in love with George, and Marty has an awesome truck now. This pattern of branching and merging is at the core of good Git workflow. It allows you to have the freedom to experiment, to try these new features without merging up your master timeline. You can see this pattern where you go up, you try something new, it works, you put it back in, you go up, you add the next feature, it works, you put it back in. That's pretty much the core of good Git workflow.
5. Terminal Time Travel - Moving HEAD Around + Branching and Merging: Here we are. We're going to take a practical look at what we just learned. We'll look at moving the head around, at doing branching, and doing merging. The first thing I'm going to do is, let's see here. Do a git init and set up this git repository. I started with a fresh one for this example and I'm going to make a hello.txt file. I say touch hello.txt and you can see here in the Finder window that I've got to git repo and hello.txt. Now you may not see this.git and this.DS_Store. I've chosen to show hidden files, there are system files that normally you won't see as a user. If you Google that, there's a really easy if you can copy paste that command into your terminal window and it'll show those files for you. I like to have it on. The first thing I'm going to do is set up a.gitignore file. There we go. Now, I can open both these in Sublime Text. There we go. Sublime Text is a great text editor, they have lots of plugins for it. It's also free for a trial download and I recommend using it if you want to just try something out. Start with gitignore. The first thing I put in a gitignore file and what this file does is it tells git not to track the files you explicitly list here. Usually I add gitignore two the gitignore file. Then secondarily, this.DS_Store, that's a system file that Macs used to track changes in the folder and it's enough of an explanation to say you don't need to track it in your GitHub repo. I've got those two things in there and now I'm going to start with my hello.txt. What I'm going to illustrate is a series of commits and then how you can move around in those. Let's say I've got a great idea for a poem and I'm going to save this. I like these two lines a lot. Let's make a little diagram down here. We're going to say this is our first commit. I'm basically going to start building out a little timeline just to illustrate where we are in this thing. I'll save it, go over here, do git status, and it says I'm on branch master. It's my first commit and it's a hello.txt is the untracked file. We'll do git add hello.txt. Now we can commit, git commit - m for message. I'm going to say, adding the first two lines of my new poem. There we go, so I've committed it. Now I can checked this and see git has a command called log. If you do git log, you will see the commit you just made. It's got this crazy long commit number that's unique to that commit and it says who did it, when they did it, and then gives the commit message. This is great when you're working in a group because you can track all the different commits and get a look at the history. Let's do a little bit more on the poem here. "World so high." Yeah, this is really feeling good, I'm liking this poem. Let's commit again, let's make a second commit. I'll call this one B and I'm going to do a little arrow to show where we're at here. Add this one, do git status. Modified hello.txt, so we'll do git add hello.txt, git commit -m for message, adding the third line and then we commit that. Let's git log it again and see what we have. There's our first commit here, adding the first two lines of my new poem. Then here you see the one we just did, so it lists them from the most recent down. Everything, okay. So far, so good, let's keep going. We have another line of the poem. I'm going to commit this one here, it will go through the usual git status, git add, git commit. Let's git log it and seen what we have here. We have all three. This should all be making sense and really probably getting a little bit boring write now. Let's say though that I'm having second thoughts about this last line. Maybe I'd like to change it, but I've already committed it. No, what can I do to move back past this commit? Well, I can go get reset and then here is a term you'll recognize HEAD. I could take the HEAD and reset it to a different point on this timeline. I show that by saying [inaudible] which is a little squiggly up in the upper left hand corner by the ESC quay on Mac, anywhere. That says, take the head and go back one, go back towards the last commit. There I go, now my changes are onstage after that reset, and you can see nothing's really changed here though. But if we look at the git log, you will see that I have the one that says adding the first two lines and adding third line. But that commit is gone. So we've undone that commit. We've gone back in time on our little time machine called head. Now let's say that I don't want to keep that last line at all. Let's do this. We'll change this to something that makes a little bit more sense. There we go. I save it. Then I'd git add and I'd git commit and I git log and you can see it. The fourth line, there we go. Now let's say I'm not happy with that either. If I want to blow away this whole last line, this whole C commit that I've done. I'm not worried about keeping any files. I can do a git reset - -hard, and then give it an index for the head, HEAD~1. What this is going to do is blow away everything in this commit and move the head back to the last commit. So once I hit return here, you will see the text change over in text pad or sublime text. Do that and when I go over here, boom, gone, erased from history. Let's try sum branching now. Obviously, I'm having a lot of trouble with this next line and I'm using a ridiculously over-simplified example here. But this is mainly because I want to focus on how to move around with this timeline rather than practical applications of committing code right now. Let's do a branch. This is a perfect example of when you might want to use a branch if you're trying to avoid messing up the perfect three lines you have so far. We go open a branch here. Do this, do a git checkout -b. We haven't checked out checkout yet, so let's checked out checkout. Checkout is how you move between branches and git. It can also be used as a shorthand command to create a new branch. So if I say git checkout -b, which is shorthand for branch, and give it a name. We'll call it fourth- line. See this, I've switched to a new branch, fourth- line. Here I am, write here. A matter of fact, let's call that A, save it and do a git status. It shows that it's modified mainly because I just switched that from a C to an A. So lets add, look at that, that feels pretty good. Lets go ahead and commit this. Save first. We see, okay. I'll text git add hello.txt, git commit -m, "I think I have it figured out!" There we go. Let's do git log. You'll see all my last commits here, including the one in the new branch. Now we're happy with the poem. But we're up in a new branch. Why don't we merge it into the master branch. We do this, now I'll put this diagram is worth the waited. We're going to try to bring this back down here and merge it and then we can keep going. This pattern might look familiar two you though, because this is exactly what we looked at in the slides there. We're going to go right here. Save that. Let's do git. Well, now we've made changes, so it's going to want us to commit again. Add git commit, that's a pretty lame commit message. Don't do that. Now we can git checkout master. See we're going to switch to branch master. Now watch what happens when I go over to hello.txt. It's going to change back to where we left off when we started our branch. Boom. You see that? So master is not aware of what we've been doing on that other branch, on our alternate timeline. To bring these two things together, we're going to do a git. We did checkout, we're going to do a git merge. What do we call that last branch, fourth-line. What that's going to do, git is going to go make a copy of that branch and merge it into master. This is what I would do if I was happy with what I had done in my branch. Let's try it. Now when I go over here. Boom, we've got everything in master. Then circle of life continues. I can go on here and etc. That's the basics of git workflow right there. You create something, you commit it, action, backup. You branch, you create something, you commit it, you merge it back in. If I was going to keep going in this fashion, I could go up here and start another branch here. You get the idea and keep going that way. That's the basics of the workflow. It just gets a little bit more involved when we start adding GitHub and stuff later. Not much though. If you get this, you get git. How's that to a half or a line to wrap it all up.
6. Set up your GitHub Account: It's time to get your own GitHub account. I just went to the GitHub website and filled in my information here. Now I've got my fledgling account. Just get the free one for now. If you want, you can get a micro account. You can't have any private accounts on the free one, they all have to be publicly visible. If you're going to be working on anything that has any confidential material or anything you don't, which you'd like to be able to hide from the outside world, then you're going to have to pay for it. But for now, I'm just going to finish this up here. Here I am. Let's see about this, let's say, "No thanks." This is your dashboard you get, and it's got a little step through here that just takes you to the docs and says this is how you do this feature, this is how you do this. We're going to do that right now. It's worth pulling through definitely. Certainly learn something. The first thing we're going to do is walk through how you create a new repository. Now you did it locally before with Git init in your directory and workspace. Now we're going to do this up in the Cloud on GitHub and show you how you can bring it down to your computer. You can also start locally and then push it up to your GitHub. It started repo that way. I'll cover that in a minute. But this is probably the easiest way to get going. You click the big green button and good old GitHub says, "What do you want to call it?" This is going to be the repo for our project. I'm going to call it cookbook. This has to be public and I'm going to click "Initialize this repository with a README." I'll show you why in a minute. There we go. Here is my brand new cookbook repository. This is the README file by default, when you get to your GitHub account page. You can check this out by going to any other GitHub repo out there on the Internet. It shows this README.md file and MD stands for markdown. Markdown is a shorthand way to write HTML. GitHub understands it and will parse it and write it out like this. We're going to be working in this README file for this class. Go ahead, get yourself a GitHub account setup, and we're going to go back to the slides and talk a little bit about the ways that we'll interact with GitHub and start sharing content with one another. Actually, we're getting close to the end of the lesson, we've got a few more units to go, but I'd say we're past the halfway point and this is where it's really going to get fun. Get your account and I'll see you in the next video.
7. Cloning & Forking - An Overview of GitHub Workflow: Here we go. We're going to take a look at GitHub. GitHub is essentially just a Git repo that's up on github.com. GitHub has put together a set of features that help you work on team-based projects. It's also a social network for open source projects as well. Two of the main components of GitHub workflow are cloning and forking. Cloning is basically just making a copy. It's like what it sounds like, what you want to do is get things from your GitHub repo down to your local development environment so that you can work on them. When you make this copy, GitHub automatically names that repo origin. It's a remote. As you can see, it's away from your local development environment. Now, you still have a Git repo like we've seen before locally and you can tell it about any number of remotes. In a project, you might have a remote for deploying staging code, you might have one for deploying production code, you can even give other team members computers a remote address and push code to them. These are called remotes. Here you'll see a little bit different version of that branch, create, commit, merge, cycle that we've seen before. When we get to our commit and we're ready to merge it, instead of merging it back into our master branch, what we're going to do is push that content up to our remote and merge it up there. When that's been merged in with the master branch, we'll then pull that new master branch back into our project and start that cycle again. What if it's somebody else GitHub repo? You won't have access to it. Unless, of course, you're an admin on that project. What happens when you try to push content up to that repo? Well, you won't be able to because you don't have access rights. In this condition, you will have to submit what's called a pull request. Essentially, a pull request is just a notice that you give to whoever owns that repo that says, "Hey, I've created this content. Will you pull it into the project?" The function that they serve is that it essentially keeps everyone in the world from pushing content into an owner's project without their permission. In a team-based project, it also gives an extra set of eyes to code that's being contributed that will generally code content. Someone else will have to review what's going to be submitted and okay it for inclusion. So it's a nice filter to keep things clean. A little note; when you submit pull requests, try to keep them as concise as you can. Don't make a ton of work for whoever going to have to review this pull request. Hopefully, the other members of your team will extend the same courtesy to you so that you're not having to read through a gigantic pull request just to include it into the project. Now, if that pull request is approved, the process continues in the same way we've seen. It would get merged into the master branch and you would pull that new master down and incorporate it into your project. Only now, it might contain submissions from other team members. So you would get not only your feature, but whatever other features have been developed while you've been working on yours. Forking is a little bit like cloning. It's just making a copy of someone else repo up there on GitHub. You start with their GitHub repo, you fork it, and now you have their GitHub repo and your GitHub repo. Forking works well when you want to take an open source project, make it your own, and take it in your own direction. On a project, I'll often fork the repo so that I have this added measure of review. I'll push my branch up there, review it, and then submit a pull request to the main repo. You get a little bit of GitHub magic when you do this. The two repos will be aware of each other. GitHub has developed several features that make reviewing and merging code or a content. I use code and content interchangeably. It'll do things, like let you know if the poor requests can be merged easily or if there's some problem. You'll see a little bit more about that when I walk you through the live example. We're going to put this whole thing together and you'll see how it works, the local and the remote. It's going to incorporate all of the things that we've talked about so far. We've talked about Git, about distributed version control, we've installed Git, we've initialized a Git repo locally. We've looked at branching, staging, and committing. We know what HEAD is and we know what merging is. We've talked about pushing, what remotes are, cloning, forking, and pull requests. Let's see how that whole thing works together. We're going to start with a master project repo. We're going to fork that and have our own repo, which we'll then clone down to our local environments so we can work on it. We'll do our work, we'll push up to our fork, and then submit a pull request to the main project repo. Once that's okay, we can pull it back down locally with any changes that have been submitted by other team members. That cycle just repeats and repeats. So get ready. We're going to do this live now. After this next video, you should be ready to contribute to our project.
8. Cloning a GitHub repo - Live demo: Let's get started with a live demo. Here I am in my fresh GitHub repository that I set up, especially for this project. I'm calling it 'cookingwithmarc'. This is where I'm going to keep some of my recipes. I don't have any repository, so let's start a new one right now. We'll call this toast, and I'm going to put my recipe for toast in here. It's going to default to public. If you want a private repo, you have to pay for it. So we're going public since I want to share my toast recipe with the world. I'm going to initialize this with a README file, which is a good idea. At least the repository has something in it. Then just click the big green button, and there we go. Now, we're going to go over here. I'm going to clone this down into my local development environment. You get clone and paste that address there. Remember the remote from the last series of slides? This is the remote here that I'm in. So I had to clone this down to my desktop, and as soon as I do this, Git is going to write in its remote address. Let me just do it, it'll make more sense. So it has brought it down, let's check the Finder window here, and it should tell us, sure enough, there's toast. So if I say git remote, I need to change directories into the actual repo now. I do this every project. CD into toast. Now I do git remote, and it's going to show me origin. So that's the remote I have it, names at origin by default, you can change it to anything you want. I like to follow the naming convention of origin and upstream, just because it helps me keep it clear in my mind where exactly I'm pushing content to later on. Now I can do a git remote -v for verbose. That flag means be verbose, tell me more. Then you'll see that origin has this address, cookingwithmarc/toast.git, which is what we copy pasted in. So you can use these origin or these remotes. You tell your GitHub repo these addresses, and it will let you push content to them. I can push up to my GitHub repo. I can put the address of somebody else's repo in there, and push to it. That's a really neat way. Is at the core of that notion of distributed version control. Let's take a look at the README file, we're going to make some edits here. This is a Markdown file, md stands for Markdown. It's a way of writing HTML in shorthand. So if you're familiar with H1, H2, H3 as header levels, even if you've only worked in a word processing document application before, you're familiar with that idea. So you can tell Markdown to render an H1 with one hashtag, two hashtags as an H2, three as H3 etc. Here is my ingredients. Let's do that as a H3. Any place that have a line break, is going to render as a new paragraph. Let's see, do I have my toast direction here? I save that. Let's go over here, and we'll do this whole branch create stage commit process. I've already started creating without starting a new branch. So let's start a new branch. We'll call this recipe output. Git checkout -b for branch recipe. So if we do a git status, it says the README has been modified, and you can see right here when we started the branch, we carried that modified README over to it. So I'm going to say git add, README.Markdown, do a git commit -m for message. Quick git status until everything is cool. So now I'm going to push this up to my origin repo. So I'm going to say git push to origin. What do we call this branch? Recipe. There we go. GitHub is going to ask me to authenticate with the username and password every time I push. Unless I have SSH setup, which is an added level of security. I'm not going to go into it right now, that might be a topic for another class. You came Google up how to set up SSH, it's not that hard. So if you're typing your username and password over and over, google that up and see if you can get it to work. That's usually what I use. So let's go up to the GitHub account now. You'll see that I've got a pull request here. So as soon as I push that content, GitHub recognized that it was an incoming new branch, and it says, "Do you want to do a pull request for that?" Sure. Let's create the pull request. So now it's going to tell me, you can merge this automatically. That's great, let's do that. Let's merge it, firm it. Great. So what it's done is the same thing we would do locally when we would merge back in. You go up in that little branch and then when you're done committing, you merged back into master. We've just done that up here in the Cloud in our GitHub repo. So you can delete that branch you push because it's been pulled into your master. Now, let's go down here. If we say git, I want to show you this. Our toast recipe is all in one piece. We're still on the toast branch. So if I say git checkout, master, watch what happens. Wow, it's all gone. So that branch has all of those changes, master doesn't have it. If we were working locally, we would merge the recipe branch into master. Well, we're going to do that from the GitHub repo instead. So I say git pull, and what pull does, is it goes up, looks around for anything new, brings it down and merges it with whatever branch here in. So git pull origin, master. There we go, and now we should have all those changes. So there's a loop through the hole, creating a repo, cloning it down, creating content, pushing it up, merging it and bringing it back down, and complete set that loop that you saw on the slides. So for the next video, I'm going to do the same thing with forking. It's just one more added little level of complexity honestly. What I want you to do is go try this, and get this whole circuit to work for you. This is your basic GitHub and Git Workflow that you would use on any kind of web project, or open source project, or anything like that. So if you can do this, you've got it, and the next lesson is just going to be a little bit extra. So have at it and good luck. See you in a minute.
9. Forking a GitHub repo - Live demo: Now, we're going to look at forking in GitHub. This is typical of the process you would go through if you wanted to contribute to a project that you didn't own. This is my personal repo up on GitHub. I have another browser open with our cookbook repo. While I'm logged in here as an admin in this browser, I'm not, but I can navigate to it. Let's go to github.com/gitforvisual. I can follow this person here, and I can also look at the repos they have. Since this is public, I can fork it. Here's the fork icon over here. When I do that, I love this animation here. I get a fork from GitHub. There we go. Cookingwithmarc/cookbook. This is going to be a copy of what's over here. See how they match up. Now, I need to follow the same procedure I did when I was cloning. I copy that URL, go back over here, make sure I'm in workspace and say get clone, put that in. There we go. Now I should have cookbook in workspace. There it is. Now I can take this README file and edit it. This is actually going to be part of our project. Once again, I've done what you're not supposed to do, which is start creating before you create a branch. Let me do that now. A quick git status is going to show us. Got to see into the cookbook. There we go. Git status. Git checkout-b, we'll call this branch tortilla. Git add the README.markdown file, git commit it with a message. There we go. Now I can do a git push origin tortilla. This is going to push my branch locally up to my GitHub repo. This is where we're going to see the GitHub magic come in with the fork. I do this. Now let's go look. Sure enough. There's my branch that I pushed up there. When I say compare and pull request, it gives me the option to create a pull request. I don't see anything here that says how to merge it. Because now I'm in Git for visual/cookbook. Follow that magical link from my GitHub repo to the one that I forked from. Now if I go over here to the actual Git for visual cookbook repo that I'm logged in as an admin at and look in the pull request, that's where the pull request shows up. Now I can review it and I can merge it. It becomes part of this repository. Let's go back here. There you go. As before, if I go git checkout master, this should all disappear. Boom. We've got to pull that most updated version of master down in to our repository. Git, pull. Wait a minute. Hold on a second. Let's look at our remotes. We've only got one origin. We need to add a remote for that original cookbook repo. Let's go back there. Copy the clone URL and say, "Git remote add upstream" and paste that in. What I'm saying is, "Hey git, I want to add a remote, I want to call it upstream." Again, I could call it anything I want to. But upstream and origin are two naming conventions that I stick to and that a lot of people stick to because it helps you separate in your mind where you're pushing this stuff. Origin is mine and upstream is the main canonical GitHub repo. I'm going to say "Enter". Now if I say git remote-b, it shows me my origin and my upstream remotes. If I say git pull upstream master, it's going to go up to upstream, it's going to look around for anything new, it's going to pull it down and it's going to merge it with my master branch. When I go back here, I should have it now. Boom, there we go. Now, I can start the whole cycle over again. If you press Command K, it clears the screen. I like to do that fairly often. I go git checkout-b. Let's say I want to make some tweaks to the way I wrote my recipe. When I start this tweaks branch, I've got the latest and the greatest master. If I were collaborating and this will happen as we collaborate, I will pull all the changes that have been added by other team members, as well as just mine. When I start a new branch, I bring all of those in with it. I've always got the most up-to-date version. I got a new branch tweaks. Let's go in here. I'm just going to make this a little update. Tell you what, I'm also going to put a line here to separate my recipe from everyone else's. Those are my tweaks. Git add is a trick. Git add. adds all of your onstage documents. If you have a lot of stuff open, it can get a little tricky. But if you're typically working on three or four files, which you will be if you're doing web development, this is neat and it's a piece of shorthand that lets you add several at a time without typing the whole filename up. Git commit-m for message, changed some text. It's a pretty poor commit message, but we're going to go with it. Now I can do a git push origin. We're going to call this one tweaks. I pushed that up, let's go take a look. Where's my repo? If I request for tweaks, it bounces me over here, I create the pull request, it can only be merged by project collaborators. Well, let's go over here where I'm a collaborator and look at the pull requests. There it is. I'm merging it as an admin over here. Now I can say git checkout master. I can git pull. Let's double-check this really quick. I'm in master, so my changes shouldn't be here and they're not. Since I do git pull upstream master, it's going to get the latest changes and this should now reflect the little changes I made. There's a couple loops through forking. Basically that's it. You're at the end of this class. You've covered quite a bit of material and you should now be able to set up your own Git repo locally. Set went up on GitHub and clone and fork. Those are the basic skills that you need to collaborate to a team project using Git. Congratulations, definitely run through this a couple of times. Then we're going to do the final video on what to submit for your recipe project, which you've pretty much just seen. If you can put a recipe up there, then you've done it. That's the whole objective. Not a lot of actual hard work as far as creating some artifact, most of the hard work you've done in this class is just learning. Learning how things work and learning the syntax and the protocol for contributing. Congratulations and I'll see you in the final video.
10. Merge Conflicts & Final Assignment: All right, everybody. Welcome to the last video for Git and GitHub for visual learners. I'm going to cover something really quick that you probably won't run into in the course of this project. But if you start using Git in any sort of team-based way, there's a good chance you might encounter what's called a merge conflict. You can see I went in and messed up the file so I could create this merge conflict. Basically what happens is, when you have people contributing and then pulling back down and re-contributing and pulling back down in that cycle, sooner or later somebody is going to alter some code on a line that somebody else did, and it might confuse Git. Git might not know which version of the two different changes to take. So it gives you a merge conflict. But it will do something helpful for you, it will point out where the confusion is. So right here you see a selection, where in one case somebody submitted the name Marc Nischan Esquire, and the other one Marc Nischan PhD. So Git has wrapped this up in a little comment. You'll see these distinctive pattern of greater thans and less thans split by a solid line. So Git is saying that this large number is the actual ID of the commit. So Git is saying, between these two, which one do you want to keep, essentially? So all you have to do is to fix this. I'm going to keep Esquire. Although, I'm neither an Esquire nor PhD. But that's a different story altogether. So I pair this down to be just the texts that I want to keep, and there was another one down here, looks like these spaces were altered. That doesn't make a whole lot of sense, we'll just get rid of that too. So now I can save this. Let's do a Git status and see what I get. Great. Git add. Git commit -M, message, solving a merge conflict. There we go. So it's a quick look at merge conflicts. Another option you have is to download a merge tool. I use P4Merge, it's free. It's pretty good. You can see in this picture over here, it basically lines up what's on the remote, what's on your computer, and what's in the branch that you've pulled down. It asks you to choose between the different versions, and it saves off the one that you choose. So this is a really neat visual way to go through these things. It lets you scroll through the whole document, and shows you all these different places where the errors are. I don't want to go into installing it. There's some great tutorials out there on how to install this thing. There's a lot of free merge tools. So look around, pick one you like, and you can get that running, I'm sure pretty quickly. So now what I want to do is run through a whole cycle. Basically, this is your final project. The whole cycle of adding a recipe, and committing it locally and pushing it up for inclusion in the master cookbook. So here we go. So here is my project, cookbook project. I'm going to add another recipe. This is pretty much what you would do. You'd begin by forking, cloning, and then starting out on a new branch. So I'm on master right now. I can check that by going to Git status. Let's do a Git checkout -B and we'll call this new branch, garlic. Because I'm going to add recipe for roasted garlic. So let's go down to the end of my last one. Right here, got a lot of formatted in Markdown. So we wont have to waste any time. There we go. So save it, and I need to add it, commit it. Now I'm going to push that up to my forked version of this. I'm using the naming convention of origin and upstream. Upstream being the original one, and origin being the one that I forked. So we're going to push these changes up Git. Push origin head. So push to origin where I'm at right now. There we go. Now as I go to my repo, here, cookbook, I have the option to do a compare and pull request, which I'm going to do. Great. It's up to date with the base branch, so I shouldn't have any trouble merging this in. So now I'm going back to this other browser where I'm logged in as the admin, and I'll look at the pull requests, and there it is. So this is what I'll be doing when I receive your pull request. I'm going to look at it, check the files, make sure there's nothing crazy in there. Now you'll notice these icons here. They let you see the full file. It basically hides things that don't have any conflict, things you've seen before. It makes it easier to scan the changes and not have to worry about all the text in between. Well, this all looks good. Let's go back and merge that. That's it. So you won't even have to do this step, all you really have to do is push it up, and let the pull request come through to this repo, at which point I'll actually add it to the cookbook. But what you can do when you go onto Skillshare for your final project, is just take a screenshot of your version, your profile of this. Just take a screenshot and post that as the final project. That should do it. Thanks a lot for taking this class, I really appreciate it. If you found it helpful, a positive review really makes this class easier for other people to find, lets it float to the top a little bit. So if you did find it helpful, please give it a positive review, and help other people find it. Of course, if you have any feedback, positive or negative, I'd love to hear it. So maybe I can make this class even a little bit better. Thanks again and best of luck. One last thing I want to tell you is that, I put up gitforvisual.com. As you can see, there's not a whole lot there right now. But what it does have, is this PDF that you can download. It basically is a cheat sheet that walks through this whole process that we've gone through together here in the class. That's something you can keep handy if you just want a quick reference for the workflow we've described. So there you have it. Once again, thanks a lot. I appreciate your feedback, and enjoy Skillshare, and Git. Thanks a lot. Bye.
Marc Nischan, Artsy people can code!
