Skip to content
cadorett edited this page Jan 6, 2012 · 13 revisions

This page describes common git operations in relation to the iSENSE repository.

Overview

A git repository is a source control solution. With the help of github, and git's "remote/pull" capabilities, git is well-suited for multi-developer projects. If the last two sentences were confusing, read more about git before continuing on.

From a developer's perspective, the world contains the following:

  1. The isenseDev/iSENSE repository
  2. Your forked repository, called username/iSENSE.
  3. A local repository on your development machine, which should have a close to identical AMMP setup.
  • AMMP = Apache MySQL, MongoDB, Php5.

Before we go on, let's define push and pull. By push, it is meant that you are pushing changes from your repository to another repository. By pull, it is meant that you are pulling changes from another repository into your own repository.

You will only ever push to (2) Your forked repository. You might pull from your (2) forked repository if you plan on using multiple development machines. You will pull constantly from (1) the isenseDev/iSENSE repository.

Creating your own fork

To do much of anything you'll need your own fork. Gone are the times where changes are made directly to the live website.

To create your own fork, you must navigate to http://github.com/isenseDev/iSENSE and click the "fork" button in second to top bar in the top right of the screen.

This will create your very own fork.

After following the instructions for setting up git found here here you need to create a repository on your local machine.

To do this, you pick a place to store said repository, and then run the following

git clone [email protected]:yourusername/iSENSE.git

In order to keep your fork up to date, you will want to keep track of the main repository you forked from. To do this, we add what is called a "remote".

git remote add upstream git://github.com/isenseDev/iSENSE.git

An example of the work flow

To clarify this, lets examine the work flow.

Before you go on, you should understand the idea of a branch. If you don't, take a minute and google git branches and read until the following makes sense.

Without getting too technical, assume you are instructed to fix a bug (Say Jim/Fred/I wanted you to add session validation to input fields on various forms across the site.)

isenseDev/iSENSE contains a stable, working branch called master. Your forked repository and local copy contain this as well. The point is to keep this branch functional and unmodified so you have a clean copy of the site easily accessible.

Updating your local copy

The first thing you would do before beginning work would be to make sure you have most up to date code, which is stored in isenseDev/iSENSE.

To do this, you pull any changes found on the master branch at isenseDev/iSENSE.

git pull [email protected]:isenseDev/iSENSE.git master

You may hate typing that url repeatedly, to simplify things, we store that url as a "remote" which I'll call upstream

git remote add upstream [email protected]:isenseDev/iSENSE.git

The same command above can now be run by the following git pull upstream master

After this command executes, you should have an up to date version of the sites code.

Creating a branch

To keep the master branch pristine, you would now create a branch. Lets call the branch sessionValidation.

git checkout -b sessionValidation

*The command "git checkout" allows you to, among other things switch between branches, git checkout switches to branch . The -b option creates the branch and then switches to it.

Making your changes

At this point you should know what to do. Modify the code. If you feel like taking a break, or reach a point where you'd like to save your progress, run git status.

Saving your progress along the way

git status will list all modified files, and instruct you on how to proceed. To recognize a change, you would run

git add file

or

git add expression selecting files.

To commit these changes,

git commit -m "Message describing this particular commit"

works. Read up on commits if you are unfamiliar.

You can commit as many times as you want, and should always do so before switching off the branch.

Throughout the process, and before you declare yourself done with a bug, you should fetch the latest changes from upstream again ( git pull upstream master ) and make sure everything is still working.

Once you are done making changes

You would now make sure you have pushed your latest changes to your local fork. git push origin sessionValidation

Once you are done making a change you feel is worthy of existence on the live site. The idea is to issue a pull request to me or someone else acting as the web master. This tells them through github that you wish to submit your changes to the site. They would then act appropriately and merge the changes from your branch on your fork into the master branch in the isenseDev repository.

To issue a pull request, you navigate to your repositories address on github (http://github.com/yourusername/iSENSE) and click pull request at the top. You then fill in the fields describing anything the web master might need to know and telling the rest of the gang what you've done, and issue the request.