Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

svn to GIT

No description
by

Yosi Oren

on 9 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of svn to GIT

Set up Subversion upgrade GiT But what is GiT? Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows. Where is git better than svn reference: http://git-scm.com/about/branching-and-merging Branching and merging The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.

Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

This means that you can do things like:
Frictionless Context Switching: Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, and merge it in.
Role-Based Codelines. Have a branch that always contains only what goes to production, another that you merge work into for testing, and several smaller ones for day to day work.
Feature Based Workflow. Create new branches for each new feature you're working on so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
Disposable Experimentation. Create a branch to experiment in, realize it's not going to work, and just delete it - abandoning the work—with nobody else ever seeing it (even if you've pushed other branches in the meantime).

Notably, when you push to a remote repository, you do not have to push all of your branches. You can choose to share just one of your branches, a few of them, or all of them. This tends to free people to try new ideas without worrying about having to plan how and when they are going to merge it in or share it with others.

reference: http://git-scm.com/about/branching-and-merging Small and Fast Git is fast. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

In general, Git is one or two orders of magnitude faster than SVN, even under ideal conditions for SVN.

One place where Git is slower is in the initial clone operation. Here, Git is downloading the entire history rather than only the latest version. Even then, it is not that much slower than a regular svn checkout.

Talk about the fact that the compression is amazing, therefore, having the entire project doesn't take much more space than the svn trunk.

Reference: http://git-scm.com/about/small-and-fast Distributed One of the nicest features of any Distributed SCM, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.

Multiple Backups
This means that even if you're using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.

Untethered to a remote
Because developers have the full copy of the repository, remote work doesn't prevent normal scm usage, such as branching and reverting if needed.

Any Workflow
Because of Git's distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.

Reference: http://git-scm.com/about/distributed Data Assurance The data model that Git uses ensures the cryptographic integrity of every bit of your project. Every file and commit is checksummed and retrieved by its checksum when checked back out. It's impossible to get anything out of Git other than the exact bits you put in.

Reference: http://git-scm.com/about/info-assurance Staging Area Unlike the other systems, Git has something called the "staging area" or "index". This is an intermediate area where commits can be formatted and reviewed before completing the commit.

With Git it is possible to quickly stage some of your files and commit them without committing all of the other modified files in your working directory or having to list them on the command line during the commit.

In SVN you would have to specify the files to commit in the commit line (or via Tortoise SVN you would pick file to commit).

Reference: http://git-scm.com/about/staging-area What are git weaknesses Steep ramping curves
Tools not as mature (it is often best to use command line interface) Creating a local repo: > cd /path/to/my/project/folder
> git init Adding a file to our newly created repo: > vim readme
> git add readme
> git commit -m "added readme file to repo"
> git log > git clone ssh://bob@build-ios-us.pus.local/Repo/MyProject.git Scenario 1: Exporting an existing local git database to the remote server You've framed your project, and are ready to share it with the team!
> git remote add origin ssh://bob@build-ios-us.pus.local/Repo/MyProject.git
> git push

Remember: Git can share with multiple remotes! You can add as many remote
as you want to your local project:
> git remote add theOldOnes ssh://azathoth@github.com/azathoth/MyProject.git
> git pull theOldOnes or git push theOldOnes Scenario 2: You joined an existing project and need to work on the code Your Identity

> git config --global user.name "Cthulhu"
> git config --global user.email cthulhu@theoldones.com Your difftool and mergetool To configure for kdiff3 simply do:

> git config --global merge.tool kdiff3
> git config --global mergetool.kdiff3.path "c:\pathto\KDiff3\kdiff3.exe"
> git config --global diff.tool kdiff3
> git config --global difftool.kdiff3.path "c:\pathto\KDiff3\kdiff3.exe" File Edited Let’s change a file that was already tracked. If you change a previously tracked file called CthulhuRocks and then run your status command again, you get something that looks like this:

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: CthulhuRocks
# Ignoring Files Much like with svn, you can choose to ignore files to be commited. This is done via the .gitignore file.
Simply put the file at the root of the project along with the ignore rules and you will be all set:

