3 ms·
> Split your merge request into smaller, independent merge requests IMHO - This depends on the change. It is not simple if you are working on a refactoring tha
by the_arun 5y ago
> Split your merge request into smaller, independent merge requests
IMHO - This depends on the change. It is not simple if you are working on a refactoring that touches 100s of files.
Review is needed where more developers share the concerns:
Eg.
1. DB Schema changes
2. API Schema changes
3. Changes related to backward compatibility with Biz Logic
4. End to end Design of the change
Open to learn if anyone thinks otherwise.
- eyelidlessness 5y agoThese are the most important cases to commit incrementally, even if they’re automated or tooling-assisted in some way. That way you can review the substantive changes separately from the chores.
- nerdponx 5y agoOne thing I have found beneficial is for the developer making a big change like this to actually write a "human readable" explanation of the changes. Something the reviewer can read and use to understand the context for and purpose of the changes.
- Pxtl 5y agoRefactoring is the most important case where it must bee refactoring-only and no real changes.
- eyelidlessness 5y agoIs “bee” here riffing “iff”? Because I might steal that.
- Pxtl 5y agoNo, just a typo.