In this tutorial we are going to be talking about Git and GitHub and looking some example work flow, this tutorial is for people who don't even know what git and GitHub are but have heard about it and are kind of interested or people that kind of get the idea but find starting off a little intimidating, because it can a little intimidating starting with Git, there's a lot of features and it can be slightly confusing. In this video, we're going to go through some basic work flow and create an example project that we will manage and make some changes to. Let's get started.

Git is a version control system tool. That just means that we can track the changes that we make to our coding project and we can roll back to those states at any point in time and perhaps branch off to develop new features that can then be merged back into the major project. Let's jump onto the whiteboard and I'll show you what I mean. In Git we talk a lot about repositories and commits, so let's just imagine that this is our repository and a repository is most often used to house a project.  It can hold multiple projects, but in this case, let's just think of the repository as our project. Within the repository, we have the project at the current state, so this is the project as we've just finished coding it, lets say we are making an automatic coffee machine, so this is all the code for the coffee machine, the grinding, the brewing, the extracting, the heating, all of that code is now represented by this dot which represents the project at that point in time. Now imagine that we found a bug in our code and we wanted to fix it, well we would go into our files and make the relevant changes to the code and then we would save our project, but, using Git we would also create what is called a commit, and all a commit is. it's kind of like a snapshot in time of your project, so this was our version of our project that had a bug; so we found a bug we wrote some code and then we fixed the bug and created a new commit. Now this point in time is the most up to date version of our project so this where we are right now but if we found that, actually, the code we were writing did more harm than good, perhaps it broke some other features,  we can always roll a project back to this point in time. Now because a repository contains all of this information, this means that when ever you have a copy of a repository you not only have a copy of the project as it exists now but also all of the projects history, so if you need to, with a repository you can roll back to changes that were far in the past and branch off from there with your own features or fixes. This means that anyone with a copy of the repository has a copy of the entire project and its history.

That's quite enough of the whiteboard, lets jump onto GitHub.com and we will get started with a working example. We will make a repository, put some files in it, make some changes do all that good stuff and we will even copy the repository onto our local machine so we can see how all that interacts. So if you go over to GitHub.com, I'm going to create an account for this tutorial so I'm going to choose something pretty mundane and an email address and a password. Okay, so that's as easy as it is signing up for GitHub, GitHub is just a web based version of the Git control software. So this kind of gives us a pretty looking interface on the web for managing our repository. So welcome to Git, I'm going to use the free plan, which means that my repositories will all be public, if you want a private repository there's a monthly fee. So continue through that, this looks like a survey which I'm just going to skip for now. Okay, I'm signed up for GitHub, here is my GitHub account and we can see that there is a guide here and we can start a project from this button, but let's just go into our profile and do it from there.  

So this is my user profile with default profile picture, so I can go to my profile and I can create a repository. So I can go to Repositories, this tab here, and create a new repository. So first I have to verify my email address, so just go over to my Gmail account, verify that address, Perfect! Play the waiting game. Okay, back to where we were, so I'm going to close that original tab and go through those steps again. Profile, then over to repositories, and new repository. We can create a repository from within this interface and that's kind of like starting a new project so I'm going to call my repository Demo, it's a Demo repository and of course it is public, as I am on the free plan, I'm going to initialise it with a readme, and we will see why in a minute, oh and there's a description so this like a one-liner of what this repository is. A demo repo for the beautiful internet people. WE often shorten repository to the repo. Okay, so I am going to initialise with a readme, I won't use a GitIgnore or a license for this, they are slightly more advanced. And here is my repository! So you can see the first thing we are looking at is a list of all the files, in the repo, in this case, theres only a readme, because I initialised the repo with a readme. And by default, we often see the contents of the readme just below that list, so that a good landing page for anyone who is coming to the repository, this is the description of what it is and what are its features. So let's create a file.