> less .gitignore
# a comment - this is ignored
*.a # no .a files
!lib.a # but do track lib.a, even though you're ignoring .a files above
/TODO # only ignore the root TODO file, not subdir/TODO
build/ # ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt Checking the Status of Your Files - git status When working inside a repo, it is always a good idea to know what has changed and what has not. This is where git status comes into play:

On a clean repo, git status will display:
> git status
# On branch master
nothing to commit (working directory clean)

Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run git status, you see your untracked file like so:

> vim README
> git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use "git add" to track) Staging Modified Files The CthulhuRocks file appears under a section named “Changed but not updated” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the git add command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run git add now to stage the CthulhuRocks file, and then run git status again:

$ git add CthulhuRocks
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: CthulhuRocks Viewing Your Staged and Unstaged Changes git diff <or> git difftool

What have you changed but not yet staged?

> git diff

And what have you staged that you are about to commit?

> git diff --cached

*add a diff sample* Committing Your Changes Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run git add on since you edited them — won’t go into this commit.

The simplest way to commit is to type:

> git commit

This will bring up your editor of choice and allow you to enter a comment for your commit.

You can also specify the comment on the command line:

> git commit -m "some comment"

NOTE: Git won't accept the commit if you leave the comment empty. Skipping the Staging Area Providing the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add or git rm part.

> git commit -a -m "some comments" Removing Files To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around.

If you simply remove the file from your working directory, it shows up under the “Changed but not updated” (that is, unstaged) area of your git status output. Then, if you run git rm, it stages the file’s removal.

> rm CthulhuRocks
> git rm CthulhuRocks (stages for removal, svn: svn delete CthulhuRocks)
> git commit -m "removed CthulhuRocks :(" Undoing things - amending last commit Why would you need to do this!

Maybe you did your commit a little too fast and realized that you forgot to add a file, or you want to edit the commit comment again.

For example:

> git commit -m "some commit"

Ooops... forgot a file:

> git add forgotten-file
> git commit --amend Undoing things - reverting changes for a Modified File Undoing things - Unstaging a Staged File > git add .
> git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: README.txt
# modified: CthulhuRocks
#
> git reset HEAD CthulhuRocks
> git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: README.txt
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory) #
# modified: CthulhuRocks
# You've added a file for staging and at the last minute you realize that you don't want that file to be commited right away: To pull latest from a remote into your local repository, you simply do
> git fetch origin

Note: This does not merge the remote stuff inside your local stuff. Each git remotes ends up in its own branch.

Git default branch (trunk) is called master. If you have a remote called origin, you will have a branch called origin/master. Git fetch simply pull the latest from the remote into origin master.

This allow you to compare the latest with your local before merging.

You then have to merge the remote stuff:
> git merge origin/master SHORTCUT: If you plan to always fetch and merge, you can simply do:
> git pull origin master (this internally does a git fetch + a git merge Pushing to Your Remotes When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: git push [remote-name] [branch-name].

For example:
> git push origin master

This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime.

If you and someone else push upstream before you and then you push upstream, your push will rightly be rejected. You’ll have to pull down their work first and incorporate it into yours before you’ll be allowed to push. Branching and Merging Small and Fast Distributed Data Assurance Staging Area Free and open source Working Directory Local GIT Untracked Unmodified Modified Staged Tracking New Files In order to begin tracking a new file, you use the command git add. To begin tracking the README file, you can run this:

> git add README

If you run your status command again, you can see that your README file is now tracked and staged:

> git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# Add The File Edit the file Stage the file Commit Remove the file Unstage Unmodify What if you realize that you don’t want to keep your changes to the CthulhuRocks file? How can you easily unmodify it — revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)?

Simple! git status tells you what you need to do. No need to google for it:

> git status
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: CthulhuRocks

> git checkout -- CthulhuRocks
> git status# On branch master# Changes to be committed:# Add commit RM Reset Pull Fetch Push Remote Origin Merge checkout Thank You Branch A light weight pointer to a commit - Not a copy C1 Master C1 C2 C3 Master C1 C2 Master C1 C2 C3 Master dev HEAD C1 C2 C3 Master dev HEAD C4 C1 C2 C3 Master dev HEAD C4 C5
Full transcript