3 ms·
My typical workflow - in private business repos, but for the same reasons specified in OP - is as follows: 1. Fork the PR branch. 2. Make the changes I want to
by kirke 4y ago
My typical workflow - in private business repos, but for the same reasons specified in OP - is as follows:
1. Fork the PR branch.
2. Make the changes I want to see upstream.
3. Create a PR into the author's branch.
4. Ask the author to review my changes.
5. When my PR is complete, finally review and merge The original PR.
This gives me the opportunity to explain my changes in commit messages, and gives the author an opportunity to push back or argue actual functionality changes I made if it's not all coding style. Now the author has license in accepting my changes. It avoids the cumbersome comment/resolve feedback loop, shows the author that their contribution is important and I'm willing to put time into making it right, and ultimately gives them credit when their PR is merged.
- travisjungroth 4y agoThe PR into their branch sounds nice, but not always necessary. If you forked the PR branch, threw a commit on top, opened and accepted a PR from your-branch to main and declined theirs, would that work? They get their commit in the history, you make the changes you want without back-and-forth. You could link from their-declined PR to your-accepted PR. I guess that's messy if it's linked to issues and the connotation of "declined PR" isn't as nice.