690
Merge conflicts (feddit.nl)
submitted 1 year ago by to c/programmer_humor@programming.dev
59 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 11 points 1 year ago (2 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 13 points 1 year ago (1 child)

    What are the maverick git workflows?

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 year ago*

    Gitflow is the usual branching strategy. It's not dialed up to 11, it only specifies precisely what to merge to where and from where.

    The real mavericky thing is when someone uses cherrypicking in combination with squash merges thus breaking branch compatibility.

    I have been the git specialist in the last few teams, and thus I'm the one who has to clean that up every time. Not because it's hard, but because nobody can be bothered to actually learn git.

    Edit: The other thing is to use rebases instead of merges. Yes, they make for a much nicer git history, but they also tend to break everything in the process when the rebase is sufficiently large.

  • permalink
  • fedilink
  • source
  • parent