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.

Or…

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.

touch README.md

4. Edit the file.

nano README.md

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 README.md to the queueing area so it can be committed.

git add README.md

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!