Code&&Friends: Hands-On Intro to Source Control

we have a central code repository for our source control. that repo feeds into the demo/test servers (where we experiment) and the production servers (which are live and client-facing). devs pull down from the central repo to code, make fixes, and to get the latest code.
Hello Code friends!
We’re talking about version control, what it is and why it matters, then we’re going to set up and CODE! You’ll get some great experience by following along. Source Control management is a real skills that every dev benefits from!If you’ve made it out to Code Club in the past then Distributed Source Version Control and Github Pages might be a familiar topic to you. If you need a refresher or haven’t attended Code Club, then I hope you’ll learn a few new things from this post!


Source control ~ U Need it

As programmers we all need to use source control to keep track of our software. We share our code with other developers to collaborate, track changes and bugs, release versions of our software, and do code reviews together. You’ve probably already experienced this at Code Club!

What is source control exactly?

BitBucket, SourceForge, and Github are a few of the code version control websites that several of our Nerdy Girls have used. These are the websites that host your awesome code on their servers so that you can keep track of changes made, share the code, help out someone else by submitting a pull request to their code repository, and go back in time to view previous versions of your code. (At Code Club we’ve mainly discussed Git, Github, Git Bash, and MsysGit.)

Some svc websites we haven’t yet played with include: Kiln, Gitlab, and Gitorious. (Maybe you should check them out and report back with your findings.) ;-)

Along with the websites that store code, Code Club has discussed some of the source control management tools that pushes your code from your local machine up to your SVC website’s server. The software management tools many of us in Code Club have used ranges from Mercurial, Git Bash, Team Foundation Server, and even a plugin in Eclipse (a Java-centric IDE) to push up our code to Source Forge.

To briefly iterate over the differences between source control and the management software, please note that:

  • the source control hosting websites (like Github, Bitbucket) are what host your code on their servers.


  • that the source control management tools (like Git, Mercurial) are your terminal or GUIs that allow you to interact with the hosted repos by pulling down code to your computer from their servers or pushing up your local code on your computer up to their servers.

Brief intro into how it all works

we have a central code repository for our source control. that repo feeds into the demo/test servers (where we experiment) and the production servers (which are live and client-facing). devs pull down from the central repo to code, make fixes, and to get the latest code.
We have a central code repository for our source control. that repo feeds into the build servers (or build servers and test servers – depending on how your team is set up) and then finally into the production servers (which are live and client-facing). Devs pull down from the central repo to code, make fixes, and to get the latest code.

Our central code repository lives on source control management website’s servers (like Github). The developers get the code from those servers by requesting it via a svc management tool (like Git).

Many developers can work on a project simultaneously! Isn’t that crazy? We can all edit a website at the same time, with one dev working on the styling with CSS, another working on the document’s layout with HTML , and another working on the interactivity and behavior with JavaScript. When the developers have finished working on their portion of code, they’ll send it back up to the central repository by making a ‘pull request’. A pull request is when one person has made changes to the repository and wants those changes pulled into a different branch, like the Master branch. (Don’t worry if this might be somewhat hard to parse at first, we’ll go into depth on using Github, branches, and pull requests at Code Club or in another blog post. If this is making sense, then awesome!! Either way, keep following along — you’ll start getting it!)

Aside from the necessity in the work place, it’s practical to use Git/Github in your personal development as a programmer. ~Believe me, using a zipped-folder with the dates and times of your last save WILL NOT be good enough for you in the years to come! This knowledge comes from a bit of personal experience. ;-)


Hands on svc portion!

In this example we’re going to use MsysGit (for Windows users) or the terminal (for Mac/Linux users) and Github.

Don’t worry if you’ve never used MsysGit, a terminal or command prompt, or Github before. Just following along and if you have questions or find tricky parts, just leave a comment below or contact me. (t, f)


Windows Users

If you’re a Windows user, download MsysGit here.

An image of the msysgit website with a red circle over the download button


Mac/Linux Users

If you’re a Mac user, open up your terminal.

Close up image of the search icon highlighted and "terminal" typed into the search field.

Linux users, please open up your terminal.

Linux dashboard showing 2 ways of opening terminal: via searching and through the sidemenu icon

Create a Github account

Now create an account on Github. On enter in your username, email, and password to create an account.

this image shows the homepage. there is a red circle around the username, email, and password fields and the submit button. Fill out these fields in order to create an account.



