4 ms·

That, plus a few sentences later: "Frankly, at the time, I did not understand much about branching strategies. It all seemed too complicated to me. I had hard t

by cactus2093 5y ago

That, plus a few sentences later: "Frankly, at the time, I did not understand much about branching strategies. It all seemed too complicated to me. I had hard times trying to fit the workflow in my head." I have no idea whose blog I'm reading here, but he doesn't exactly sound like someone whose opinion on version control and branching strategies should count for very much. Coming next week - a post about why X is the best programming language, from someone who hasn't bothered to learn any other programming languages!

tdeck 5y ago
Having worked with novice developers very recently I agree with the author here. The workflow of SVN (and similar) is much easier to understand and explain to folks who haven't used version control before. People tend to easily lose the thread when there's a local version of main/master, a remote version, and a local and remote version of their own branches, and they have to perform a whole host of commands to keep everything the way it should be. I often find even a simple workflow involves teaching multiple Git concepts that get in the way.
- tharkun__ 5y ago
  I don't get how that's so complicated to be honest and your host of commands is literally 3. SVN had 2, big deal, especially when of those 2, commit can destroy all your work easily n SVN, while a very simple rule of git will allow you to never loose any work: Before you do "anything else", commit! By simple workflow I mean the simple workflow that mimmicks what you would've done with SVN (or CVS for that matter). Remember the holy wars of SVN over CVS? "What do you mean the entire repo has one version number instead of each file? Are you insane!" :) What git allows for are different workflows and some of them are probably harder to understand than others but very workable ones are really easy too and don't require a host of commands or a deep understanding as long as simple rules are followed. All of my last few new hires (juniors) can work without problems with our simple git workflow. FWIW, we use short lived branches per ticket that get PR'd into master. Master is always green and deployable (hourly). The branch is yours to do with whatever you want until you want to actually merge to master, at which point you have to squash and rebase from master. Some guys got bitten by not following the simple rules of "do one thing at a time" and "commit first". Luckily git refuses many actions if you have a dirty tree but people can get confused because they never read error messages. "Yes, yes I pulled and then ... and now it doesn't do what it's supposed to". Do one thing at a time works for most things in life and software development and rebasing from master while also squashing at the same time is just insane. Just do one of them first. Usually I find squashing first is easier as otherwise you might have to solve conflicts on intermediary commits that you wouldn't have in the first place with your squashed commit.
  - 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.
- cactus2093 5y ago
  I've worked with many new developers, some self-taught on the side, some of them directly out of bootcamps and only been programming for a few months. Sure, they don't all know the ins and outs of the git data model and what every command does. But I've never seen anyone that couldn't understand git pull, git commit, and git push. If the org uses a branching model, you can teach them git checkout -b, git checkout <branch_name>, and git merge origin/master to switch between branches in 5 minutes. They might get themselves into trouble eventually, but then someone more experienced can come by with git reflog and help them recover their work. Set up their github project to use squash commits only so each PR is one commit and master is always linear and they're off to the races. Despite some command naming quirks, the simple stuff is pretty simple in git and the more advanced stuff is there when you want to learn it. I really don't buy that there is any good reason to choose SVN these days, regardless of how junior the team might be.
CRConrad 5y ago
> Coming next week - a post about why X is the best programming language, from someone who hasn't bothered to learn any other programming languages! Hey, that was me-- wasn't that all of us, after we learned our first programming language?

tdeck 5y ago

Having worked with novice developers very recently I agree with the author here. The workflow of SVN (and similar) is much easier to understand and explain to folks who haven't used version control before. People tend to easily lose the thread when there's a local version of main/master, a remote version, and a local and remote version of their own branches, and they have to perform a whole host of commands to keep everything the way it should be. I often find even a simple workflow involves teaching multiple Git concepts that get in the way.

tharkun__ 5y ago
I don't get how that's so complicated to be honest and your host of commands is literally 3. SVN had 2, big deal, especially when of those 2, commit can destroy all your work easily n SVN, while a very simple rule of git will allow you to never loose any work: Before you do "anything else", commit! By simple workflow I mean the simple workflow that mimmicks what you would've done with SVN (or CVS for that matter). Remember the holy wars of SVN over CVS? "What do you mean the entire repo has one version number instead of each file? Are you insane!" :) What git allows for are different workflows and some of them are probably harder to understand than others but very workable ones are really easy too and don't require a host of commands or a deep understanding as long as simple rules are followed. All of my last few new hires (juniors) can work without problems with our simple git workflow. FWIW, we use short lived branches per ticket that get PR'd into master. Master is always green and deployable (hourly). The branch is yours to do with whatever you want until you want to actually merge to master, at which point you have to squash and rebase from master. Some guys got bitten by not following the simple rules of "do one thing at a time" and "commit first". Luckily git refuses many actions if you have a dirty tree but people can get confused because they never read error messages. "Yes, yes I pulled and then ... and now it doesn't do what it's supposed to". Do one thing at a time works for most things in life and software development and rebasing from master while also squashing at the same time is just insane. Just do one of them first. Usually I find squashing first is easier as otherwise you might have to solve conflicts on intermediary commits that you wouldn't have in the first place with your squashed commit.
- 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.
cactus2093 5y ago
I've worked with many new developers, some self-taught on the side, some of them directly out of bootcamps and only been programming for a few months. Sure, they don't all know the ins and outs of the git data model and what every command does. But I've never seen anyone that couldn't understand git pull, git commit, and git push. If the org uses a branching model, you can teach them git checkout -b, git checkout <branch_name>, and git merge origin/master to switch between branches in 5 minutes. They might get themselves into trouble eventually, but then someone more experienced can come by with git reflog and help them recover their work. Set up their github project to use squash commits only so each PR is one commit and master is always linear and they're off to the races. Despite some command naming quirks, the simple stuff is pretty simple in git and the more advanced stuff is there when you want to learn it. I really don't buy that there is any good reason to choose SVN these days, regardless of how junior the team might be.

CRConrad 5y ago

> Coming next week - a post about why X is the best programming language, from someone who hasn't bothered to learn any other programming languages! Hey, that was me-- wasn't that all of us, after we learned our first programming language?