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 http://myhost.com:/svn-repos, 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).
Doing stuff remotely in git requires the remote
argument. Here we're adding a repository, which takes two
arguments
git remote add repoName
https://github.com/repoPlace
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
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:
SVN http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-3-sect-5.4
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...)
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.
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.
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.
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:
Dump, archive and reload a repository
svnadmin dump URL/svn-repos >
svn-repos-dumpfile
