Github Basics V 0.1: Aaron Cheng March 21 2014

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

Github Basics v 0.

1
Aaron Cheng
March 21 2014

Introduction

Welcome to GitHub!
First o, why, GitHub or any version control software to begin with? There are plenty of reasons why, but
there are two major reasons that I can think of, and they are:
Maintainability
Keep code organized, especially amongst large teams, without having to manually redistribute code
and integrate code face-to-face.
Keep code safe
Keep code on a distributed code-base, making it more resilient to hardware failures, as well as
keeping track of who has done what to the code.
With the two main reasons out of the way, another huge advantage that GitHub has over other VCS
systems (say Microsofts Team Foundation Server) is that it is completely platform independent.

Initializing your Git Repository, or I Have Git Installed, Now


What?

The rst thing we must do when using GitHub, is to initialize a directory to which it will be monitoring all
code changes to. Assuming that all members of the team have signed up for accounts on Github.com, as
well as intalled a Git client team members can proceed by issuing the following command in the
directory they wish to use to store their code:
git init
What this does is it noties the Git client that this directory needs to be under version control, and Git
will create several other les to help keep track of the changes this folder will undergo. Ideally, the folder
you want to store your code in will be of the same name as the repository (i.e if the repo name is
EmptySpace, your folder name should be EmptySpace).
At this point, the team leader, or whoever is making the repository needs to go ahead and create the
repository on the remote GitHub server. On the GitHub.com page, there should be a Make Repo button
which will allow you to create a repository to upload your code to. Only a single team member should do
this action.
After the repo is created online, every team member inputs this command (while still in the directory of
where the code is going to be saved):
1

git remote add origin https://github.com/[owner name]/[reponame].git


Alternatively, team members have the option of waiting until the repository is created on the website by
the team lead, then type:
git clone https://github.com/[owner name]/[reponame].git

Pushing to Repositories, AKA, Thats Great, but How Do I


Save My Code?

So we have now successfully created the repository, as well as created the local folders to which we will be
saving our code. What is interesting is that at this point, the directory we have created both locally and on
the server are completely empty. Being a version control system, there must be a point where we need to
save the code online at some point.
Thankfully, using GitHub, saving code is quite easy to do. The most basic command to save code is
git push. What this command does is it takes all the local changes that you have made and uploads them
onto the server.
Before running git push there are two more commands you MUST run. They are:
git add *
This command noties git of all changes that you wish to make
git commit -m "Message"
This command noties git that you are now commiting your changes, as well as storing a message as
to why you are making this change.
Messages should be kept short, but descriptive enough to tell other developers why you are
commiting your code.
To summarize, when commiting your code, you must run three commands, and in the following order:
git add *
git commit -m
git push
There is more to this than just those three commands, and well cover them in the next section.

Branching and Merging, AKA Just What the Hell are Merge
Conicts?

Now we can create repositories, as well as add code TO our repositories. But trying the above commands
(creating, adding, commiting and pushing) to a shared repo results in a multitude of errors called
Merge Conflicts! Why is that?
It turns out that having a large number of people commit code to a shared repository isnt the greatest
idea. To work around this, we use the idea of branching to allow us to save our work.

4.1

What is branching, aka I Thought it was the Stu on Trees?

Branching takes advantage idea that every independent feature of the system can be developed
concurrently.
As we saw earlier, we ran a command called git remote add origin. That tells Git that we are planning
to push (and recieve) code from the origin branch.
The origin branch is the main branch (or trunk, if you will) of the entire repository; once initially created,
users DO NOT MODIFY the main branch except when they need to merge their code (well get into
that later).
To create a branch, rst decide which feature of the system you will be working on. Ideally, a single person
should be working on each feature, otherwise the problem of having multiple code commits to a single
branch arises again.
After you have decided which branch and feature you are working on, go to the directory to which you are
doing your work and perform the following command:
git checkout -b [branchname]
This tells Git that you are creating a branch of the repository in the current directory. Keep in mind that
this branch is local, and you must commit it to the repository for any changes to take eect.
To commit the branch, simply run through the commands to commit the code to the repository. Keep in
mind that you are now working on the branchname branch. To switch back and forth between the master
branch and the branch youve just created, use the command:
git checkout [branchname]
Where branchname can be the name of an existing branch on your computer or the master branch. Keep
in mind that branches should ONLY be created for a single NEW feature. Once you are nished with the
feature, you will want to merge the branches back onto the master branch.
To do so, go on the website, and issue a pull request; this noties each member of the team that you are
done with your branch and that you wish to merge your branch into master.

4.2

Merging! Wait, what?

to be lled

You might also like