Now that we have GitHub set up we can click complete on our first task in Pivotal Tracker.

Our next task is to create a repository, and push it to GitHub.

Coming back to GitHub, you can click on the little Octokitty logo, which will take you to the homepage.

First, let’s go to your profile page (you can quickly access that by clicking on the image box in the right hand corner of the navbar and choosing “Your Profile”). On this page you will see a link called "repositories".

Repositories

Repositories are centralized locations where you can store code bases.

I have many repositories (called ‘repo’ for short). In some, I'm the only person working on the repository, while in others, I have multiple contributors/team members. This is one of the real powers of GitHub: It allows you to work on multiple projects simultaneously, and allows multiple developers to work a project together.

In this course you will work on a single project you will be the only collaborator on your repository.

However, I want to give you an idea of what it would be like to work with multiple team members working on the same repo. Let’s click on one of my repositories, and this is what you should see:

This page gives you all the items you would need to access the code, and acts as a backup for the code files.

If you click on the commits link, you will see a list of all the commits that have been made in this repository. You will see a posting for each time myself, or anyone that has been contributing to the application and has pushed code or code changes up to the repository.

Looking at the commit dated Dec 22, 2016 you can see that I have merged items in. You can see that Anthony pushed a small change that same day. Just below you can see that Andrew has also been pushing commits. GitHub's version control repositories have allowed us to build this application in a team atmosphere, which is a fantastic way to develop large applications. I wanted you to see a real world application of what it would look like to be a part of such a collaboration.

Creating a Repo

Now let's create our own repo. Go to the "+" sign, in the navbar and click on it. Choose the option called "new repository".

Give a name for your repository (such as devcamp-portfolio).

You will want to keep it public if it going to be something you will share with others. You have the ability to have a private repo, but you will have to pay a fee for those.

Don't click on yes on anything in the initialize READ.ME files section, as this is something we'll be doing ourselves a little later.

Finally, click on the button called "Create repository".

This will create your repository and give you a list of instructions.

We don’t want to do the quick set up and we’ve already done some of the steps in the “create a new repository on the command line” instruction list, so we're going to pick the third option, “push and existing repository from the command line” But first, we need to do some work in our application.

Git Init

Let's go to the terminal, and make sure you're at the root of your application. You can verify that you are there with the ls command.

We now have to create the repository locally.

The command for that is: git init

This will create an empty repository for us. You should get a reponse that says Initialized empty Git repository in / followed by your file location.

This creation also means that we're going to have a hidden folder inside our application named .git where all of our releases, versions, and everything pertaining to Git, are going to be stored.

Git Add

Now we can use the command git status. This will bring up a list of all the items that need to be added to Git. We want to add all of these items, and we could add them one file at a time.

For example, we could use the command, git add README.md

Now, if you type git status, you'll see that we have one Changes to be committed file that is listed in green and the rest of the files are still Untracked files listed in red.

The short version of what this means is that Git is aware there is a file to be commited (added), but we have to give a comment, or message when we make the commit. This provides a benchmark, or place in time, to say, this is what was done to these files since the last time they were worked on.

Typically we want to add all the files that we have been working on before we make our commit. We could continue to add a single file at a time with the command git add filename, and repeating the process for each file on our list. However there is a better way to add multiple files all at once.

To add all files at one time, you could use one of two commands; git add . or git add --all

I use git add . simply because it is quicker.

Once you’ve added all the files run a git status, you'll see that all the files now have a status of Changes to be committed.

Git Commit

When we make a commit we are creating a version of the application at that point of production. This would give us the ability to revert back to this code base at anytime we needed to.

The command for a commit is git commit -m ‘comment’. The comment has to be in quotation marks, but you can choose whatever comment you want to make. For a first commit I usually use this command:
git commit -m 'Initial commit’.

The -m option stands for the message, and I use this option to know what I committed.

Now if you type git status, you'll get a message saying On branch master nothing to commit, working tree clean, this means git knows we have created this version.

You can also verify what you have done with the command git log . You will get a commit id, which is a log hash full of numbers and letters. You will also get the Author’s name, the date, and a response message. This one says Initial commit. So you know it occurred.

Git Push

Finally, we want GitHub to know about our application, and this where the third option we saw on the GitHub website will come handy.

Simply copy the command by clicking on the clipboard icon in the “push an existing repository from the command line” section, then paste it in your terminal and hit enter.

This is where setting up the SSH keys was useful. Otherwise, you would have to take several more steps here like typing in your username and password. We’ve already verified the security of our system with GitHub.

Now, If you go back to GitHub, and hit the refresh button, you should be able to see the full application there. Everything we have locally is now on the GitHub website.

You can open your app directory and navigate to to your blogs controller and see that all your code is there.

I think it's pretty amazing that in a matter of minutes we were able to take all our code and push it up to this repository. If we were working with other developers they would also have access to these files. This makes for great collaboration opportunities.

We also have access to all of our versions. If we click the on the commit link we will see our Initial Commit. On the far right of this section is a button that allows us to browse the repository at this point in history. This gives you the opportunity to browse the code base at that fixed moment.

We are going to commit our files after building out any new feature, in this project.

Making a Change

Let’s make a small change to our app. Open it in sublime and use command t, to find and open your README.md file. On line one (1) after the hashtag change the name to a title of your choice. I'm going to change it to "DevCamp Portfolio Application”. Save the file and return to the terminal

Making another commit

If you type git status, you can see that the file is modified.

The next step is to add the file: git add .
Now we want to commit it: git commit -m ‘updated readme title’
Last we need to push it up to GitHub: git push

Now if you switch back to the browser and refresh the page, you can see this newest commit along with the initial commit.

To see the change between your two versions, click on the little icon, like this:

In your Initial commit you will notice that your readme file still has a original title. If you click on the code link for your second commit you will be able to see the changed title.

Version control tools have made development a much smoother process. Using version control is also considered a best practice, so you are going to want to become very familiar with GitHub. We will be using it throughout this course.

Now let’s update our project management dashboard by checking off the second task of this feature.