We can create a new file, and because this repository - we will stick with the coffee machine for instance, lets just write some dummy code for if we were programming an automatic coffee machine. So what do we need to do, we need to start, grind beans, heat water and we need to extract coffee. Okay, that looks like a reasonable automatic coffee machine, scrolling down to the bottom this is where we commit our changes. So when you work in the web interface, every change you make is a new commit, and commits have messages attached to them that describes the commit and the changes that were made, in this case the first line of the commit, which is this first box; it's most often filled with a directive like "Make new file" or "Fix Bug" or "Debug Code", so I'm going to leave that as the default make new file, or create new file, actually no, I'll say "Create coffee script", okay. And in this second box, this is where you can add more long winded descriptions of what you have done, if necessary. I'm going to leave that blank just now, because it is a very simple commit. We will leave this default as commit directory to the master branch, we will come back to that very shortly. So I'm just going to commit the new file. Oh no, is there something that I have no fulfilled? Oh, I need to name my file! Of course I do, I am going to name this "Coffee", alright good one, I'm sure there was someone screaming at their computer just then. Okay commit the file directly to the master branch.

Back at our repo directory and you can see the coffee file has appeared!

So now that we've created a file we have actually created a new commit, and if we looked at the commit tab we can see that we have 2 commits so we can click on that to see the commit history. And it's quite simple so far, we have the initial commit, which was the repository being created and then after that the create coffee script commit. So I am just going to go over to the whiteboard and we will keep a bit of a map of what's happening. This will be useful for later. So remember I committed directly to something called the master branch, so I will just label this as "Master" and then we had our initial commit, which i will call "Init" and then I created the coffee script. So this is kind of like our road map of the history of the project, "Create Coffee". Okay so now if we were to modify coffee, let's just have a bit of a thought experiment, we could open up coffee again and modify it, so let's just quickly see how that would be done, with an existing file, so we could click on coffee and we could click "Edit this File", so I want to include some more features to my automatic coffee machines so we have extracted the coffee, I like a flat white, so I am going to heat some milk, and I am going to pour all and now it has gone from being a shot of coffee to now let's say a flat white. If I saved this change directly to the master branch, we would have more of the same and this master branch would just grow and grow and we would have a very linear looking timeline, but a good philosophy when working with git is that every new idea or feature you explore or direction you go in should have it's own branch. A branch is exactly what it sounds like, rather than repeatedly committing to the master branch which isn't a very elegant approach because it kind of hard to manoeuvre, instead of creating features down here, we can branch the project off and create features down here. And the reason, one reason that we do this is because it is then much easier to manage different people working on different things or just yourself working on different features, but what is most important is that if you want to share your project with anyone when they go to your GitHub repository the master branch is what they are going to see by default and this means that if you have code that is kind of broken and isn't working as it is under development on your master branch, it means that anyone that is interested in collaborating with that project, the only thing that they are going to get is the broken version of that project, they're not going to get the most recent stable version, so this is one of the reasons why we branch. So I'm going to develop those new features for my coffee machine but I m going to do it in the development branch, you can call this whatever you like, I'm going to call it "Dev" and for simple projects that's kind of the structure that I would use, Master and Dev, so you can have this sandbox called dev that you can develop new features and changes in and then roll them into Master when they are finished. So let's create this branch.

