3 ms·

I’m in a „merge conflicts are a waste” camp. I don’t need multiple parallel versions of software (unless it’s a library following semver). I need to hear a sing

• JimmieMcnulty 4y ago
  Coworkers. Also you’re pushing code into this main branch from… where? Another main branch. That’s literally how git works, you’re just removing any oversight and collaboration opportunities by insisting on calling this branch you’ve created locally “main” as well. Code reviews are awesome, and not doing them is a fantastic way to ruin your team’s ability to support work they didn’t themselves write.
  • gocartStatue 4y ago
    Does it have to be post-coding, pre-merge code review? The difference lies in size of the diff and the manner of introducing changes. Other developers have your changes instantly. This is core of the discipline called „continuous integration”. I’ve been in multiple teams doing mandatory, pre-merge, double code reviews and getting crappy results. The longer someone kept their precious feature branch isolated, the worse. And keeping branches „up to date” only solves a small part of the problem with long lived branches.
    • JimmieMcnulty 4y ago
      Yeah, but nobody here is suggesting long lived branches, nothing about a feature branch requires that it exist for a “long time”. Your local “main” branch that you’re developing a feature against is a “feature branch” you just aren’t calling it that. But even if it did, regularly remerging main back into it (or rebasing) does solve like 90% of the issues being described here, and further comes with a whole host of other benefits.