( A little background of how it all started )
The important thing to remember about a Git repository is that it exists entirely in a single .gitdirectory in your project root. There is no central repository like in Subversion or CVS. This is what allows Git to be a distributed version control system – everybody has their own self-contained version of a repository.
$ git init
Initialized empty Git repository in /home/demo/demo-repository/.git/
$ ls -l .git
total 32
drwxrwxr-x 2 demo demo 4096 May 29 20:10 branches
-rw-rw-r-- 1 demo demo 92 May 29 20:10 config
-rw-rw-r-- 1 demo demo 73 May 29 20:10 description
-rw-rw-r-- 1 demo demo 23 May 29 20:10 HEAD
drwxrwxr-x 2 demo demo 4096 May 29 20:10 hooks
drwxrwxr-x 2 demo demo 4096 May 29 20:10 info
drwxrwxr-x 4 demo demo 4096 May 29 20:10 objects
drwxrwxr-x 4 demo demo 4096 May 29 20:10 refs
Let's take a look inside .git, after git init...
The hash of any parent commits. This is what gives a repository its history
The author’s name and email address, and the time that the changes were authored.
The committer’s name and email address, and the time that the commit was made.
The Commit message.
For manipulating hashed, it's required to know their hashes.
But to do that, we need to remember the hashes, which is not a feasible solution.
To save you from having to memorize these hashes, Git has references, or “refs”.
A reference is simply a file stored somewhere in .git/refs
, containing the hash of a commit object.
Git’s branches are often touted as being one of its strongest features.
Reason behind, branches in Git are very lightweight, compared to other VCS where a branch is usually a clone of the entire repository.
Branches are so lightweight in Git is because they’re just references.
There are two types of tags in Git – lightweight tags and annotated tags
LightWeight Tags
$ git tag 1.0-lightweight
$ cat .git/refs/tags/1.0-lightweight
d409ca76bc919d9ca797f39ae724b7c65700fd27
Annotated Tags
$ git cat-file -p 1.0-lightweight
tree 9d073fcdfaf07a39631ef94bcb3b8268bc2106b1
author Nishant <s.nishant@globaledgesoft.com> 1400976134 -0400
committer Nishant <s.nishant@globaledgesoft.com> 1400976134 -0400
First commit
$ git cat-file -p d409ca7
tree 9d073fcdfaf07a39631ef94bcb3b8268bc2106b1
author Nishant <s.nishant@globaledgesoft.com> 1400976134 -0400
committer Nishant <s.nishant@globaledgesoft.com> 1400976134 -0400
First commit
Some of the things which I am skipping..
In order to collaborate on any Git project, you need to utilise at least one remote repository. Unlike centralised VCS which require a dedicated server daemon, a Git remote is simply another Git repository.
We will dig more on to this later.
The git clone command is really just a shortcut which does a few things for you. With its default configuration, it will:
Create remote-tracking branches for each branch in the remote.
Perform a git pull to bring the current branch and working tree up-to-date with the remote.
Some More..
git branches
Create a branch - git branch [BRANCH NAME]
Checkout - git checkout [BRANCH NAME]
Checkout along creating branch - git checkout -b [BRANCH NAME]
https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
https://en.wikipedia.org/wiki/Git
https://wildlyinaccurate.com/a-hackers-guide-to-git/
https://medium.freecodecamp.com/git-internals-for-curious-developers-a1e44e7ecafe
https://datasift.github.io/gitflow/IntroducingGitFlow.html
https://github.com/nvie/gitflow
https://datasift.github.io/gitflow/IntroducingGitFlow.html
( Read shamelessly copied from..)
github : nishant-shrivastava
twitter : @n1shant