GIT
&
a Beautiful world..
Before that...
Let's go back to
Uncle Sam's World!
What we had before
-
Concurrent Version System (CVS)
-
Sub Versioning (SVN)
-
GIT (The name is Git..Just GIT)
GIT
How it actually happened..?
When someone realized..
- In the very beginning, Git began with a bit of creative destruction and fiery controversy.
- Specifically built to handle code-base of Linux Kernel.
- In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.
- In 2005, the relationship between the Linux community and the company behind BitKeeper broke down, and the tool’s free-of-charge status was revoked.
- Prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.
Yeah... I Know...
( A little background of how it all started )
Once you start talking about branching, merging, rebasing, multiple remotes, remote-tracking branches, detached HEAD states… Git becomes less of an easily-understood tool and more of a feared deity. Anybody who talks about no-fast-forward merges is regarded with quiet superstition, and even veteran hackers would rather stay away from rebasing “just to be safe”
>>>
You don’t need to worry about all of this just yet...
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...
Repositories
- Blobs, which are the most basic data type in Git. Essentially, a blob is just a bunch of bytes; usually a binary representation of a file.
- Tree objects, which are a bit like directories. Tree objects can contain pointers to blobs and other tree objects.
- Commit objects, which point to a single tree object, and contain some metadata including the commit author and any parent commits.
- Tag objects, which point to a single commit object, and contain some metadata.
- References, which are pointers to a single object (usually a commit or tag object).
Commits
-
A commit object is essentially a pointer that contains a few pieces of important metadata. The commit itself has a hash, which is built from a combination of the metadata;
- The hash of the tree (the root tree object) at the time of the commit. This means that with a single commit, Git can build the entire working tree by recursing into the tree.
-
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.
References
- We saw how objects in Git are identified by a hash
-
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.
Branches
-
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.
Tags
-
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
Merging
- Merging in Git is the process of joining two histories (usually branches) together.
- I hope everyone knows about it, but still we will take that up in hands-on section.
Some of the things which I am skipping..
- Rebase
- Cherry pick
Remotes
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.
Cloning
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.
- Check out the branch which is currently active (HEAD) on the remote.
-
Perform a git pull to bring the current branch and working tree up-to-date with the remote.
Let's get our Hands dirty..
- git init
- Writing a file
- Adding a file to commit
- Committing it locally with a proper message.
- Adding a remote
- Pushing it to the branch
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]
Continued
- git stash
- git log
GIT FLOW
References
-
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..)
Thank you!
github : nishant-shrivastava
twitter : @n1shant
GIT and best practices
By Nishant Shrivastava
GIT and best practices
Slides for GIT session and best practices to follow. Has a basic of GIT and history before it, for Code versioning.
- 505