Git is a major rethink if you learned how to do source control on SVN. Many of the habits you developed there (which may have well been best practice for SVN) will misguide you when using git. This is primarily because git's branching model is so fundamentally different. It doesn't leverage *folders* for branches, and it's also possible to make it non-linear because it was designed to support the distributed use cases better. It takes some time to unlearn SVN habits and understand how you're *supposed* to use git. # Start simple You say you've chosen Gitflow as your standard for branch management. This strikes me as your biggest mistake. To quote [Gitflow Considered Harmful](http://endoflineblog.com/gitflow-considered-harmful): > All of these branches that are used force GitFlow to have an > elaborate set of complicated rules that describe how they interact. > These rules, coupled with the intangible history, make everyday usage > of GitFlow very hard for developers. > > Can you guess what happens whenever you set up a complex web of rules > like that? That's right - people make mistakes and break them by > accident. In the case of GitFlow, this happens all the time. Here is a > short, by no means exhaustive list of the most common blunders I've > observed. These are repeated constantly, sometimes every day, often > over and over again by the same developers - who are, in most cases, > very competent in other software areas. Your developers are likely overwhelmed by the sheer complexity of this standard. I don't personally think it has any benefit, and the article above makes the same argument. But that's a separate discussion. Objectively, though, it's a pretty heavy standard with a lot of manual management, and it requires a lot of cognitive effort. You need to start simpler. Don't worry about a branching standard right now. Focus on *getting them used to using git* first. You only really need a few operations to get started: * clone * pull * branch * merge * commit * push * knowledge about how `.gitignore` works * maybe tag Yes, your history might look at little messy at first. This is okay. Don't worry about it right now. Just get them *using git*. # Gradually increase knowledge From here, you can gradually educate them on slightly more advanced usage. * Teach them the epic stash command * Teach them how use reset when they want to throw away the local commit they just made * Teach them how to amend * Teach them how to rebase to avoid unnecessary merge commits * Teach them how to interactively rebase to organize their commits before they push * Teach them how they can checkout from any hash, tag, or branch Especially make sure you take advantage of opportunities to show them cleaner ways of getting their code into the repository, but also teach this stuff in training activities and what have you. Having a guru or two that people can approach when they're not sure what to do will help a lot, too. If you have something like Slack, create a dedicated channel and encourage people to ask and answer questions there. # *Then* choose a branching standard Once you have most of the company competent in using git at all, *then* you can look at branching standards. Choosing one up front is a really bad idea for multiple reasons: * They don't have enough knowledge of the tool to tell you whether the standard works well for the company's use cases * They won't be able to offer alternative standards * They have to learn both the tool and the standard at the same time * Some will assume the standard you pick is the only way they can use git * They won't be able to identify rare edge cases where the standard is doing more harm than good You shouldn't be handing down a Git workflow from the mountain. Your team needs to have input on it and be able to give you feedback about whether it's going well or not. They can't do this if they don't even understand the fundamentals yet. You don't need *every* single developer to have deep knowledge like this, but you definitely need several who really get it. And you need the vast majority to be at least competent in git so they know enough to stay somewhat on the rails. Here are a couple alternatives to Gitflow your team can consider: * [OneFlow](http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow) * [Feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) * [Centralized workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow) Look at them and Gitflow, weigh them against your use cases, and pick one that fits.