I completely agree with my sibling and I want to expand a bit on it/make it more clear. You are fogetting something in your three step svn tutorial: svn add!

I completely agree with my sibling and I want to expand a bit on it/make it more clear. You are fogetting something in your three step svn tutorial: svn add! svn up <whatever> = git clone <whatever> edit files = edit files svn add <files> = git add <files> svn commit -m "commit msg" = git commit -m "commit msg" Now at this point in the simple workflow, yes you do _have_ to learn something new. You have to learn that git is always offline and you do need to actively push your commit. git push That's it. That is the _only_ difference to doing the same workflow you did with SVN with git. Now if you were using SVN with a code review workflow, it is very likely that you used something like Atlassian's Crucible and you would use branches. Let's say you just for the first time pulled/did the initial svn up to get the code and now you're gonna work on your ticket using a code review based workflow with branches. So on svn you have trunk checked out and on git you are on master. svn up <whatever> = git pull (this can be skipped in both, if you just svn upped/cloned for the first time before) svn copy trunk branches/<branchForMyTicket> = git checkout -b <branchForMyTicket> edit files, create new files etc. svn add <files> = git add <files> svn commit -m "commit msg" = git commit -a -m "commit msg" At this point the same difference comes in that you already learned in the non code review workflow. You push, big deal, already learned. git push As the sibling pointed out, since we're using the command line here for the example, adding new files is the same for both, while editing existing files can be done differently. I.e. with svn you could skip the svn add, because svn commit will commit all changes files. With git you will have to learn to just always do `git commit -a`, which you might even alias. Personally I just add it myself when needed because sometimes I do _not_ want to do that. But I can totally understand why a newbie might not want to. Now if we get away from the command line and just think in concepts that someone has to understand on top of svn while using a GUI, there really isn't much more than the "You need to push to actually publish your changes instead of commit always talking to the server right away". Most GUIs for version control present these simple workflows in _exactly_ the same manner, i.e. they do an implicit "git add" and "git commit -a" for you by default and you can select which files to actually commit by checking and unchecking checkboxes just like they allowed you to do for SVN. Now we're actually at a problematic stage. How do you merge your branch into trunk/master? Maybe your code review tool allows for it via the web UI or maybe you need to do it yourself on the command line/GUI locally and push. This is where you will find that it's a pain in the rear with SVN, including lots of conflict potential, slow operations etc. and git will just be a breeze.