SVN Git Cheat Sheet

Incidently, the AmonI svn server is

getting started

Git: SVN:


For SVN, if you use a different user name on your server than on the computer you are calling it from, you need the flag --username [me] right after svn.

Info commands

This directory is under version control - Tell me about the code?
svn info
git status
Lists the repository URL (see below), the checked out revision number etc.

What's available on the repository server?
svn list URL
URL is something like, where svn-repos is the path to the repository on the server, assuming you're serving svn via Apache.  This lists the top level directories.

Who's done what lately?
svn log
git log
Lists the commit comments (in reverse order).

Starting new repositories or getting started with one

Doing stuff remotely in git requires the remote argument.  Here we're adding a repository, which takes two arguments
git remote add repoName

Assuming that you want to start from someone else's, then you want to use clone, then probably branch or some such.

Check out the directory 'Module'
svn checkout URL/Module
Note: This does not lock Module.  Others may do the same as you and cheerfully make inconsistent changes.  These are resolved by one or other of you on commit.
svn checkout URL/Module MyModule checks out directory Module but call it MyModule

Creating a new branch in an existing git repository you're already working on
git branch branchName
git branch With no arguments, tells you what branches exist
To actually start work in a branch, you have to checkout
git checkout branchName
When you are done, you have to kind of pull a merge into the main tree by first switching back to it
git chekout master
git merge branchName

git branch -d branchName  Clean up the branch since you're done with it
git push  If you want anyone else to know

Making and getting changes in repositories

Update your checked out copy to the latest version (pull latest version from the [for git: a specified] server).
svn update
git pull repoName master
Note: this only updates files at or beneath your current directory level.

