Git why using Git instead

SVN

The answer is ... the way Git think

Version control systems have traditionally required a
lot of up-front planning followed by constant interaction to
get changes to the right place at the right time and in the
right order.
The way Git think about source control as its data,
states (repository (local and remotes), staging area,
working), trees, branches, distributed model and
implementing .

Content
The snapshots Git
The distributed Git
Branches and merge
The implementation
The repository
The staging area or the index
Support to using parallel git and svn

The snapshots Git

The major difference between Git and any other VCS (SVN,
etc) is the way Git thinks about its data. - Scott Chacon.

Git is snapshot based, not patches or changes based.

The snapshot Git (cont)

There systems (CVS, SVN and so on) think of the
information they keep as set of files and the change
made to each file over time.

The snapshots Git

Unlike it, Git thinks of its data more like a set of
snapshots of a mini file system.
Takes a picture of what all your files look like, and
stores a reference to that snapshot.
Git doesnt store the file againjust a link to the
previous identical file it has already stored.

The snapshots Git (cont)

This is an important distinction and advance feature
between Git and SVN.
Git is very efficient in storing text files, and only storing
these files that were changed.
It makes Git more like a mini file system.
It makes Git reconsider almost every aspect of version
control.
It makes Git branching to become magic feature of
Git

How Git store content

It stores the repository in such a logical way, using far fewer
files and much less disk space than Subversion
Each file, no matter its location in the tree or history is only
stored once.
The repository is stored in a single .git folder at the top level
of your working directory. Subversion needs a .svn folder
inside each folder of the working directory.
In SVN, the working directory holds two extra files for each file,
plus some more file and folders for each directory. Git needs
none of these.
Its more efficient, dont need to make sure all your tools have
special handling for the invisible .svn folders.

The distributed Git

SVN is a Centralized CVS.
There is only a single repository to check out and check in
source code. So, what happed is it if server is crashed or
corrupted?
It must work online or requires that you maintain a network
connection to the central repository in order to track the changes
that you make. What happed is it if it can't connect to internet ?
Branching and merging is difficult. But you want work in new
branch for test or try experiencing
More management: all setting dependent on manager such as
add new users, change pass, create project and so on.
It seems be disadvantage to you in some way.

The distributed Git (cont)

Git is a Distributed CVS. It can resolve
problems that meeting with SVN.
Multiple Backups
You do a clone of the entire repository, as
copy of the repository. So, it will a backup for
the main server when it need. And it only using
command: git clone bare [add server/project]
Local repository
Each developer has their own copy of the
repository. So, you can work offline:
Can commit, merge, resolve conflict offline
Making a change to your copy affects just
your repository by commit your code.

 Branching and merging is easy. Because every

developer has their own branch, every shared change
is like reverse integration. But the guilds make it easy to
automatically combine changes and avoid duplicates.

The distributed Git (cont)

Decentralized but centralized
Centralized: all developers push to
the same remote server. It is default
called origin.
Decentralized multi remote
server : each developer may also pull
changes from other peers to form sub
teams. ( it neednt publish to main
server)
Any workflow: A centralized
workflow; Integration Manager
Workflow; Dictator and Lieutenants
Workflow.

The distributed Git (cont)

This advantage Gits feature
Multiple shared repositories
Multiple remote server.
Gives the team leads an extra opportunity to review the
code that was created by their team before sharing it with
everyone else.
Suitable for everyone: people coming to Git from a
traditional centralized repository or who have never used
version control or who are wanting to change completely.

Branching and merging

Git supports branching and merging far better than
Subversion did:
In Subversion, branches all are copies. Sometimes, it is
easy to check out the whole repository by mistake
Branches are so core in Git because every developers
working directory is itself a branch. They used every day by
every user.
Branch master consider trunk in SVN

Branching and merging in SVN

