Version Control & Git Part II

At the beginning of the week we covered creating a directory, a file, editing that file, creating a local repo, staging the new file and committing it to a local repo, all in Git command line. If you need to brush up or have not read VersionControl & Git Part I, I recommend you check it out first.

In this part of this series we are going to learn how to push the contents of our local repo to a public repo on Github, create alternate branches to work on and merge those branches to the master branch.

I’m going to assume that you have already created a Github account and are ready to push a commit from your local repo to there.

Go ahead and login into your Github account and click on “New repository.”


After that you will need to name your repo, select “public” -unless you would like to pay for an account to make your repos private- and give it a brief description. Most of the time you will want to initiate it with a README file but because we already have one, we will omit the option here.


You will need to generate an SSH key (Secure SHell) to remote login to your Github repo with the command line. This will enable you to login to your Github account every time you open terminal without having to enter a Github password for each repo you have. For more on SSH visit here. To learn how to generate an SSH key and add it to your Github account visit here.


Now that you have your SSH key set up we are going to open terminal and cd (change directory) to your local repo.

cd a_new_project

You will notice on your Github repo some commands to push your local repo to Github and that’s next.


Simply copy and paste the first line and press enter.

Next, copy and paste the second line and press enter again.

git push -u origin master

You can now refresh the repo page on Github and view your README file.


Let’s assume you are still in the a_new_project directory in your terminal. We will make a change to our file and push it to our Github repository.

First we’ll edit the README file in nano in the terminal.


Add some additional text, type control x, type “y” to save your changes and then press enter to exit nano.

Now let’s check the status of our file.

git status

We will see that the file is highlighted in red and accompanied with “modified.”


This means it is ready to be queued to our local repo.

git add -A

Using the add -A command will add all files that you edited, all at once to the queueing area; a shortcut. You can still add files individually as you did in the first tutorial, if you prefer.

Check the status again to make sure that the file is queued to be committed.

git status

The file will now be highlighted in green.


It is now ready to be committed to your local repo.

git commit -m "Added some additional text to README."

Now push it to your Github repo.

git push

Go ahead and check your repo at Github to see that the changes were made along with your comments.

On to using multiple branches.

The master branch in a repo is the first branch, it is also known as the trunk. If you do not want to work in the master branch because you are working on a new feature and will be making several commits before it is ready, you will need to create a new “feature” or “development” branch.

Let’s create a new_feature branch. (If your terminal is filled up with commands you can type the command clear to remove your command history from terminal.)

git branch new_feature

To get into the new_feature branch you will need to use git checkout.

git checkout new_feature

This command will prompt the terminal to reply with “Switched to branch ‘new_feature’.”

Now we will do some more editing to our README file.


Add some text, type control x, type “y” to save your changes and press enter to exit nano.

Now let’s queue it, commit it and push it to Github.

git add -A
git commit -m "Added some text to the README file in the new_feature branch."
git push

Ahhh, wait a second, you get an error after git push.

“fatal: The current branch new_feature has no upstream branch.”

You need to setup the new_feature branch on Github to receive the contents of it from your local repo. Lucky for us, terminal tells us exactly what to type to accomplish this.

git push --set-upstream origin new_feature

Once you have set the new_feature branch upstream, push your commit again.

git push

Now go back to your Github repo and select “branch:” to see your new_feature branch and it’s contents.


Now, let’s say you are finally ready to merge the contents of your new_feature branch to your master branch. You will need to be in the branch you want to merge to in order to merge the alternate branch with it. For us, we want to merge our new_feature commit to our master branch, thus, we will need to get back into our master branch in our local repository.

If we use

git status

terminal will let us know that we are still in the new_feature branch.

“On branch ‘new_feature'”

So let’s get back into our master branch or trunk with the command git checkout.

git checkout master

Terminal will tell us that we have switched to the master branch.

It’s time to merge our changes to the trunk or master branch.

git merge new_feature

After the merge occurs it is time to queue it, commit it and push it to Github.

