1y ago

always try and get my PR merged before anyone else

18 comments

Merge conflict in general is fine
What's really bad is if someone drastically changed the implementation of something which you've also changed and if you completely need to rework it…
- What's really bad is if someone drastically changed the implementation of something which you've also changed
  That's not a merge conflict, that's a management conflict.
  
  Oh, I mean I was talking about Open Source projects. If you just work privately and don't say at some kind of central place (like a Discord or Matrix server) on what you're working on, then it can easily happen that just two people do that at the same time without knowing of each other.

Merge early and merge often.
And ideally, each commit represents a working state of your software. If your team is disciplined enough with that, you can save yourself the feature branches and merges.
- Are you expecting a developer to test everything every time they commit? Thoroughly testing even a small application or feature subset will take up quite a bit of time. You also want devs to commit often, so it is easy to roll back an approach that didn't pan out, or just to go back and figure out what change caused something to stop working. If you end up committing only a few times per week because everything needs to be thoroughly tested, I'm not convinced it is a good approach.
  
  No, they should not need to test everything, but this strongly depends on your code quality and project setup.
  There's definitely other paths to the goal, but generally for larger projects, I recommend:
  Good isolation between components. A change in one component should not have unforeseeable effects in other components.
  Automatic unit tests for each component, so devs can test their changes in isolation.
  A statically typed, compiled language, so that compiling does a basic integration check between components.
  Strong ties between components, where it makes sense. For example, ideally, the communication model between backend and frontend is in a shared module/library, so that if someone does change the model, it leads to compile errors on both sides.
  Automatic integration tests + a CI/CD pipeline, which tests the rest of the application after each push. This will let you know as early as possible, if you did push a broken commit.
  A multi-project build with all parts of your application in a monolithic repo, so that all components get continuously compiled + integrated with their most recent changes.
  This rigidity does have challenges of its own.
  For example, a change in the backend might force a change in the communication model and therefore in the frontend, too. And if you're exclusively backend, you might struggle with updating the frontend accordingly.
  Then you'll need to push onto a separate branch and look at it with your frontend colleague later. But hopefully, you get that arranged within a day or two, so the merge conflicts should still be quite tame.
  And obviously, this rigidity has tons of advantages. Not needing to wonder whether frontend and backend, or any other interface, is compatible right now, is just insanely good.

git rebase -x theirs origin/main and then look at the lines your changing to see what needs to be retouched
- I’m more of a git push origin/main —force guy myself
  
  Reject "main" branch, embrace master branch