How to ease in Git to someone with Git PTSD

Git is software for manipulating graphs which, instead of drawing a graph you manipulate, makes you memorize a bunch of strings of magic words that map to certain transformations given certain graphs, try to imagine the current state of the graph, try to figure out which magic words will change the state you think it's in to a different state you want, try to imagine that state, then apply the transformation without seeing the result, and then type other magic words to try to figure out if typing words transformed your graph the way you thought.

Instead of showing you a graph and letting you change it.

It's mainly used by people who would say they're writing software, not manipulating graphs.

It also doesn't tell you this is happening, so people coming from another VCS don't even know there's this whole other part they should know. They memorize commands that seem to work, it goes ok, and then one day they ruin everything. Silly, that command means something different in the context you had no idea you were in. Duh.

Their experience with Git is that it's hard to make it work and then it randomly blows up. It's not because they're stupid or lazy. They're normal people dealing with a system that from their perspective is almost cartoonishly hostile.

They might wonder why they need to care about some underlying data model just to save their work instead of what they're doing now. If you have an answer that will make them want to switch, I suggest you spend a good while showing them pictures of history trees and ways you can change them. Name things slowly: this node is a "commit," this state change is a "reset," this transformation is a "rebase." If you have a workflow on top, draw more pictures of its states and changes using those terms. Then (re)introduce Git, a tool that does what you've shown them. Then set them up with a client where they have that flow with those terms and a graph they can look at, if not manipulate directly.

Is your team in gaming? If so they will want to stick to Perforce because it handles binary files and otherwise large assets well, while git realistically only supports text files and does deltas by line of text.

I truly detest Perforce with a passion but I understand this use case.

Have you asked yourself why you want to introduce git if team has an alternative they prefer?

The answer to that question gives you what you need, bit could allow you consider whether the trade is worth it.

I have convinced gitophobes in the past, but the team was mostly on board, it was the minority that needed coaxing. That is much easier, because you can suggest trying it by working with those open to it. Generally people will cave to FOMO as others are learning together.

I would also keep in mind that there is a upper limit to how much 'selling' you can do to someone, so make sure this fight is worth it before using up the political capital needed to get them there.

Start using it yourself, raise some PRs, get them to review it, bring up diffs on the screen, just ease them into it a bit. If you're confident using it, that might help them learn to trust it again.

Large binary assets don't scale in git, even with LFS and similar solutions. At that point the pain of having code in multiple places far outweighs the pain of being on a really annoying platform like perforce. As you mentioned you'll also miss out on a lot of tooling (in perforce and unreal) and trying to replicate that functionality with git on the backend (struggling with large binary assets) will bury the project.

If you're making a game perforce is the only legitimate option. Unless you hate your developers, then try alienbrain.

Thank you for all your answers! You made very good points.

To answer some of the questions:

- Perforce isn’t going way, Git would just there for projects that will benefit from it (generic tools, less overhead setting up a repo)

- Git will need to bring value for the people using it (it’s just a tool), so something to think about

- Git graphical ui is definitely a good idea, I think it will also show better what operations are available for different contexts

- Definitely taking into account understanding Git graph and snapshot concepts is a very good start, as well having graphical visualisations

If your workplace doesn't naturally need branches, like, PRs are to be merged immediately, then it is very hard to convince your colleagues. In fact I don't think you should in that case, your team's workflow wouldn't be a good fit for Git anyway. Using spreadsheets does sound problematic, that's why locking exists in Perforce and many other centralized VCSes, but that can be fixed without introducing Git.

Have you shown them all the interesting and useful features that comprise the git ecosystem yet? Things like GitHub, maybe with its releases, wiki, issues, discussions, etc., perhaps GitLab with its ops/CI/CD features, etc.? That may be juuuuust enough to get them to overcome their "yuck" factor for just long enough to give it a real chance.

Maybe try having them use a nice GUI tool like Sourceforge. That way they won't have to learn any commands, and everything will be in a clean graphical format.

Linus’ original talk might be good

https://youtu.be/4XpnKHJAok8