Version Control

1.What is “version control”, and why should you care

Version control is a system that records

changes to a file or set of files over time so that you can recall specific versions later.

2. Local Version Control Systems

Many people’s version-control method of choice is to copy files into another directory

3. Centralized Version Control Systems

Centralized Version Control Systems (CVCSs) were
developed. These systems (such as CVS, Subversion, and Perforce) have a single server
that contains
all the versioned files, and a number of clients that check out files from that central
place.

Figure 1 Centralized version control

Advantages

everyone knows to a certain degree what everyone else on the project is doing.
Administrators have fine-grained control
over who can do what, and it’s far easier to administer a CVCS than it is to deal with local
databases
on every client

Disadvantages

The most obvious is the single point of failure

that the centralized server represents. If that server goes down for an hour, then during that hour
nobody can collaborate at all or save versioned changes to anything they’re working on. If the
hard
disk the central database is on becomes corrupted,

4 Distributed Version Control Systems

clients don’t just check out the latest snapshot of the files; rather, they fully
mirror the repository, including its full history. Thus, if any server dies, and these systems were
collaborating via that server, any of the client repositories can be copied back up to the server to
restore it. Every clone is really a full backup of all the data.

5. What is Git?

The major difference between Git and any other VCS (Subversion and friends included)
is the way
Git thinks about its data. Conceptually, most other systems store information as a list of
file-based
changes. These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the
information they store as a set of files and the changes made to each file over time (this
is
commonly described as delta-based version control).

Following figure 2 Git doesn’t think of or store its data this way.
Instead
 Figure 2:Storing data as changes to a base version of each file.

Git thinks of its data more like a series of

snapshots of a miniature filesystem. With Git, every time you commit, or save the state of
your
project,

Git basically takes a picture of what all your files look like at that moment and stores a
reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the
file again,
just a link to the previous identical file it has already stored.

Figure 3:git storing data as snapshot

Git doesn’t need to go out to the server to get the

history and display it for you — it simply reads it directly from your local database.

6.Git Integrity
Everything in Git is check summed before it is stored and is then referred to by that checksum.
This
means it’s impossible to change the contents of any file or directory without Git knowing about it.
This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t
lose
information in transit or get file corruption without Git being able to detect it.

Git uses for this checksumming is called a SHA-1 hash

Git stores everything in its database not by file name but by the hash value of its
contents.

When you do actions in Git, nearly all of them only add data to the Git database. It is
hard to get the
system to do anything that is not undoable or to make it erase data in any way.

7.Git states

modified, staged, and committed

Figure 4 git stages

• 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.
• Committed means that the data is safely stored in your local database.

The working tree 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 file, generally contained in your Git directory, that stores information about
what will go into your next commit. Its technical name in Git parlance is the “index”, but the
phrase “staging area” works just as well.

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.

8.After Git installation

Your Identity
The first thing you should do when you install Git is to set your user name and email
address. This
is important because every Git commit uses this information, and it’s immutably baked
into the
commits you start creating:

$ git config --global user.name "John Doe"

$ git config --global user.email [email protected]

you need to do this only once if you pass the --global option, because then Git will always
use that information for anything you do on that system. If you want to override this
with a
different name or email address for specific projects, you can run the command without
the
--global option when you’re in that project.
Your Editor
you can configure the default text editor that will be used when Git
needs you to type in a message. If not configured, Git uses your system’s default editor

. $ git config --global core.editor emacs

Checking Your Settings

If you want to check your configuration settings, you can use the git config --list
command to list
all the settings Git can find at that point:

you can also check what Git thinks a specific key’s value is by typing git config <key>:

$ git config user.name

Getting Help
If you ever need help while using Git, there are three equivalent ways to get the comprehensive
manual page (manpage) help for any of the Git commands:

$ git help <verb>

$ git <verb> --help
$ man git-<verb>

9.Git Basic
Initializing a Repository in an Existing Directory

$ cd /c/user/my_project
$ git init

This creates a new subdirectory named. git that contains all of your necessary repository files — a
Git repository skeleton.

If you want to start version-controlling existing files (as opposed to an empty directory),
you should
probably begin tracking those files and do an initial commit.

$ git add *.c

$ git add LICENSE
$ git commit -m 'initial project version'

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

$ git clone https://github.com/libgit2/libgit2

That command does the same thing as the previous one, but the target directory is called mylibgit.

$ git clone https://github.com/libgit2/libgit2 mylibgit

10. Recording Changes to the Repository