Git With The Program – Beginning Code Control

Git version control has two components a working local copy and a remote repository of some sort (GitHub/Enterprise Git). Development of new features or code changes require branches for each feature to allow easy merging of those features into an existing code stream. In this post we’ll start with the git basics to get you on your feet and running.

Git setup:

Code is maintained by a snapshotting system based locally on your development machine. These snapshots (commits) can then shared to the central repository (GitHub). Step one of the process is getting your local development host setup. To do this, you’ll need to download a version of git and install it. There are variants available for almost any OS (Windows/OSX/Linux/Solaris) to help you start versioning your files locally.

Download your version of git here

After installation you’ll need to configure a few parameters that tell git who you are and also give git a contact email for your code that is committed to remote repositories (GitHub). Fire up a console and enter the following:

git config --global "Your Name"
git config --global "Your Email"

Your first code repository:

A local code repo is created in two ways, either by cloning a remote repository (to work on another author’s code) or by creating your own. Let’s get started creating our own.

Create a repo within your working directory:

git init

To clone a local copy of a remote repository (another person’s work):

git clone


git clone username@somehost:/some/repository/

Adding files to git for tracking:

Adding a file effectively adds the file to git’s change tracking index. This is accomplished with the following:

git add <file that you're changing>

or, if you’ve made a bunch of changes:

git add *

Commit your changed files:

Although you’ve told git to track changes on files by using the git add command, git doesn’t officially take a snapshot of the files until you tell it to commit. Do that by issuing this command:

git commit -m "A note about the changes that you've just made in this commit"

Congratulations on your commit! You can view your commit by running the git log command. This will show you your history of each commit on the repo:

git log


The next step in this process is to push code to someplace where others can use it. To do that we’ll need to add another step to our workflow:

Update a remote repository with your changes:

To send your local changes to a remote repository, you’ll first need some information about where the files are supposed to go. If you’ve initially cloned this repository, git will attempt to push changes to the same remote source. If, however, you created your files locally and need to push them to a remote repo for the first time, you’ll need to add that location to git’s local database with the following:

git remote add origin

To push to the external server use this command:

git push origin master


Every time you want to edit something in git, it’s a great idea to use a branch. A branch is simply a separate sandbox of the master code repository that we can use to work on a new version of code. After you’re satisfied with your code changes, it’s easy to merge these changes back in with the master branch of code. Git uses snapshots making it easy for us to back these changes out should something go wrong in our process. To create the sandbox/branch for development we use the branch command. Later, when we’re done working in our branch we’ll use the merge command  to bring the new code into the production stream. To create and switch our working context to the new branch/sandbox use the following:

git checkout -b name_of_the_addition_to_our_code

You can always check which branch of code that you’re working on locally by using the branch command.

git branch


The branch listed with the asterisk by it is your current working branch

Branches can be shared on a remote repo as well. To share a branch simply create a commit within the branch and push it with the following command:

git push origin branch_name

Merging your branches:

When you’re done working with your branch and you’re ready to include your code with the main code-stream, it’s time to merge. To merge you may want to first make sure that your local master repository is up to date with the most recent remote version.

Switch to your master branch:

git checkout master

Pull any remote changes:

git pull

And merge your other branch with production:

git merge name_of_branch_waiting_to_be_merged

Finally you’ll want to push this code up to the master repo with the following

git push origin master

More info:

Get deeper with git. There are a TON of nuances that aren’t covered here! This is really designed to just get your feet wet with the git process. For more information check out the Pro Git book also check out the 12 days of commitmas on github!

Leave a Reply

Your email address will not be published. Required fields are marked *