How to Get Started With GitHub

If you’ve ever wanted to learn Git, but didn’t want to configure a server, GitHub may be the place to do it.

That thought isn’t mine alone. During a recent site visit, Groupon’s lead talent scout told me the company searches for candidates not on a resume site but, rather, by searching through recent GitHub commits.

If that isn’t enough reason to learn Git, how about a free tutorial? Today’s your lucky day. It will only take about an hour.

First, Find a Git Project – or Use Our Sample

Git uses a branch-per-issue model; the local copy is the branch you’re currently working on. You can commit to it, roll it back and, periodically, push it to the GitHub server. The basic operations are Add, Commit and Push. GitHub is a fee-based corporate repository for code but open-source projects are free.

[ News: GitHub Cranks Delivery Speeds, Adds Analytics ]

Today we’ll make an open-source project and put it up on GitHub. We just need a little code.

To get started, pick a project that has some code and a build step. If you don’t have any code, you can use The Factory Simulation, which requiresonly Ruby to run. Just create a subdirectory with another subdirectory called “lib” and copy the five files in the right places.

To understand the code, read my previous article on getting started with Ruby. To run the application, go to the root directory and type “ruby factory_multi3.rb” from the command line. To run the tests, change the directory into the test directory and “ruby run_all.rb.” (This is code the author, Matt Heusser, wrote and contributed under open source license with contributions from Zach Spencer.)

Next, Create a GitHub Account

Go to github.com and sign up. Now download and install the latest version of the command-line tools. From here, we’ll create a repository through the Web interface, then import our code into GitHub using command-line tools.

Start on the login page, clicking the green “+ New Repository” button at the middle right:

Once you’ve created the repository, start your command line and run these commands. Make sure you change the directory to your code directory.

touch README.md

Note: Windows has no “touch.” Instead, edit and save a blank text file called README.md.

git init

git add *

git commit -m "first commit"

git remote add origin https://github.com(Username)/(Repository_name).git

git push -u origin master

Type in your username and password. Congratulations, you have public code on GitHub – at the url of http://github.com/(Username)/(Repository_name) – for the world to see.

What Did I Just Do?

First, with the “touch” command, we created the readme file that git init displays when you look at the root directory of your repository online. It’s in this file that we’ll tell users how to run our program.

Git init created an empty Git repository in your local directory. “Add *” added every file in that repository, and all subdirectorys, to the local repository, while commit committed the changes into a changeset. Notice the -m at the end. That’s a version note. If you leave off the -m, then Git will force you to edit the note in vi.

Next, we connected our changes to GitHub with Git remote add. If you run your own server, you’ll just need to change the URL. Finally, we pushed our changes to GitHub with git push.

Now, if I go to https://github.comMattExcelon/factory6 (the import I just made), I see that README.md is blank. Let’s edit it, adding the following text. You can cut and paste.

The Factory Simulation

From CIO.com, uploaded by (name), based on the work of Matthew Heusser 
Matt@xndev.com

Distributed under the GNU GPL 2.0 license: 
http://choosealicense.com/licenses/gpl-2.0/

Imagine a factory that has a number of stations. Each day, work proceeds through 
the stations.

The stations have high variability but are balanced. We simulate this with a six 
sided die. Users enter the number of stations and days and the application shows 
how work processes. The advanced version, factory_multi3.rb allows you to simulate 
multiple runs of the factory (run it a thousand times and take the averages) or 
change the number of dice.

## Dependencies

This code developed and tested under ruby 2.0.0p247. As long as you have ruby 1.9.3 
or higher you should be fine.

## Running the Simulation

1. `cd this/project/directory`

2. `ruby factory.rb` or `ruby factory_multi3.rb`

## Running the Tests

You’ve now made a change to the code that needs to be committed. So:

git add READM.md

git commit -m “Updated the Readme to provide information”

git push

After this, in your browser, Shift-Refresh http://github.com/(Username)/(Repository_name) and see the README appear. You’ll note that the pound-signs (#) are a type of markdown language, creating headings. (For more, see the GitHub Help on Markdown.)

After Your Own Repositories

GitHib is more than a website. It’s a community. You can follow other people, follow project work and receive notifications for changes; GitHub even has some recommendations for where to start.

In addition to your own work, you may want to fork the work of others by making a copy of their work for you to tinker with. To fork, view a GitHub repository – below is https://github.comtaq/vim-refact — click “Fork” at right and you’ll have your own version created, along with an automatic redirect.

On you own page, which is now https://github.comheusserm/vim-refact, you’ll see “HTTPS clone URL” on the right side. On the command-line, go to the root of your Git installation and type the following:

git clone (URL you copied)

Git will create a copy of the repository on your local machine, which you can now add, commit and push.

Those changes will be local to your repository and won’t impact anyone. When the time is right, issue a pull request, notifying the other person of your changes and giving them a chance to patch up your work.

[ Feature: Programmers Pick 7 Great GitHub Integrations ]

Here we focused on a few of the fundamental pieces of Git – namely, how to add/commit/push to GitHub and how to create repositories. That’s enough to write your own code to be crawled by recruiters. The hard work is creating the personal projects interesting enough that the recruiters will want to call you back.

We’ve also created a full-functional application, with tests, in GitHub. Our next step should be to integrate that with a continuous integration (CI) system such as Jenkins that pushes to GitHub generate a new build/test run of our software.

Let’s talk about that another time.