Skip to content

Git for Subversion users

February 6, 2016

First of all: GIT is NOT Subversion. The commands are NOT the same and the behaviour of the same commands are different. A “commit” has NOT the same meaning in the two software. Then the best is to think differently. But sometimes, we could imagine a one-to-one guide. Let’s try.

svn checkout is git clone

As you checkout the central repository in subversion, you just make a copy of the parent one in git. This is why the command is not the same. Of course, I consider you have a read/write access to the “parent” repository you try to copy. This is to keep the same behaviour than for Subversion.

svn checkout <repo> creates the local copy of the repository on your disk (you have the last version). Note sometimes you write svn checkout <repo>/trunk <repo> to only copy the development branch.

git clone <repo> will clone the repository on you local disk (you have all the history of the project including the last version but also all the branches). This is why the merge is so simple in git: all the history is available.

svn propedit svn:ignore is .gitignore

If you need to remove some files from the source system (object files, compiled results, logs…), you just have to create a .gitignore file at the root of the project. No need to use the “propset” (or “propedit”) commands, one per directory.

See git documentation for some subtle notation.

svn revert is git checkout

What a shame! Reverting to the repository last version is made through a checkout in git! What that fuck? Well, checkout is getting the last version in Subversion. Same on git. This is why there is no revert command in git. Think you can achieve a revert by forcing the checkout of the last version in subversion.

Note a “revert” command could be a good way to “match” Subversion and Git but also is quite inadmissible for git purists.

svn update is git pull origin master

To get the last version from svn, just write svn update

But, git is a multiple repository system and multiple branch system. You must give these 2 information. Then git pull origin master. Because you get the master (i.e. trunk) branch from the “origin” repository. But you could do the same with another parent repository. Well, of course, it is out of scope of this post because svn has a unique repository.

Subversion has branches but managed as separate projects (usually using “tags”, “branches” and “trunk” directories). git is more like the CVS ancestor: branches are part of the tool.

svn move is mv

There is no “move” command to rename a file locally (and absolutely not possibility to rename a file remotely). You simple move your file with the “mv” command on Unix or rename it through the Explorer under Windows (or the Finder for Mac users).

Because there is no tracking like in Subversion, git has no need for marking files changed. It will see it. Note that that for copying or deleting a file, just do the same: use the operating system commands.

svn status is git status

Well, not so surprising. You are checking the “local” status of your files. Note git has a slightly different notation than Subversion but you can understand easily what has changed and what added.

The main difference is about the management of changes. In Subversion, you can commit changes made on files. You just have to add manually new files. git is just about “changes” including new files. But there are good news: renaming a file in git is simply renaming the file. git will understand a file has been renamed and will do the job.

svn commit is git add + commit + push

Because your local directory is a git repository (yes, it is), commit has the sense of “commit” on your repository. Then to send back to the repository (in the sense of Subversion), you have to push.

Because there is no renaming or moving and because your work is a complete repository and history, you have to first add the files and push back all of them to the origin master.

git add --all
git commit -m "<my comments about changes>"
git push origin master

An important point

Never forget that git will NEVER store an empty directory. If you need an empty directory to be saved in the git repository, you need to add a fake file inside (usually a README.md because it is a good practice).

Conclusion

This post is NOT to force you to go to a git repository but to make the adoption simple. I don’t want to change your source control from subversion to git. Personally, I use both. Sometimes subversion is better than git depending of your organization, your management and so on. And this post is the very minimal of the minimal. If you don’t understand the philosophy behind git, you will just continue to suppose these tools are the same. But not: they are really different.

Advertisements

From → Computers

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: