3 ms·

You don't have to convince me that the git workflow is more powerful and affords more opportunities to recover from error - I completely agree and could go on a

by tdeck 5y ago

You don't have to convince me that the git workflow is more powerful and affords more opportunities to recover from error - I completely agree and could go on at length. However, the git workflow requires you to understand a larger number of concepts and I can personally attest that these concepts are not intuitive to new learners. For example, in Git you need to do the following, just to create a PR editing a file: 1. Checkout master 2. Pull master 3. Create a new branch off of master 4. Edit files 5. Stage edits 6. Commit 7. Push the local branch to the remote Consider the equivalent SVN workflow: 1. svn update 2. edit files 3. svn commit Notice what I didn't have to understand there. There's no branches, no division between local and remote, no index and distinction between staged and unstaged changes. All of these concepts are like an unexpected speed bump when someone is trying to learn to accomplish a task; they're trying to do one thing at a time and are forced to instead learn 5 other things until those are fully reinforced. And we haven't even gotten into the various minutia of commit-squashing etiquette, rebasing vs. merge commits, and all the other powerful abstractions that simply don't exist in SVN.

majewsky 5y ago
Not a fair comparison. 1. You're comparing a branching workflow in Git to a branchless workflow in SVN. The branchless workflow in Git eliminates step 1 and 3. 2. You can remove step 5 by doing `git commit -a` in step 6. Sure, you will have to `git add` new files, but you need to do the same in `svn add`, which your list for SVN conveniently ignores.
tharkun__ 5y ago
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.
- deleted 5y ago
  [deleted]

by tdeck 5y ago

majewsky 5y ago

Not a fair comparison. 1. You're comparing a branching workflow in Git to a branchless workflow in SVN. The branchless workflow in Git eliminates step 1 and 3. 2. You can remove step 5 by doing `git commit -a` in step 6. Sure, you will have to `git add` new files, but you need to do the same in `svn add`, which your list for SVN conveniently ignores.

tharkun__ 5y ago

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.

deleted 5y ago
[deleted]