The Stack Overflow podcast is back! Listen to an interview with our new CEO.
4 added 215 characters in body
source | link

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.

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:

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.

Once you have most 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:

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.

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:

3 added 19 characters in body
source | link

Your developers are likely overwhelmed by the sheer complexity of this standard. (II don't personally think it has any benefit, and the article above makes the same argument. But that's a separate discussion.) It's Objectively, though, it's a pretty heavy standard with a lot of manual management, and it requires a lot of cognitive effort.

  • 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

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.) It's a pretty heavy standard with a lot of manual management, and it requires a lot of cognitive effort.

  • 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

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.

  • 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
2 added 88 characters in body
source | link

Look at them and Gitflow, weigh them against your use cases, and pick one that fits.

Look at them and Gitflow, weigh them against your use cases, and pick one that fits.

1
source | link