Create a branch:
be placed under the /branches/ folder in the repository
Generally, projects that take more than a day or two to
complete should be considered for branching
$ svn copy http://.../trunk
http://.../branches/Mybranch -m comment
here
Switch a blanch
$ mkdir /your/local/copy //if dont have a
local copy
$ cd /your/local/copy
$ svn checkout http://.../branches/MyBranch
.

 Merge branches with the trunk:

Updating Your Branch The First Time

Bring your local copy up to date: $ svn update
Merge from trunk to your branch:
$ svn merge r[] url .
Commit the merged changes back to your branch
$ svn ci -m .
Updating Your Branch More Than Once
Update your working copy of the branch :
$ svn update
Merge trunk starting where the last merge left off:
$ svn merge r [revision] url .
Commit the merged changes back to your branch

$ svn ci -m "" .
Handling Branch Conflicts

 Back to the trunk

$ cd /your/local/copy
$ svn update
At revision 3400.
$ svn switch http://.../branches/MyBranch
$ svn merge -r3328:3400
http://.../branches/MyBranch .
(MyBranch was created at revision number
3328)
$ svn ci -m "branch back MyBranch into
trunk" .
Delete a branch
$ svn del http://.../branches/MyBranch
do you think SVN are more cumbersome?

In Git, branching and merging is easy.

Create a branch
$ git branch iss53

Switch a branch
$ git checkout iss53
Back to master
$ git checkout master
Merge with master (in iss53 branch)
$ git rebase master
Delete a brach: $git branch d
iss53
Do you think it is simply?

More advantage: easy staging temporary work.

EX:

 Easy staging temporary work.

You are working in a branch. You need fix a bug in
another branch or get o problem and want to try a new
resolve. You can do:
Stashing Temporary Work ( in branch A)
$ git stash

Switch to another branches B

$ git checkout B

Switch to branch A to resume work

$ git checkout A
$ git stash apply

 The key thing to note is how we switch between branches.

In Git, the repository handles this.
With SVN, youre literally just working on a separate set of
files.
If you branch a lot, this quickly becomes annoying, time
consuming, and non-productive. With Git, it magically
changes all of the files on your file system for you.
Git will float uncommitted changes.
Did a git checkout B, bring all of the uncommitted work in
A. But you dont need commit A. Instead, you stash your
work. Using it will tuck away your WIP changes without a
formal commit.
The Subversion method is simpler, but you could potentially
end up with several half-baked branches and no record of
when you abandoned them.

Merging in SVN
It's hardly to merge in a CVCS; therefore branches
tend not to happen
Easily get lost particularly when refactoring start
happening, unless merge to HEAD frequently.
The killer is not only do there include a bunch of changes
already made from trunk. Changes that occurred in the past
to trunk are now showing up again in the merge and SVN
get very confused.
Example:

This picture show the sequence of the changes to a single file in a

repo. T0,T1,T3,T4 indicate points in time at which file is edited and is
also the order in which the modification took place. This is
important to SVN.
When get to T5 and merge your branch into trunk, the sequence
looks like: T1 already was in trunk, and was reapplied to the branch;
T0 from the merge at T2;T4 was already in trunk then T3.
So the order the merge tries to resolve is T1, T0, T4, T3. But, T1, T4
are already committed to trunk so just T1, T3.
But since changes are in terms of the previous state of the file
being changed, T3s modifications knew nothing about T4s
modifications, so you are applying modifications out of order.

Merging in Git
Merging in Git is simply
Every commit, git take a snapshot file and stores a
reference to that snapshot. It is not only do you know what
changes need to be made, but also what point in history they
need to be made. So, Git will be able to apply the change
and then play forward the changes.

Merging workflows
Git using the two snapshots pointed
to by the branch tips and the
common ancestor of the two.
Instead of just moving the branch
pointer forward, Git creates a new
snapshot and automatically creates
a new commit that points to it.
This is referred to as a merge
commit and is special in that it has
more than one parent.
So, by using a command:
$ git merge [branch]
It is easy to merge two branch with
only resolve confict if having.

