your PR is too big
its not really checkable nor approvable - noone can hot approval button and consciously share responsiblilty for merging this to master. So go back drawing board, split it up! Respect your git history amd your coworkers time )
I do it all the time - an idea, or a feature first lands in a prototype branch (even TDDed one!) and the I split it to smaller branches that are easy for my collegues to comprehend and check.
PS safe (automated) refactoring, like migrating to new codestyle can be as big as needed, and doesnt really require checking. But as you mentioned 23 commit and “context” attached to them - I take it as it was not the case )
PPS I have to admit, squashing works well with short-lived feature branches, CI/CD and instant releases. If you, for any reason, have different lifecycle (I bet its organisations’ processes/structure) squashing might seem like unnecessary or strange idea
Thanks for the input Andrew - I definitely had the feeling that PR was getting too big! The way I went about it was very TDD - authoring a test for the bug I was fixing, then getting it to pass, and then repeating that test + pass cycle until I had covered all of the corner cases. How would you recommend splitting that up? I wouldn't really feel comfortable merging a fix into master that I didn't feel was complete, so I'm curious what strategies you would have in mind!
I’m not sure if you will like this answer =) IMO if tests came out so big, component was also quite big, so maybe its possible to extact/isolate it and cover a small coherent part. Tests would likely to become smaller, and integration tests could be added in a separate branch.
PS yes it means refactoring before fixing a bug, and actually this is what I do too )
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
your PR is too big
its not really checkable nor approvable - noone can hot approval button and consciously share responsiblilty for merging this to master. So go back drawing board, split it up! Respect your git history amd your coworkers time )
I do it all the time - an idea, or a feature first lands in a prototype branch (even TDDed one!) and the I split it to smaller branches that are easy for my collegues to comprehend and check.
PS safe (automated) refactoring, like migrating to new codestyle can be as big as needed, and doesnt really require checking. But as you mentioned 23 commit and “context” attached to them - I take it as it was not the case )
PPS I have to admit, squashing works well with short-lived feature branches, CI/CD and instant releases. If you, for any reason, have different lifecycle (I bet its organisations’ processes/structure) squashing might seem like unnecessary or strange idea
Thanks for the input Andrew - I definitely had the feeling that PR was getting too big! The way I went about it was very TDD - authoring a test for the bug I was fixing, then getting it to pass, and then repeating that test + pass cycle until I had covered all of the corner cases. How would you recommend splitting that up? I wouldn't really feel comfortable merging a fix into master that I didn't feel was complete, so I'm curious what strategies you would have in mind!
I’m not sure if you will like this answer =) IMO if tests came out so big, component was also quite big, so maybe its possible to extact/isolate it and cover a small coherent part. Tests would likely to become smaller, and integration tests could be added in a separate branch.
PS yes it means refactoring before fixing a bug, and actually this is what I do too )