Notes on Git Part I / Quickstart Guide to Git

By
rp
– December 27, 2011Posted in: Web Development
  • Git stores all the information locally, commit logs, versions etc so there is very little you can’t do if you are offline
  • everything is check summed before it enters the repo, it uses SHA-1 hash which is a 40 character string composed of hex and calculated based on a file or directory structure in Git.
  • files have three states
    • committed: data is safely stored in the local database
    • modified: the file is modified but not committed
    • staged: marked a file in its current version to go into your next commit snapshot.
  • Three main sections of a git project
    • working directory: single check-out of one version of the project
    • staging area: is a simple file that stores information of what will go in the next commit. its referred to an index
    • git directory (repo) where all the metadata and the object database for your project is stored.
  • define your git identity: 
    $ git config --global user.name 'Rajat Pandit'
$ git config --global user.email 'rajat@virajsolutions.com'
  • define the editor 
    $ git config --global core.editor vim
$ git config --global merge.tool vimdiff
  • checking the settings $ git config --list
  • Initialize a git repo.$ git init
  • add files to the repo$ git add *.
  • commit message:$ git commit -m '';
  • cloning a repo: this is not the same as svn’s checkout. every version of every file is brought down. infect if the server crashes, any of the cloned copies can be used to bring the server back to the state in was in when it was cloned.
  • $ git clone git://bla.com/morebla.git mybladir
  • git has a number of transfer protocols
    • git://
    • http(s)://
    • user@server:/path.git (ssh protocol)
  • files are either
    • tracked: (modified, unmodified or staged)
    • untracked: (any files in the working directory which are not present in the last snapshot and not in your staging area)
  • checking the status of files$ git status
  • revert a file change$ git reset HEAD # to upstage the command
  • if you do a "git add" and the modify the file and commit it the changes at the point of last 'git add' will get committed. if the new changes need to be added as well the file has to be 'git add''ed again’
  • defining ignore files by adding them to the .gitignore files. The following rules for the pattern work
    • blank lines or lines starting with # are ignored
    • standard glob patters work
    • patterns can be ended with a / to specify a directory
    • you can negate a pattern by starting it with a !
  • to see what will go in the next commit: 
    $ git diff --staged
$ git diff (will only show untagged changes)
$ git diff --staged (will show the diff for the staged files)
  • to remove a file$ git rm It removes it from the staging area and also physically moves to file to ensure that it doesn’t appear as a tracked file.
  • To remove a file from staging area but not form the file system.$ git rm --cached readme.txt

    This is useful particularly in case where you possibly forgot to add it in the .gitignore file and it got pushed to the staging area and then had to be taken out but not removed from the filesystem.

  • To use the glob patterns, stuff needs to be escaped. 
    $ git rm log/\*.log
$ git rm \*~
  • moving files around:$ git mv file_from file_to
  • git status will show this as a file renamed. its the equivalent of renaming the file first, git rm the first file and then git add the new one
  • git has no meta data that tells you later that you had renamed the file.
  • viewing history using git log 
    $ git log -p -2
-p shows the diff
-2 limits the entries to 2 by default shows the most recent commit first.
$ git log --stat
--stat shows the abbreviated stats for all the changes that happened
$ git log --stat --pretty=<online|full|fuller>
$ git log --stat --pretty=format:"%h - %an, %ar : %s"
(ref: http://progit.org/book/ch2-4.html)

$ git log --pretty=format:"%h %s" --graph

(adds a nice little ASCII graph showing your branch and merge history)
$ git log --since=2.weeks
$ git log --author=<name of author> --grep="search in commit messages" to make both of them count you also need to pass --all-match option
  • git understands the difference between author and patcher.
    • author: who created originally wrote the work
    • committer: who applied the last of the work.
  • Amend a commit, in case you forgot to put a file in stage then you can put it as a second step: 
    $ git commit -m 'intial commit'
$ git add forgotten_file
$ git commit --amend
  • in case you have staged two files but want them to be committed in separate commits, how do you ‘upstage’ your files. 
    	$ git add * # staged all the changes
	$ git reset HEAD benchmarks.rb # keeps the file modified but takes it out of the staging area
  • reverting local modification $ git checkout -- benchmarks.rb
  • get the info about the remote git repo. if you have more than one remote repo then the command lists all of them 
    $ git remote -v
  • adding a remote repo 
    $ git remote add [shortname] [url]
$ git remote add pb git://github.com/paulboone/ticgit.git
  • now you can fetch all the changes in pb that are not in origin
    $ git fetch pb
    this will check out the changes in pb/master you can then merge it in to one of your branches or checkout a local branch at this point if you want to inspect it.
  • update your current code from the remote repo $ git pull # automatically pulls from the origin)
  • pushing changes to the report server 
    $ git push [remote-name] [branch-name]
$ git push origin master

    note: push will only work only if no one else has pushed their changes, if that’s the case, your push will be rejected and you will have to pull to bring your code to the most recent state.

  • inspecting a remote $ git remote show [remote-name]
    shows the branches on the remote and also the branch the pull is associated with.
  • git tagging $ git tag # list the number of tags n your code
  • git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn’t change – its just a pointer to a specific commit. Annotated tags, however are stored as full objects in the git database.The annotated tags are checksummed, contain a tagger name, email and date; have a tagging message and can be signed and verified with GNU privacy Guard. its generally recommended that you create annotated tags so that you can have all this information; but if you want a temporary tag or for some reason don’t want to keep the other information then keep the other information, lightweight tags are also available.
  • create and show new annotated tag 
    $ git tag -a v1.0 -m 'bla bla bla bla'
$ git show v1.0
$ git tag # lists all the tags on the code also create a signed tag
$ git tag -s v1.5 -m 'my super signed tag'
  • creating a light weight: 
    $ git tag v1.4
$ git tag
lists all the tag along with annotated, signed or lightweight tags
$ git show v1.4
* verifying a signed tag:
$ git tag -v v1..4

    you require to have the public key installed to verify that the tag is from the right author

  • you can also tag later by specifying commit checksum or part of it.$ git tag -a v1.2 9fceb02
  • sharing tags, by default the tags are not transferred to the remote server when using git push,they have to be explicity pushed though
    $ git push origin [tagname]
    if you have lots of tags and want to push all of them at the same time.
    $ git push origin --tags

About rp

Architect for large, highly scalable LAMP applications and Technical Manager with special focus on metrics based continuous improvement of teams and products. Rajat has close to a decade of experience of a very wide range of skills related to infrastructure, middleware, app servers all the way to front-end technologies and software development methodologies including agile, iterative waterfall, waterfall as well as ah-hoc startup using the right approach in the right context to reduce time to market.