git add -A
git commit -m "Merged new_feature onto trunk."
git push

That’s it! Congrats! You can now use version control with Git for your entire career. No more cowboy coding. Time for a raise, right?

There is much more to learn about Git but this is enough to be able to have version control implemented on any project. Here are some useful links for continuing your Git/version control education.

WordCamp KC: Version Control Using Git

Please feel free to comment, ask questions or send me an email. I love talking shop and would enjoy hearing from you. Also, subscribe to my blog. I send out one email per month ( on the last Friday) to get you up to date with what I posted during that month.


Read More

Version Control & Git Part I

When I was introduced to version control with Git I was hooked, but there was a catch, command line. I thought, when will I have time to learn command line? However, it really isn’t as scary as it sounds. As a matter of fact, all anyone needs to know are a handful of commands in order to implement version control.

In this two part series we will use command line to create a new directory, create and edit a file, use Git to initialize a repository, add our file to a queue area, commit it to our local directory and push it to a public directory on Github. Along the way we will learn what version control is, why to use it, a handful of commands and where we can download Git.

Let’s do a quick run down of what using Git for version control looks like.

1. Your boss, team leader, other team members or minions, will be adding to or changing your initial code.

2. Git simply allows you to create a local repository in the directory of a project.

3. You initialize a local repo in a project directory.

4. You add the files/changes made to existing files in that project to a queueing area.

5. You commit those changes and/or new files to your local repo.

3. You push the contents of that local repo to a public repo (Github).

4. Team members/contributors then pull or clone the contents of your public repo into their own local repos.

5. They make their changes to the code.

6. They add the changed and/or new files to a queueing area.

7. They commit those changes and/or new files to their local repos.

8. Last, they push the contents of their local repo back to your public repo.

Here’s the best part, their changes have not affected your initial code. In fact, your team members’ changes will not be “merged” with your code unless either A. you approve of the changes (an approved pull request) or B.  you gave them access to merge their changes to your master branch of the project from the start (assigned them with a role of “Contributor” on Github). Even better, your team can work on several different branches of the same project simultaneously and only merges to the master branch will occur when an idea is fully developed and approved! This eliminates stepping on others’ toes and committing conflicting code.

First you need to download Git here and install it. If you are using a Macbook with Xcode installed then you already have Git installed. Xcode is a free app at the App Store.


This page contains all of the commands you will need to run in your terminal for all of the dependencies Git requires, the download and the install. Yes, this is in command line, but all you have to do is copy and paste each line, one at a time into your terminal, easy peasy.

Last, setup a GitHub account here.

Once you have completed these tasks you’re ready to implement version control on every project from here on out. Tip: It is highly recommended to implement VC even on projects without any team members.   

Alright lets git down to the nitty gritty. Get your coffee and open your terminal.

1. Make a directory.  The ~ in your terminal indicates that you are in your user directory, this is where the new directory will be created.

mkdir a_new_project

You can check your user directory to see the newly created directory.

2. Get into that directory.

cd a_new_project

3. Create your first file in a_new_project.


4. Edit the file.


5. Type some text, hit control x to exit, this prompts ‘yes’ or ‘no’ to save your content, enter ‘y’ to save and then hit enter to leave nano.

6. Initialize the local repo in a_new_project.

git init

7. Add the to the queueing area so it can be committed.

git add

8. Check the status of the file to make sure it is ready to be committed to the local repo.

git status

9. Once you see that the file is there it is time to commit the file.

git commit -m "Added a README file."

And that’s it. You have now created a directory, created a file, edited that file, created your first local repo, staged your new file and committed it, all in command line! You should be feeling like a hacker at this point!

Make sure to always add a brief descriptive message to each commit as shown above (-m “a descriptive message”). This will be helpful to your future self and other team members.

In Part II of this series we will learn how to push the contents of our local repo to a public repo, create alternate branches to work on, merge those alternative branches (or development branches) to the master branch and then pull the changes made back into our local repo.

Please feel free to leave comments and ask questions!





Read More