Git
A distributed version control system
BySachin Singh
C.S (B)
Under Guidance OfMr. M. Jha
05/05/16
Version control systems
Version control (or revision control, or source control) is all
about managing multiple versions of documents, programs, web
sites, etc.
Some well-known version control systems are CVS, Subversion,
Mercurial, and Git
Almost all real projects use some kind of version control
Essential for team projects, but also very useful for individual projects
CVS and Subversion use a central repository; users check out files,
work on them, and check them in
Mercurial and Git treat all repositories as equal
Distributed systems like Mercurial and Git are newer and are
gradually replacing centralized systems like CVS and Subversion
2
Why version control?
For working by yourself:
For working with others:
Gives you a time machine for going back to earlier versions
Gives you great support for different versions (standalone,
web app, etc.) of the same basic project
Greatly simplifies concurrent work, merging changes
For getting an internship or job:
Any company with a clue uses some kind of version control
Companies without a clue are bad places to work
History
Created by Linus Torvalds for work on
the Linux kernel ~2005
Some of the companies that use git:
Why Git?
Git has many advantages over earlier systems such as
CVS and Subversion
More efficient, better workflow, etc.
More Functions
Data saves locally
Very fast operations compared to other VCS
Distributed Version
Control
Create and fill a repository
1. cd to the project directory you want to use
2. Type in git init
This creates the repository (a directory named .git)
You seldom (if ever) need to look inside this directory
3. Type in git add
This adds all your current files to the repository
4. Type in git commit m "Initial commit"
You can use a different commit message, if you like
The repository
Your top-level working directory contains everything about
your project
At any time, you can take a snapshot of everything (or selected
things) in your project directory, and put it in your repository
The working directory probably contains many subdirectoriessource
code, binaries, documentation, data files, etc.
One of these subdirectories, named .git, is your repository
This snapshot is called a commit object
The commit object contains (1) a set of files, (2) references to the
parents of the commit object, and (3) a unique SHA1 name
Commit objects do not require huge amounts of memory
You can work as much as you like in your working directory, but
the repository isnt updated until you commit something
8
Commits and graphs
A commit is when you tell git that a change (or addition) you
have made is ready to be included in the project
When you commit your change to git, it creates a commit object
A commit object represents the complete state of the project, including all
the files in the project
The very first commit object has no parents
Usually, you take some commit object, make some changes, and create a
new commit object; the original commit object is the parent of the new
commit object
You can also merge two commit objects to form a new one
Hence, most commit objects have a single parent
The new commit object has two parents
Hence, commit objects form a directed graph
Git is all about using and manipulating this graph
9
Working with your own repository
A head is a reference to a commit object
The current head is called HEAD (all caps)
Usually, you will take HEAD (the current commit object), make
some changes to it, and commit the changes, creating a new
current commit object
You can also take any previous commit object, make changes to
it, and commit those changes
This results in a linear graph: A B C HEAD
This creates a branch in the graph of commit objects
You can merge any previous commit objects
This joins branches in the commit graph
10
Branches Illustrated
Working with others
All repositories are equal, but it is convenient to have one central
repository in the cloud
Heres what you normally do:
Download the current HEAD from the central repository
Make your changes
Commit your changes to your local repository
Check to make sure someone else on your team hasnt updated the central
repository since you got it
Upload your changes to the central repository
If the central repository has changed since you got it:
It is your responsibility to merge your two versions
This is a strong incentive to commit and upload often!
Git can often do this for you, if there arent incompatible changes
12
Multiple versions
Initial commit
Second commit
Third commit
Exp. gets a copy
Fourth commit
Exp. commit
Merge
13
Keeping it simple
If you:
Then you dont have to worry about resolving conflicts or
working with multiple branches
Make sure you are current with the central repository
Make some improvements to your code
Update the central repository before anyone else does
All the complexity in git comes from dealing with these
Therefore:
Make sure you are up-to-date before starting to work
Commit and update the central repository frequently
14
End Of
Presentation
