Getting started with GIT
Setup Client Environment
git config --global user.name "Joe Bloggs" git config --global user.email firstname.lastname@example.org 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 repo||svn co repo|
|git pull||svn up|
Create new repo
Cd to the dir where version tracking is required and create the repo:
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
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:
git checkout HEAD -- file
Revert local changes to the version on the same branch of the commit directly BEFORE the most recent commit:
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 exit
In your new repo folder:
git remote add origin ssh://remote-server/var/git/repo1The 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 http://blah.com/repos/bgrepo.git
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
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.
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.
- Both of these commands have the same result:
git mv script.pl script2.pl
mv script.pl script2.pl git rm script.pl git add script2.pl
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 Fast-forward .... 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>