> In the past, version control was something that existed but you never had to think about.
I think its the complexity of git that forces you to think about it. It's really not that user friendly, in comparison to SVN for example. Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that).
The big fallacy for me of distributed version control systems is that we all use them in a centralized way anyway (commit loses value, code does not exist at team level until pushed). It just adds another step to your work flow (code->commit->push vs. just code->commit), but the gain isn't obvious.
> Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that).
Create some aliases that make it as close as possible or as simple as possible for them. There's no need to force someone to learn the whole tool if they only need a subset.
I think the core problem is that git is designed for large fast moving code bases with several contributors. So in the process of teaching a newbie git, you can't help but teach them all complicated use cases that show up in a regular workflow. But you don't have to use git this way. You can use it like SVN where the only difference is the index (push pull)
If you're that concerned about "commit + push" vs. just "commit" then you might want to just alias "commit" to "commit + push" :).
Anyway, I think I get what you're saying wrt. less experienced users, but I found that with the proper explanation it wasn't actually that hard to get the point across. When explaining it to my coworkers, I've always tended towards focusing on the human factors. Namely things such as: "Don't you wish you could have taken that commit back?" (rebasing), "Everyone has a backup of the whole history"[1], "Hey look, if you mess up a merge, you can just say 'git reflog' and figure out where you were before everything got messed up", etc. If people can see the advantage in terms of their professional goals they are usually very willing to learn even relatively arcane tools such as git :).
Just curious how much experience to you have using git? Days, weeks, months? Have you worked on a team using it before or just by yourself? These aren't loaded questions.
I've been using it full-time for the past 2-3 years, in teams of roughly half a dozen devs. I still use SVN for my part-time open source work out of choice.
At this stage I'd say I'm very comfortable with git at the CLI (I only ever use source control tools in CLI mode), but it took me a long time to get there.
I think its the complexity of git that forces you to think about it. It's really not that user friendly, in comparison to SVN for example. Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that).
The big fallacy for me of distributed version control systems is that we all use them in a centralized way anyway (commit loses value, code does not exist at team level until pushed). It just adds another step to your work flow (code->commit->push vs. just code->commit), but the gain isn't obvious.
Another SVN fan unconvinced about git.