{The Good Part!}

Let’s get to the good parts, where we actually write some bash code and get a site live on the internet!

We’re going to create a repo on After creating an account you’ll see a similar view on, but your feed will be empty since you aren’t following anyone yet. Just focus on clicking that green button that reads, ‘+ New Repository.’

Create a new repo on Github by clicking on the 'New Repository' button

After clicking the New Repository button, you should see the page below.

You should see a page with fields like, repository name, description, public and private radio buttons, initialize the field with a readme file, and a create repository button.

Fill out the input fields with your own names or feel free to use this sample text:

Repository name: mysite

Description: This is my first Github repo and hosted page. (Or maybe it’s your 5th, or 50th, Nerdy friend!)

Public: click this radio button (it’s selected by default already, by the way) to display your code visibly.

Initialize this repo with a README: click this checkbox to create a readme file in your project. (Readme’s are handy to have to quickly explain what your project is about, how to download it, and how to interact with it.)

Git ignore ignores files that you specify that you do not want to appear in your repository, like .DS_Store or a spotlight file if you’re a Mac User.

Licenses share how you want this code to be acceptably used and shared. It’s really neat and I can’t wait to learn more about different licenses.

Now that you know about all those input fields, click the Create Repository button!

The page you should see has your repo title, descript, and a tree view of your files include in the repository.
Your page will look similar but without that awesome ‘demo code’ text. We’ll add in the markdown content into the readme file soon though!

Great job, nerdy friends! Thanks for following along so well. We’re about to create the files and then upload them and host them live.

Create a folder on your computer, the desktop is fine for this or the location where you keep your code organized. (Press the control key and right click, name it MySite or whatever you’d like.)

Now, open up your console, terminal, or msysgit and navigate to the folder you just created. Type in the following (but adjust the path to reflect where your folder is on your computer):

cd /Users/amanda/Desktop/ProjectPageDemo

Now type the following!

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

you set the global properties of the user account. more info

(extra credit: password caching & ssh!)

git init

you created an empty git repository or reinitialized an already existing one more info

touch index.html

you created an html file named index right from your command line! more info
open up index.html in your text editor or IDE. Copy & paste the html below into the file and then save.

<!doctype html>
<title>Code Club</title>
<h1>hello world!</h1>
<p>join code club! ~*~*~*~ </p>

now open up in your IDE or editor. (The file format .md is a markdown file, by the way! View the Github Flavored Markdown cheat sheet.) Type in the following:

Welcome to my Totally Awesome Code
##this is my repo. there are many like it, but this one is mine.

