Basic git cycle

Here are the basic (very basic) steps one should take when using git and github for his/her projects. I am more or less intentionally ignoring the details of the more cumbersome matters regarding branching, resets, etc. More about these in a future post.

0. Concepts

Okay, so here it is (and I pray now to the gods of version management to forgive me for the simplistic explanations):

- we work with projects (which are basically files and directories grouped under one project directory)

- all the files and directories are tracked by git in a repository (or repo for short) - where each and every modification (adding/removing files, changes in the tracked file) is  monitored, but only when the changes are committed to the repo.

- each repo keeps track of the entire succession of the commits, and one could see (or even revert to) a previous commit state (no, we don't provide these below)

- moreover, one could "fork" a repo in multiple simultaneous states, by branching the repo (you won't find this below though; just for the future, although we won't be using it anywhere below, the current state of the current repo is referred to as HEAD)

- and finally, besides the local repo (the one in your computer) there could be many remote repos with which the local repo gets periodically synced (most notably, the github repo which is the default remote for most of us, and the one on heroku).


1. Creation

This can be done either by using a local project (all commands are in the project directory, unless specified otherwise):

    git init

or by using an already existing project in a repo:

    git clone repo_name

(This is not to be typed from within a project directory, as there is no project directory yet. The git clone will create one).

Both commands will create a .git directory in your project directory, where all the details of the repo/branches/commits are to be held.

As a side note, you can instruct git what to always ignore by setting up a file called .gitignore, which will contain wise notes such as (folders and files to be ignored):

    /db/*.sqlite3
    /log/*.log
    /tmp

As a side side note, a README file in the root of your project directory will tell github what to use as a description of your repository. It supports multiple formats (plain text - no file extension, markdown - files with .md extension, and RDoc - files with .rdoc extension).


2. Finding current situation

    git status

    git diff

    git log


3. Adding and removing files

    git add . (or just the needed filename)

    git rm filename (yes, there is also a recursive option for the rm, but it is dangerous enough to leave it out for now :-)).


4. Committing changes to the repo

    git commit -m "comments"

(If you feel lazy, git commit -a -m "comments" will do both the add and the commit part, but I prefer having it in two steps... because this auto-adds only the already tracked files)


5. Updating/syncing the other repos

One can either update his/her local project by using the repo:

    git pull

or can update the repo using the local as the source of truth:

    git push

Here a few more words:
- the name of the local repository is by default master
- the default name of the remote repository is origin

However, typically this needs to be created when first initializing the local repo with:

    git remote add origin remote_repo_name

The first push towards the new origin ought to be a little bit more explicit:

    git push -u origin master

But after that git push will be enough for git to know the right direction.

 - there could be other remote repos defined (such as for instance when we create a heroku instance, which also creates a remote repo in the local project directory, with the predictable name of heroku). Hence, syncing with heroku will be:

    git push heroku master


6. And finally, the mother of all...

    git help command

If you don't know even the name of the command you're looking for, just use git...

Web reference: http://git-scm.com/