They should merge my pr first, so the one who will resolve the conflict is not me. I spent 3 days and nights cleaning 60 files in the projects. 60 files! Sadly, my manager merged other pr with 2 files changes from my junior first, destroying many of my changes.

You really can only do major code style refactorings when you are the one who decides when what gets merged, no one else works on the files you touch or you can just update your pull request after rebasing onto the previously merged commits.

Might also hold back your pull request until you can be reasonably sure that your request will actually be the next to be merged, to minimize friction which normally leads to refactoring anxiety on all sides.

@Oktokolo in an ideal condition, people will have awareness because I've been talking about this in every stand up in the past 3 days. But we're talking about junior intern here, can't be mad at them. And also, this is my manager first experience as a manager. So yeah.

Well if their changes only affect two of the sixty files you cleaned up, wouldn't that mean only two of the sixty files have merge conflicts?

Also I'd rather solve conflicts in my work myself than delegate the merge to a junior who likely has no context to why I changed something and would likely just click "resolve using mine".

@kwilliams I agree the second paragraph. I'm just a little tired looking into the same code for 12+ hours in the past 3 days, thus the rant.

For the first one, my changes were refactoring core components like form and its fields, and modal. The other dev just happened to use those old components with their hacky way in their changes, forcing me to rethink again about what other possibilities people may do when using the components, so I have to come with better idea while resolving the conflict.

@anotherjsdev *marks enter helper method as deprecated and refactors well implemented components into a new class*