I'm going to go back to the repository, I'll abandon my changes, and you can see that we have this branch tab here, and we are currently on the master branch, now we could find other branches but we can also use the branch to create a new branch. So I'm going to create a branch called dev and create that from master, so now dev and master are essentially at the same point in progress. You can see now that this branch has been, I'm now on the dev branch, so i can go into my coffee script I can edit it and i can say, "Heat Milk and Pour". So I have included my new features into my development branch and I can say, "Add Milk Feature" and you can see now I am committing directly to the dev branch. So if I commit changes here, this is now what our project looks like, we have master and all that can do is make coffee, but now the dev branch exists and it can also heat milk. Now we can stay on the dev branch and we could make commit, after commit, after commit as we develop and debug our feature until we're really happy that it works well and then we can roll it back into the master branch so that we can share it with other people. And the way that you can do that is with a merge or pull request. In this case, just going back to the repository, you can see now I am on Branch Master, so I have clicked on the repository and I'm back on branch master, this is something that you have to be careful of, but you can see that 1 minute ago I created a change in Dev, now that I am happy (I could have made many many commits, this doesn't have to be 1 commit) but now that I am happy with the progress in dev I can now pull it into master using this Compare and Pull button here. If you don't have this, or you do this at a different time you can also go up to the pull requests tab and create a new pull request. A pull request is just a option to essentially pull from one branch into another, the new changes. So the base is Master that's what we are pulling the changes into and we're going to compare with Dev, and this comparison that now comes up is a useful little tool, you can see the changes that were made and where they were made. So we have the common text between the two, but then you can see this plus symbol has been included for Heat Milk, Pour and the space in between (that's even counted aswell). So these are the additions that will be made when we create that pull request. So yep, I have reviewed the changes and I am happy that that's what I want to do so i can create this pull request and I'll leave it as the last commit message and we can leave a comment because we might be collaborating with other people or our future selves and say, "This now heats milk" and I will create that pull request. So now we have created the request, and because we are administering our own GitHub account and we kind of made that pull request and we are happy with it, I can just say Yep, approved, I will merge that pull request confirming the merge, and now our map looks something like this. So we could have had an arbitrary number of commits down through here, and now our changes have been pulled in to the master branch, so the master is now the most up to date version of the project. 

So now that our pull request has been successfully merged into the Master branch, we have the option to delete the branch that we were just working on because it has been merged in. This is very much part of the Git philosophy if you want to develop a new feature; so you branch off, and you develop the feature on the side and then merge it in, so it's now part of the main project. There is not really any need to keep that branch if the feature has been completed. I am going to keep it for now because I like to have at least 2 branches to work with all the time. Now its time to clone our GitHub repository onto our local machine, I'll be using a Raspberry Pi in this tutorial, but you could be using any machine that has Git installed already.

I'm going to go to my GitHub repository and select this green "Clone or Download" button, that'll give me a link that I can copy and in my terminal, i can execute

Git Clone (and then paste that link and execute that)

So this is going to clone the entire demo repository into my users home directory and you can see there it is there. So if I change into the demo, I can see that I have a coffee and a readme, that's fine. I'm just going to minimise that terminal, we will work in this graphical interface for a sec. So I can open up the demo,  and I can, Ah, before I make any changes there is a very important point to make. And that is, lets just wind things right back for a sec, I have just cloned my Git repository into my local machine. I am just going to clear this, so you can see I am currently in the demo directory which is a git repository, and if I execute

Git status

You can see I am currently on branch master, and remember any changes that we make we should always make in the development branch, rather than in the Master branch, the very first thing I need to do before I make any changes is execute a Git Status just to make sure you're in the right place. in this case, I need to be in that dev branch so I can execute

Git checkout dev

And we get a little feedback there, but most importantly, a Git Status command will return the correct location. And you can see that both these messages say something about Origin master and Origin Dev. So what this means is that my current dev branch is up to date with something called origin dev and that origin is just the repository that we pulled from on GitHub. So that link now is attached with this local repository and it's now coupled to that online GitHub repository. We will come back to what that means exactly just in a moment, there is one more thing that I need to do. If we come back to the whiteboard you can see that the most up to date version of the project were master so this could have had several changes since we have cloned this repository. We could be coming back to this weeks later, so the most up to date point could be somewhere down here, but we are working at this point now, we've just checked out the dev branch and the last point on dev was this point here, so before we make any more changes we need to make sure that dev accurately reflects the current state of the project by merging from master into dev so we just do another one of these operations just to make sure that the branch that we are working on, dev, is most up to date. So this is the action that we are going to perform and we're going to perform it by performing a:

Git merge master

So we are pulling the changes from Master into our current branch, dev. And we get a message there that now we have updated our repository to this state. Now we can make our changes. If we made our changes to this point that was behind the master, and we tried to merge changes from dev into master, we would run into a few troubles, it's nothing very serious but it's always good to just follow this workflow so that you never have to deal with those problems. 

So what are we going to do now, let's develop some more of our code on our local machine, so I can open up my demo repository, open up coffee and where are we currently... so far we start, we grind the beans, we heat the water, we extract the coffee, we heat the milk, we pour, now it's probably time to take over the world. So I have made my changes, I developed them on the local machine, so I can close that file and execute a

Git Status

Now git status is exactly what it says on the tin, it tells us whats going on with the current git repository, and we can see that now our branch is ahead of origin dev by 1 commit because we performed this action, that's a commit and we created this new commit. And what we would like to do now is update that change to our code in the git repository, so at the moment we have no changes have been added to the commit. I'll actually widen this out, clear this, and execute that again, just so it's a little easier to read. So we're ahead of the branch by 1 commit, that was the merge that we performed and we have something called changes not staged for commit, and we have our coffee script. So now that we're working on a local machine, we have to work wit something called the staging area, and that sounds very dramatic, but what it really means is i can make all the changes to all the files that i like but none of them will be included in the next commit, unless i stage them to thee. And that's really easy to do, all we have to say is

Git add coffee

And if we execute git status again we can see now we have changes that are going to be committed and coffee is in green. So we can commit those changes to the dev branch. And I'll do that with

Git commit

Before we proceed though I have to actually tell Git who I am. So I have to execute these two commands, what I'm going to do is copy and paste it so I don't have to type it out. And then just enter user email, and my name, these are the user credentials that we signed up to git with. Okay, so just after that little detour, we just told git who we are because we need to have our credentials so we can actually commit to this repository now. Now if I execute

Git commit

We're dropped into a text editing environment and this is where we add those commit messages that we did on GitHub, remember there was a short message that was something like "Add take over world feature", but now we don't have 2 text boxes we've only got this one file that we are editing. So the common practice is to add that short git commit message on the top line, and then put a blank line in between it and the long winded description. All of this text down here is commented out so that won't be included in the commit, it's just there as a helper to kind of steer you along the right path. So you can see that lines with this hash will be ignored. So the only message is, add this feature and here's the description. So I'll CTRL X to save, I'll say Y for yes and press enter, and now we've got the Take over world feature committed to the dev branch.

So now we have made our first local commit, and it looks something like this. remember we merged to master, into Dev, and then we created this new feature, which was Take over he world. So this is what our local repository looks like, with the dev branch and the master branch but there's just one thing that we haven't quite yet finished yet and that is, of course, we could roll this change back into Master, and we could do that but our remote repository is still back up here. Our remote repository is still back up here, the remote repository being the repository that's hosted on GitHub.com, it doesn't know anything about the changes that we have made on our local machine, even if we're developing things that may not find their way in the master branch eventually, we may still want to save our progress because we have some bugs to iron out or you know we're just saving our progress along the way. So we do that with what's called a push, and that's really easy to do, we just say

Git push

And I may not have to enter anything else in there. Okay, so I have just said git push and all I need to do is enter my user name for GitHub.com which was CoreMichael and my password. Okay, and now we can see that the GitHub site is now being updated with the changes that we made on the local machine. So if I go back to GitHub and we can see here the last commit was made 43 minutes ago. So I will hit F5 to refresh the page, and hmmm still 43 minutes ago. Remember I was modifying the development branch, not the master branch, so I have to go over to master branch here and select dev, and now we can see that the last commit was quite recent and If I open up coffee we can see the commit message. And of course if we wanted to we could issue a pull request to move those back over to the master branch from here, we could do a merge onto our local machine and do another push, the options are just...whatever your preference for workflow is. 

For me though, I am just going to do the merge on the local machine and do another push. So I am just going to execute

Git status

I'm on branch dev, I want to merge my new features on Dev to my Master. So I can

Git Checkout Master

And yep, we are on the master branch, you can see that it is up to date with Origin master because no changes were made to origin master, they were only made to dev. That's what we are doing now, we are updating the master branch. So I can say

Git merge dev 

And you can see that was what is called a "Fast Forward Merge" that's a bit technical, it's kind of outside the scope of this project, but we can see that there was the coffee script and 2 insertions have been made. That was a blank line and the command to take over the world, so our master branch has now been updated with our new features so we can execute a

Git Push

We enter our username/password once again, and performing that action has merged our new feature into the master branch and it has also pushed those changes onto GitHub.com. So if we go back to GitHub we can just click on the Demo directory here and it should take us back to the master branch. I just need to refresh that. Yeah, so the add takeover world feature is now in the master branch, and the thing that originally had confused me was because the timestamp was for 17 minutes ago, so that timestamp was actually for when I made the changes on my local machine and that's the timestamp that stays with it forevermore, so even though I only executed the push command just this moment, that commits was made a long time ago, so that's what is shown on GitHub.

And that's the basic Git and GitHub workflow, so you can see this model of how we manage our branch is very simple and that works for small projects, I have included some links in the content for this video to some more complex workflows, maybe if your projects get a little larger or you start collaborating with other people. And of course, this diagram wound up, well it was only commit to commit, so it didn't get too complicated, but it stands to reason there could be any number of commits along these development paths. Like I was saying, you would work on this feature until you were happy with it and it's at that point that you would merge it into master. So that wraps things up for this tutorial, if you have any questions, we would love to hear from you on our Forum and if you want to take a closer look at the features that Git has to offer I'd recommend checking out Daniel Schiffman's Git and GitHub for Poets course on YouTube. I'll see you next time.