If you have already made changes locally, then pulling changes will result in an attempt to merge.  If there are conflicts git can't just guess about, you need to do
git mergetool
which will (on OS X) pop up "openmerge" a local OS X tool (if you've installed xcode). You basically scroll down through the files, the arrows indicate which is the current favourite, red arrows are conflicts it couldn't resolve.  There's a little menu at the bottom with which you can change any decisions, whether they are red or not.  Eventually you can save the merged document and exit, saying the merge was successful. At this point, you still have to commit (see below) before you are allowed to push (also see below) your merge.

Commit your changes (send your changes to the server for others to see).
svn commit [files to commit] [-m 'my message']
git commit [-m "my message"] these are not equivalent commands

Git expects that stuff you are going  to commit is already in "the staging area", but even so it's commit is not a real (old-school) commit. Git commit just kind of wraps things up for you, but you also need to push it somewhere if anyone else is going to see it.  I guess this is the libertarian aspect of git, it's committed because it is on your machine, and the rest of the world is just lucky if they get to see it.

To put something in the staging area, you have to add it, even if the file is not new.  To stage everything in the directory, including new files and the removal of files, as well as any edits, type
git add -A before the commit!  Now you still have to push.  Otherwise, add files by name.  But first, a word about SVN...

For SVN: Leaving out 'my message' means the value of shell variable SVN_EDITOR will pop up for your message (or the system's default editor).  Leaving out the file list means everything uncommitted is committed.

push tells git where to put commits. -u tells git to remember arguments as a default.  This sticks your committed things somewhere someone might see them.
git push -u repoName master

Resolving conflicts:
Git see merge above.  Sometimes git (or the mergetool) will insert both versions in your file, then you just edit it the way you think it should go, then add the file to the staging area and commit it (then push it...)

Releases and imports

Git has a pointy clicky way of creating releases.

Get directory Module out for distribution, not for editing
svn export URL/Module ModuleReleaseName

Tagging a release (e.g. for putting on a web page.)
svn copy URL/Module URL/Module/tags/release-1.0/ [-m '1.0 release']
Note this assumes tags/ directory exists.  If it does not use 'svn mkdir'.  Note that unlike CVS there is no real tagging built into SVN, this is just a system that works by convention.

Add a new project (with existing files) to a repository.  This will create a new branch in the repository, even with multiple subdirectories.
svn import thisdir URL/newdir
Note that this will not checkout your code for you, thisdir is not put under revision control.  For a controlled version, you need to do a seperate svn checkout.

Git has a pointy, clicky way to start up new projects from existing code too.

Making changes to your own copy of the code tree

Note: you may be prompted to do many of these things if you try to commit & haven't done them already, but it's more graceful to remember to do them when you change your directory.

Add a new file to directory
svn add dir/newfile.txt
git add newfile.txt
git add '*.ending'
  for some reason wildcards require quotes

Move a file from place to place
svn mv oldpos/file.txt newpos/file.txt
Adding a directory will add all its contents.

Copy a file
svn copy oldpos/file.txt newpos/samefile.txt

Remove a file
svn rm [filename]
git rm filename or git rm '*.filestuff'
Note: this removes the local copy for you too.  If you just 'rm' a file without 'svn rm'-ing it, just 'svn rm' it explicitly before you commit.  svn status will flag when this needs to happen.

See what is changed, uncommitted etc.
svn status
Note: this is a cheap operation unrelated to commit. It needs no access to a networked repository.

Examine differences you've made since you got the file from the archive
svn diff dir/newfile.txt
Examine differences that someone has made, often done after a pull (HEAD means just the most recent one?)
git diff HEAD
git diff --staged 
This is the version that look at what you've done and put in the staging area but not pushed.
Note: the above needs no access to a networked repository.  If you want to compare to something on the repository (e.g. the current version or previous ones), see svn help diff for details.  You may actually want to use svn merge, because that takes into account the history of files whose names have changed.

When things go wrong...

First of all, with git you can always clean it up

git clean -n tells you what git clean -f will do
git clean -f will clean your file space.

Revert the file contents to the repository version because your changes suck.
svn revert dir/newfile.txt
git reset fileName
Note: In SVN his also undeletes things (assuming you used 'svn rm').  In Git, if you want things to go back to the way things were at the last commit, you have to checkout in a particular way:
git checkout -- fileToRevert

Sometimes you confuse svn & it decides things are in conflict.  This particularly happens if you change a directory while there are changes to files in it.  If you are lucky (and you've carefully looked at status & diff) either your own or the archived copy is what you really want.  (If neither are, edit your own copy until it is!)  the commands you need are:
svn resolve --accept mine-full -R [directory, e.g. . for here], if yours is right or
svn resolve --accept mine-full [filename] if just one file is getting fixed, or
svn resolve --accept theirs-full... to dump your changes and go with the archive.

Git is a bit cleaner.  If you edit a file someone else deleted and you want to keep it, just add the file, commit & push.  If you don't want to do this, just rm the file etc.

Admin Stuff (svn only)

Make a new repository (On the server)
svnadmin create /usr/local/svn-repos
This creates a Berkley DB backed subversion repository.  To get a file system based on, use the '--fs-type fsfs' flag.
This only needs to be done once, and has probably already been done for you!  (Certainly if you are using BAI)

Once your server is set up, but you have an empty repository, you want to do this:

  1. Create a folder on the server for your project.
  2. Create inside that branches, tags & trunk (three folders.)
  3. Checkout the empty trunk directory.
  4. Copy the files you want to put on the server into the new directory.
  5. Do a commit!
Why?  BDB-backed repositories will not work over NFS/AFS/Samba.  But that should not matter since you should have set it up to run on a server and be accessed by Apache.  BDB is a database, and can therefore get wedged after certain interruptions.  You can use 'svnadmin recover' to sort some things out.  Using a file system backed repository ducks all these problems.

Dump, archive and reload a repository
svnadmin dump URL/svn-repos > svn-repos-dumpfile

svnadmin hotcopy (same as dump only safer)
svn load /usr/local/new-repos < svn-repos-dumpfile

Will Lowe - 24 July 2005
Modified by Joanna Bryson 27 Jan 2006
Updated for Git by JJB 18 August 2014, and again April 2017