Friday, July 5, 2013

Understanding & Using Git

What is git ?
Git is a distributed version control and source code management system designed and initially it was designed and developed by Linus Torvalds.

Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.

Git is free software distributed under the terms of the GNU General Public License version 2.

Getting a git repository
You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.

Initializing a repository in an existing directory
If you’re starting to track an existing project in Git, you need to go to the project’s directory and type 
  • $ git init
This creates a new sub directory named .git that contains all of your necessary repository files to a Git repository skeleton. At this point, nothing in your project is tracked yet.

Cloning an existing repository
If you want to get a copy of an existing Git repository - for example, a project you’d like to contribute to the command you need is git clone. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is clone and not checkout. This is an important distinction. Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run git clone. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned.

You clone a repository with git clone [url]. For example, if you want to clone the Ruby Git library called Grit, you can do so like this:
  • $ git clone git://github.com/schacon/grit.git

The three states
Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.



The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.

The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.

The staging index
Git internally holds a thing called the index, which is a snapshot of your project files. After you have just created an empty repository, the index will be empty. You must manually stage the files from your working tree to the  index using git add:
  • $ git add somefile.txt
git add works recursively, so you can also add whole folders:
  • $ git add somefolder

Committing
git commit takes the contents of the index and creates a new commit:
  • $ git commit somefile.txt -m "comment" 
Or if you want to commit all the changes at ones
  • $ git commit -a -m "comment"

Committing is a completely local operation, not related to sending something to a remote server. It just takes the contents of the index and keeps a snapshot of your project files as they were in the index:

View committing history
You can view the committing history by using
  • $ git log

Push all commits to the main repository
You can push all commits to the main repository by using
  • $ git push --all
This will push all the commit changes in all branches. If you want to push a particular branch you can use
  • $ git push -u origin <branch name>
This command only push the given branch to the main repository.

Pull others changes
You can get others changes to your local repository by using
  • $ git pull

Git branching, checkout & merge
If you init git or get the clone from the url you will get the master branch. As a best practice, it's better to have different branches for your changes.

As an example suppose if you want to do some platform changes in your code. To do that you can make a branch from the master branch in your local repository.
  • $ git branch platform
Then you can checkout that branch by using
  • $ git checkout platform
After that you can do the modification and commit the changes to that particular branch you created. Finally if you want to apply those changes to the master branch in your local repository, first you have to checkout the master branch. After that you can merge the changes by using following git command.
  • $ git merge platform
You can see what's happen on by using git status command.

Make patch using git
Suppose if you need to make a patch from your changes. The command is,
  • $ git format-patch -1 branch_name
In here -1 means, your patch will create using last commit changes. If you use -2 here, it makes two patches with last two commits.

Checkout a branch from the main repository
Suppose if you want to checkout the branch from the mail repository. To do that you can use the following command.
  • $ git checkout -b branch_name /remote/origin/branch_name

Get the specific file from the main repository
Suppose if you want to get the specific file from the main repository to your local repository. This will replace your file with the repository file. To do that you can use
  • $ git checkout -- filename

Stashing the changes
Often, when you’re been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. To do that you can stash your work by using
  • $ git stash
Stashing takes the dirty state of your working directory - that is, your modified tracked files and staged changes - and saves it on a stack of unfinished changes that you can reapply at any time.

Then you can switch to another branch and do the changes what you want and make a commit. Suppose if you want to reapply the changes, first you have to switch that particular branch. After that you can view the stashing status by using
  • git stash list
This will give the list of stash you have done. For example, it'll give something like this.

stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size"
stash@{2}: WIP on master: 21d80a5... added number to log

In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command
  • $ git stash apply
If you want to apply one of the older stashes, you can specify it by naming it, like
  • $ git stash apply stash@{2}
If you don’t specify a stash, Git assumes the most recent stash and tries to apply it.


1 comment: