Getting started with GIT


Jump to: navigation, search


Setup Client Environment

git config --global "Joe Bloggs"
git config --global
git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

GIT vs SVN cheat-sheet

git clone reposvn co repo
git pullsvn up

Create new repo

Cd to the dir where version tracking is required and create the repo:

git init

Version track *.sh and *.pl files:

git add *.pl
git add *.sh

Perform your first commit:

git commit -m "Initial commit"

Re-commit every time changes are made:

git commit -a -m "test1"


Changes in working tree not yet staged for commit

git diff        

Changes between staged changes and the working tree

git diff --cached

Changes in the working tree since your last commit

git diff HEAD


Reverting local changes

Revert local changes to the version on the same branch of the most recent commit:[1]

git checkout HEAD -- file

Revert local changes to the version on the same branch of the commit directly BEFORE the most recent commit:[2]

git checkout HEAD^ -- file 

Reverting a commit

Use git log to view the list of commits, note the long alpha-numeric after "commit".

git revert <commit-number>

Setup remote repo

Setup a bare remote repo:

ssh remote-server
mkdir -p /var/git/repo1
cd /var/git/repo1
git --bare init

In your new repo folder:

git remote add origin ssh://remote-server/var/git/repo1
The following command will now push your repo to remote-server:
git push origin master

Clone an existing repo

Note that the term 'check-out' is specifically not used here, as 'check out' in GIT is completely different to 'check-out' in CVS/SVN. A check-out in CVS/SVN is called 'clone' in GIT.

git glone

Repos can also be setup using GITs own protocol in the form of git clone git://... or over SSH as described above or with git clone user@host:repos/bgrepo.git

Making stages

GIT unlike CVS/SVN has a 'staging' principal. Changes that are made to files in your local repo are not automatically committed when git commit is run. All local changes must be set to be 'ready to commit' instead, which is is called 'staging' in SVN-speak. This is done from the git add which is also used to add files to the repo as in CVS/SVN. Local changes made since git add was run will NOT be committed! Instead the changes up to the last time git add was run on the file are committed. This is an important point as this is very different to the principals behind CVS/SVN and indeed other VCS.

It is possible to force git to place all local changes into staging before the commit ala CVS/SVN with the -a argument. This will place into staging files which already tracked - git add is only required to add new tracked files to the repo.

Renaming files

GIT does not automatically track file renames, however if a file is removed and re-added to the repo the change history is still retained.

git mv
git rm
git add

Branching and merging

A branch is a separate snapshot of your primary or master branch that can be worked out with affecting the master branch.

$ git branch
* master
$ git checkout -b fix-fallback
Switched to a new branch 'fix-fallback'
$ vim index.html
$ git commit -a -m 'fixed fallback'
[fix-fallback 3a0874c] fixed fallback
 1 files changed, 1 deletion(-)

Now they changes are committed in the fix-fallback branch. To merge this into master we switch to it and perform a merge command:

$ git checkout master
$ git merge fix-fallback
Updating f42c576..3a0874c
 1 file changed

Now that the changes have been merged into master the fix-fallback branch can be deleted:

$ git branch -d fix-fallback


List changes in this branch

git cherry -v


git log <upsteam-branch>..

See changes in last commit

git log --name-status HEAD^..HEAD


See changes in a given commit id

git show <commit-id>


Personal tools