if you're interested in coding, come join code club. you can contact us in a few ways:
* [twitter](
* (
* or my friend [Amanda](

Save your index.html and files!

back to the terminal, type the following in:

git status
git add index.html
git commit -m "created index.html and a markdown readme file. like a boss."
git push origin master

The console commands you typed should look similar to this (excluding setting the global user name and email, which i skipped):

This image is of a console with the previously mentioned console commands. You've added a user email, name, initialized a repo, created some files, and pushed them up. Good job!
Your console commands should look similar to the commands I’ve typed here


Your repository’s page should look like this:

your site should display the text from the markdown file and your two files (index and readme) should be visible
it’s alliiivveeee



YOU DID IT!!! ~*~*~*~*

Nice job on writing Git Bash, creating your first Github Repository and using source control to store your code! Now you can share your code with others, like the Open Source Community, your coworkers, your future clients, or with Code Club! You’ve done so much today and learned some important skills. I hope you will continue to build upon this knowledge.

Awesome Links to check out on your code journey:

Github Docs – Set up Git

Git SCM – Free Book & Docs on Git

6 thoughts on “Code&&Friends: Hands-On Intro to Source Control

  1. Question: Why do I have to add the file? I would have thought that it would already be added since it was created when the repository was created. I guess it make some sense. You always have to add a file to the repo when you create it …but if it wasn’t a part of the repo. I wouldn’t think it would have come when I cloned … hm.

    1. This is a great question. Can I ask what part of adding do you mean specifically? The touch command or the git add command?

      I think you’re asking ‘if you initialized the repository with a readme file, why did you need to type ‘git add’ before committing your code to Github’, right?

      If I’m following you, you would have checked the checkmark to create a file when iniatilizing your repo, then made a change in the readme file (like typing ‘Kendall’s awesome code’ into the file) and saved the file. Then you’re wondering why you typed ‘git add’ if the file already exists, right?

      When you type ‘git add’ or ‘git add index.html’ you aren’t recreating those files, you’re setting them up in a staging area to be committed. The files we added were untracked before we told Git to track them in an index (aka a staging area aka a cache) for a future commit to our source control data store. [1]

      We created the index.html file with the ‘touch’ command so Git knew nothing about the file therefore it was untracked. When we entered ‘git add index.html’, we told Git to stack tracking this file and add it into the “index”. Then when we’re ready to send that staged file to Github’s servers when we commit it.

      After that commit, the files are now unchanged because they are 1) tracked and 2) unmodified. If we modify the files again, by adding more code, the files will then be unstaged and also tracked.

      Hopefully these text snippets might explain why we used ‘git add’ if I haven’t explained it well enough (yet).

      “The basic Git workflow goes something like this:

      You modify files in your working directory.
      You stage the files, adding snapshots of them to your staging area.
      You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.” – git scm

      “Git essentially has 4 main statuses for the files in your local repo:

      untracked: The file is new, Git knows nothing about it. If you git add , it becomes:

      staged: Now Git knows the file (tracked), but also made it part of the next commit batch (called the index). If you git commit, it becomes:
      unchanged: The file has not changed since its last commit. If you modify it, it becomes:
      unstaged: Modified but not part of the next commit yet. You can stage it again with git add
      As you can see, a git add will track untracked files, and stage any file.

      Also: You can untrack an uncommited file with git rm –cached filename and unstage a staged file with git reset HEAD ” – stack overflow


      Please let me know if this did not answer your question! I will totally try to help you with this new learning experience. <3

  2. This could be a whole other blog post! So it sounds like mercurial (which is what I use a work) and git use add differently, and that’s why I was confused.

    Mercurial uses add to start tracking, and as far as I know, there’s no ‘staging’ in mercurial. So you only have to use add once on any given file. Then hg commit automagically commits all changes to any tracked files.

    It sounds like you have to use add before every commit in git. I’m not sure I like that. Do you end up typing:
    git add
    git commit
    a lot?

    or do you add a few times in a row and then commit once for all of them?

    1. Oh, neat! Yeah staging, branches, pull requests could all have their own post. Hopefully they’d be shorter because each one would be so precise! 😛 Quick posts explaining tracking, staging, etc, would be pretty cool!

      (Ha, automagically! I know, right.) Thanks for teaching me about Mercurial! This post on mercurial & git concepts is pretty neat! [1]

      Sidenote: this blog post does a really good job of explaining more about Git bash. [2] (I should have added on file then explained using ‘git status’ to see that the other file was untracked – like that post did!)

      Very good question! This is how I use git, so there are likely variances in what I say vs what a super power programmer would do. (I feel like that warning should be there, lol.)

      Yes, I do ‘git add’ & ‘git commit’ a lot! I can see that doing that a lot seems odd, but after a year it seems natural to me now.

      I type ‘git add .’ to start tracking new files and then again when there are a few changes in different files that I want to stage. (The period after ‘git add’ adds all the files in the directory and subdirectories in regards to your local working directory.) Sometimes adding everything is really handy, but sometimes you only want to add a select few files.)

      Next I’ll type a commit message for those particular changes. If there have been a lot of deleted files or folder restructuring, I’ll use ‘git add . -A’. [3]

      If there are multiple specific files that I need to add to be tracked or stage, I would do ‘git add A.html B.html C.html’, etc, all on one line instead of multiple lines.

      I’ll add files a few times after solving & creating various problems, then do a ‘git push’ to my repository. You can have a commit for every add, but I think most people would add several changes and then do a commit, rinse & repeat, and then do a ‘git push origin master’ or whatever the remote and branch are named. [‘git push origin master’ in other words means git push remote branch.]

      After the code is pushed up to the data store on Github, I create a pull request to the main (stable & working) repository to pull in my changes.

      The pull request manager (my boss, someone else, or myself, lol) will review those changes and either accept or deny with what changes need to happen first. (If my code breaks things, they’ll reject the PR and ask that I fix the code first. If everything works and runs fine, they’ll merge it in.)


  3. Yeah, pull requests sound like a great way to manage changes to code!

    Cool. Thanks for the post! and I have a Git hub account now, yay!

Comments are closed.