What are the maverick git workflows? When I had a web developer job, it all seemed pretty straightforward and I can’t imagine doing it some other way and it being a good idea.
Okay, but be advised: this is how we start fights. Depending on where you’re coming from, everyone else is doing it wrong. Keep that in mind. That said, I want to have a discussion with you and others, if possible.
If we assume that a GitHub PR, or GitLab MR, workflow is “typical”, then the oddballs I know of are:
Geritt - It endorses a unit of review/work that is always exactly one commit. I have some strong opinions about why this is a thing, why it’s not great, why you shouldn’t if you’re not Google, and how Google got here, but that’s a whole other discussion. It’s a super-polarizing approach to Git in general.
Gitflow - takes the usual branching strategy of MR/PR work and dials it up to 11. This too is polarizing, as the added complexity can be a bit much for some folks.
IMO, a lot of the trouble we run into with Git is largely due to training problems. Also, one has to architect the git space to fit the company, culture, and engineering needs at hand. This means planning out what repositories you need, how you’re going to solve CI/CD, what bar for code review is needed, how to achieve release stability, and how to keep the rate of change steady and predictable. To do any of that, everyone needs to learn a bevy of git commands to do this well, and not enough companies bother to teach them.
What are the maverick git workflows? When I had a web developer job, it all seemed pretty straightforward and I can’t imagine doing it some other way and it being a good idea.
Okay, but be advised: this is how we start fights. Depending on where you’re coming from, everyone else is doing it wrong. Keep that in mind. That said, I want to have a discussion with you and others, if possible.
If we assume that a GitHub PR, or GitLab MR, workflow is “typical”, then the oddballs I know of are:
IMO, a lot of the trouble we run into with Git is largely due to training problems. Also, one has to architect the git space to fit the company, culture, and engineering needs at hand. This means planning out what repositories you need, how you’re going to solve CI/CD, what bar for code review is needed, how to achieve release stability, and how to keep the rate of change steady and predictable. To do any of that, everyone needs to learn a bevy of git commands to do this well, and not enough companies bother to teach them.