I've noticed this at work. There are some developers that just don't seem to want to take the time to figure out what git is doing, and so get very confused and throw up their hands right away.
I'm not sure what the right solution is. We switched to git to try to get out of the hell that was svn merging between long-lived branches. It's seemed to have helped, but in exchange for much day-to-day frustration for a lot of devs.
I don't like using SVN for enterprise because of it's broken merging/branching. It's hard to implement a proper feature branching strategy without dealing with conflicts.
I find the "too easy to break the repo" argument really quite odd. While I understand why users think this is true, it's actually very far from the case. The git repo is very stable, has built in error checking, and is extremely stubborn about removing data. The working copy on the other hand, is very easy to jack up if you're not sure what your commands are doing.
The best thing you can teach someone just learning git is to commit very frequently. If your files are committed, you can undo most any error. But if you've got a dirty working copy, you could lose it if you do something drastic. As an added bonus, this also teaches the user to branch often, and eventually they'll find the majick of `git rebase --interactive`
I assume you mean `git push origin :featureBranch`? Deletes a branch pointer on a remote repo. No data is lost, it just takes a little effort to dig it back up if you don't know what SHA the branch was at.
Yeah, that's the one I meant, I still find it extremely counterintuitive, one character is the difference between push my current changes to origin and delete the branch on the remote side.
7 comments
[ 3.6 ms ] story [ 27.1 ms ] threadI'm not sure what the right solution is. We switched to git to try to get out of the hell that was svn merging between long-lived branches. It's seemed to have helped, but in exchange for much day-to-day frustration for a lot of devs.
While I personally use and like git, it's just too low level for general use. Too easy to mess up the repository.
Git is a very good basis for version control. It just needs a better front end for slightly less sophisticated users.
The best thing you can teach someone just learning git is to commit very frequently. If your files are committed, you can undo most any error. But if you've got a dirty working copy, you could lose it if you do something drastic. As an added bonus, this also teaches the user to branch often, and eventually they'll find the majick of `git rebase --interactive`
git branch origin :featureBranch?
disclaimer; don't experiment in a data critical repo