Git is a version control system that is used for software development and other version control tasks. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows.
Git (very) basics
git help <command>
The git community book
Pragmatic Guide to Git
-Add: put a file (or particular changes thereto) into the index ready for a commit operation. Optional for modifications to tracked files; mandatory for hitherto un-tracked files.
-Alias shorthand for a git (or external) command, stored in a
-Branch: a divergent change tree (eg a patch branch) which can me merged either wholesale or piecemeal with the master tree.
-Commit: save the current state of the index and/or other specified files to the local repository.
-Commit object: an object which contains the information about a particular revision, such as parents, committer, author, date and the tree object which corresponds to the top directory of the stored revision.
-Dirty: a working area that contains uncommitted changes.
-Fast-forward: an update operation consisting only of the application of a linear part of the change tree in sequence.
-Fetch: update your local repository database (not your working area) with the latest changes from a remote.
-HEAD: the latest state of the current branch.
-Index: a collection of files with stat information, whose contents are stored as objects. The index is a stored version of your working tree. Files may be staged to an index prior to committing.
-Master: the main branch: known as the trunk in other SCM systems.
-Merge: join two trees. A commit is made if this is not a fast-forward operations (or one is requested explicitly.
-Object: the unit of storage in git. It is uniquely identified by the SHA1 hash of its contents. Consequently, an object can not be changed.
-Origin: the default remote, usually the source for the clone operation that created the local repository.
-Plumbing: the low level core of git.
-Porcelain: higher level, user-visible interfaces to the plumbing.
-Pull: shorthand for a fetch followed by a merge (or rebase if
--rebase option is used).
-Push: transfer the state of the current branch to a remote tracking branch. This must be a fast-forward operation (see merge).
-Rebase: a merge-like operation in which the change tree is rewritten (see Rebasing below). Used to turn non-trivial merges into fast-forward operations.
These core tutorials will help you to learn the Tips & Tricks in GIT. For an in-depth understanding and practical
experience, explore Git Essential Training.
-Ref: a 40-byte hex representation of a SHA1 or a name that denotes a particular object.
-Remote: another repository known to this one. If the local repository was created with "clone" then there is at least one remote, usually called, "origin."
-Stage: to add a file or selected changes therefrom to the index in preparation for a commit.
-Stash: a stack onto which the current set of uncommitted changes can be put (eg in order to switch to or synchronize with another branch) as a patch for retrieval later. Also the act of putting changes onto this stack.
-Tag: human-readable label for a particular state of the tree. Tags may be simple (in which case they are actually branches) or annotated (analogous to a CVS tag), with an associated SHA1 hash and message. Annotated tags are preferable in general.
-Tracking branch: a branch on a remote which is the default source / sink for pull / push operations respectively for the current branch. For instance, origin/master is the tracking branch for the local master in a local repository.
-Tree-ish: a ref pointing to either a commit object, a tree object, or a tag object pointing to a tag or commit or tree object.
-Un-tracked: not known currently to git.
This module presents a broad survey of useful Git utilities. We’ll take a step back from the theoretical aspects of Git and focus on common tasks like preparing a project for release and backing up a repository. While working through this module, your goal shouldn’t be to master all of these miscellaneous tools, but rather to understand why they were created and when they might come in handy.
If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download it directly from the Git source code at https://github.com/git/git/blob/master/contrib/completion/git-completion.bash . Copy this file to your home directory, and add this to your
If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the
/opt/local/etc/bash_completion.d directory on Mac systems or to the
/etc/bash_completion.d/ directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions.
If you’re using Windows with Git Bash, which is the default when installing Git on Windows with msysGit, auto-completion should be preconfigured.
Press the Tab key when you’re writing a Git command, and it should return a set of suggestions for you to pick from:
$ git co<tab><tab>
In this case, typing
git co and then pressing the Tab key twice suggests commit and config. Adding
git commit automatically.
This also works with options, which is probably more useful. For instance, if you’re running a
git logcommand and can’t remember one of the options, you can start typing it and press Tab to see what matches:
$ git log --s<tab><tab>
That’s a pretty nice trick and may save you some time and documentation reading.
Learn more about Git Interview Questions in this blog post.
Git doesn’t infer your command if you type it in partially. If you don’t want to type the entire text of each of the Git commands, you can easily set up an alias for each command using
git config. Here are a couple of examples you may want to set up:
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
This means that, for example, instead of typing
git commit, you just need to type
git ci. As you go on using Git, you’ll probably use other commands frequently as well; in this case, don’t hesitate to create new aliases.
This technique can also be very useful in creating commands that you think should exist. For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git:
$ git config --global alias.unstage 'reset HEAD --'
This makes the following two commands equivalent:
$ git unstage fileA
$ git reset HEAD fileA
This seems a bit clearer. It’s also common to add a
last command, like this:
$ git config --global alias.last 'log -1 HEAD'
This way, you can see the last commit easily:
$ git last
Author: Josh Goebel <email@example.com>
Date: Tue Aug 26 19:48:51 2008 +0800
test for current head
Signed-off-by: Scott Chacon <firstname.lastname@example.org>
As you can tell, Git simply replaces the new command with whatever you alias it to. However, maybe you want to run an external command, rather than a Git subcommand. In that case, you start the command with a
! character. This is useful if you write your own tools that work with a Git repository. We can demonstrate by aliasing
git visual to run
$ git config --global alias.visual '!gitk'
For an Indepth knowledge on Git, click on below