git merge iss53

The implementation
SVN

Server

Central repository

Git
Remote Repository
fetch

Client

push

Local Repository
commit
update

reset

The index
checkout

Working directory

commit

add

Working directory

The implementation
SVN

Server

Git

Central repository
Difference

Client

Remote Repository
fetch

push

Local Repository
commit
update

Difference

reset

The index
checkout

Working directory

commit

add

Working directory

Repository
In SVN, there is only a repository that called central
repository, and is located in a server.
Advantage: the projects source code always sync.
Disadvantage:
Might commit unfinished code to server that can
make a lot of conflict and break your prorect.
Cannot preview how projects code effect to if you
dont commit your code.
Difficult to try new feature or another resolve.
Your work doesn't always finish in a short time and right
way, does you?

Repository
Git have two repositories (remote and local) and two
types repository as bare and non-bare.
A "bare" repository contains the version control information,
no working files
It doesn't contain the special .git sub-directory.
It cannot do any change in this repository. A remote
repository is a bare repository.
The repository has to be "bare" in order to accept a push.
only use a "bare" repo to clone, pull from, and push to.
A non-bare repository has working files and .git subdirectory.
It can work in non-bare repository. A local repository is a
non-bare repository.

Repository
The remote repository
Git thing it only a place to share code
Can place any where or you have multi remote server.
In normal, always have a remote repository to sync
code of project
The local repository
Can work offline: commit code, merge code and
resolve conflict.
Only need network when sync source code with
remote repository.
Save your time when commit code.
Easy try or test new way of resolve that dont break
projects source code

The staging or index a great feature

It is a file named index on lies in local .git repository.
St, you have code that you re not quite sure to commit but
want to store. The staging is the place to store there files or
take a snapshot there files by using command: $ git
add
The main advantage of index is it can define exactly which
changes to commit and which to leave for a later commit.
Git does not force to use the staging feature. To directly
going from the working directory to the local repository,
using $ git commit -a m file.
Easy to know what file are saved or not by using
$ git status

The index
Let see this situation to understand the useful of the index.
Suppose that, you start work on some an enhancements.
After screwing around, you give up, leave the half-baked
changes in my working copy. Then, you working again and
have a problem. Using git status to see where your working
is at and having some files changed but not updated such
as a, b, c, d. have two unrelated changes in my working
copy: a, b file are not ready commit and push into remote
server and c, d file needs a commit immediately.
The big problem here is c file it's "tangled" in the sense
that it includes modifications from two different logical
changes and need to tease these changes apart into two
separate commits.

What does SVN resolve this problem?

1. You should have committed the experimental changes
to a separate branch before working on.
2. Using Subversion, might go at it like this:
a. Run svn diff
b. Remove hunks from the diff and write the diff out to commentstuff.diff.
c. Run patch -p0 -R < comment-stuff.diff.
d. Commit the bookmark related fixes
e. Run patch -p0 < comment-stuff.diff
f. Forget to create branch for comment stuff, again.
g. Hack on comment stuff for a while.
h. Find more unrelated brokeness and fix it.
i. Oops! GOTO a.

What does Git resolve this problem?

The index is more useful and become a great feature.
$ git add --patch c.rb
diff --git a/c.rb b/c.rb
index be4159d..3efd4ce 100644
--- a/c.rb
+++ b/c.rb
@@ -256,7 +256,7 @@

Stage this hunk [y/n/a/d/j/J/k/K/s]?

The magic is in the --patch argument the files specified
on a hunk-by-hunk basis and lets choose one of options
[y/n/a/d/j/J/k/K/s]

Support using parallel Git and SVN

You realize that in some side, Git is better than SVN
You want to using Git. But, your company, your co-dev are
used to using SVN.
It is not a problem
Git support using parallel Git and SVN with command
$ git svn
Retain SVNs features such as : centralized repository