This document is a case study discussing the differences between Git and Subversion (SVN), including features, migration strategies, and benefits of using Git. It provides step-by-step instructions for migrating from SVN to Git, highlighting commands and procedures for seamless integration. The study emphasizes the importance of careful planning and simultaneous use of both systems during migration to ensure team confidence and continuity in development.

1. Case Study:

2.  Introduction
 Distributed Source Code Control
 Git’s Features
 Benefits of Git over SVN
 SVN to Git Migration
 Migrating from SVN to Git
 How to use Git with SVN
 Conclusion
 Sources

3. Section I

5. Repositories URL Revisions
Commits Commands Colors
Visualize

6.  With Subversion, for each project there is a single
repository at some detached central place where all
the history is and which you checkout and commit
into.
 Git works differently, each copy of the project tree
(we call that the working copy) carries its own
repository around (in the .git subdirectory in the
project tree root). So you can have local and remote
branches.
 You can also have a so-called bare repository which is
not attached to a working copy; that is useful
especially when you want to publish your repository

7.  In Subversion the URL identifies the location of
the repository and the path inside the
repository, so you organize the layout of the
repository and its meaning.
 Normally you would have trunk/, branches/ and
tags/ directories.
 In Git the URL is just the location of the
repository, and it always contains branches and
tags.
 One of the branches is the default (normally
named master).

8.  Subversion identifies revisions with ids of decimal
numbers growing monotonically which are typically
small (although they can get quickly to hundreds of
thousands for large projects). That is impractical in
distributed systems like Git.
 Git identifies revisions with SHA1 ids, which are long
160-bit numbers written in hexadecimal. It may look
scary at first, but in practice it is not a big hurdle - you
can refer to the latest revision by HEAD, its parent as
HEAD^ and its parent as HEAD^^ = HEAD~2 (you can
go on adding carrets

9.  Each commit has an author and a committer field,
which record who and when created the change and
who committed it
 Git is designed to work well with patches coming by
mail - in that case, the author and the committer will
be different.
 Git will try to guess your realname and email, but
especially with email it is likely to get it wrong. You
can check it using git config -l and set them with:
 git config --global user.name "Your Name Comes Here"
 git config --global user.email
you@yourdomain.example.com

10.  The Git commands are in the form “git
command <command_name>”.
 Eg- “git commit …. “
 You can interchangeably use the git-
command form as well
 Eg “git-commit ….”

11.  Git can produce colorful output for
commands
 Colors are disabled by default

12.  Watch your repository using the gitk
repository viewer as you go.

13. SVN Git

14. Section II

15. Import your SVN repo into Git
• git svn clone https://svn.foo.com/svn/proj --trunk=trunk --branches=branches --tags=tags
Make your own Git branch
• git checkout -b work trunk
Add the files you changed
• git add <filename>
Commit
• git commit
Want to sync with master SVN?
• git svn dcommit

16.  Why would we want this?
 Since Git is a distributed revision control system
(while svn is a centralized one) you can perform
commits, brances and merges on your local working
dir.
 When you want, you will be able to “push” your
changes back to the central SVN server
 What are the advantages of this approach?
 No downtime. Smooth migration
 Existing system can run as-is while hooks are being
written to integrate git into the system.

17. • install git and git-svn
Install
• create the working dir
Create
• init your git working dir:
Init • cd <workdir> && git-svn init http://your_repo
• Find a commit regarding the project
Find • the command git-log will show project’s history starting from this revision
• Perform the command git-svn fetch –rREVISION
Fetch • Where REVISION is the number obtained before.
• Update your working dir: git-svn rebase
Update
• You can commit your changes using git-svn dcommit
Commit

18.  Sometimes, you may experience some problem when
synchronizing with the main development tree.
 In fact you have to commit all local modifications (using the git-
commit command) before invoking git-svn rebase.
 Sometimes it isn’t reasonable since your changes are not yet ready
to be committed.
 git has a native solution also for this problem, just follow these
steps:
 put aside your changes using the command: git-stash
 update your working copy using: git-svn rebase as usual
 take back your changes typing: git-stash apply
 clear the stash by typing: git-stash clear
 After the first step all your uncommitted changes will disappear
from the working copy, so you’ll be able to perform the rebase
command without problems.
 For further informations read git-stash man page.

19.  A DSCM gives a lot of flexibility when
development is happening across various
team.
 Care needs to be taken while doing an SVN
 git migration.
 SVN & git should be used simultaneously
until the team is confident about git.