> Therefore I suggested SubVersion
This author has much to teach us about evil after all
This author has much to teach us about evil after all
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!
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.
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.
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.
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"
git push
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"
git push
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.
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.
Hey, that was me-- wasn't that all of us, after we learned our first programming language?