[jackhab]

As someone who also switched from SVN to git many years ago I understand this "is this really worth it" thing. It came to my mind many times in the beginning when I said to myself "do we really need a distributed SCM if everyone are always working against the same server anyways".

But putting git's technical advantages aside, for me, one of its most important values is that it has become de facto industry standard. It's like IP/TCP/UDP protocols which everyone understands be it a tiny IoT device or 10K-core cluster.

With all this enormous amount of programming languages, frameworks and tools we have in the industry it's so nice we've managed to agree, at least, upon one very important element of our work.

[sharken]

As someone about to move from Mercurial to Git i absolutely agree, even though Git has its quirks, you can always find some help for a specific problem.

Refactoring was mentioned and i think a good Git branching strategy is vital in that regard. If you have multiple branches and merge between them, then refactoring tends to not happen due to developers not wanting to have difficult merges.

The obvious choice is Trunk-based Development, but it's almost a bigger transition than moving to Git.

[tharkun__]

This just reminded me of when I last didn't use git. It's been so long and really worth it.

It must have been around 2010. I was with a client and they were using SVN in the projects I worked on (and some other obscure - to me - versioning system that they literally had "build masters" for that were the only ones allowed to merge and solve conflicts for the entire company, even though they never ever worked on the code itself). I had been using git before that already for some time and couldn't fathom why anyone would not use that.

They didn't believe my raving about git. Almost needless to say that they were always complaining about merge conflicts, about not being able to do X or Y or Z or that things were slow or error prone (like branches) or that they messed up a conflict resolution upon merging and needed help because they forgot to copy their entire source tree to a different location before doing so etc.

I had zero problems like that because I simply used `git-svn`.

Why is this significant? Because I hear so many people complain about how hard a "trunk based development workflow with rebases" is. Well guess what, that's basically what git-svn is. Nobody in their right mind used SVN any other way but with a single trunk, because branches sucked so much (except for release branches and yes, if you had to bring in something from `trunk` it wasn't just a simply cherry-pick). And because of SVN being what SVN was, before committing to SVN git-svn would simply rebase my work on the current SVN trunk automagically and the issue the commit to SVN. Any conflicts could be solved locally on git and because I had to commit anyway before it could do this rebase. In those two years I had literally one conflict and it was easy to solve, while everyone around me kept having problems. Heck even the feature branches were easy for me, because it's just a different 'trunk' to rebase onto and I actually _could_ cherry pick for them :)

I learned the one lesson I think everyone just has to keep in mind with git: Commit before you do anything else and you won't ever loose work (save bugs in git or you doing stupid low level stuff). You can always just reset back to your commit and redo the botched attempt to resolve conflicts and this time around it should be easier with the knowledge you gained in the first try. That's also why I never use git-stash to move stuff around. There's no commit to go back to if you accidentally did a `git stash pop` instead of `git stash apply`. Heck there was even this one guy who got some rebasing and squashing so wrong that he force pushed a completely different branch onto his branch. "Lost" all of his week's work. He was so so happy when he learned how to find the commit hash for the 'lost work' and that all branches are in git are labels for those commit hashes and we magically brought it all back by reattaching this label to the right commit and force pushing again.