4 ms·

I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it

I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of your time for no real reason. I wonder what the justification is.

jjmarr 1y ago
> I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. Correct. It makes sense to me because it leaves a linear history of git commits in response to comments on a PR which makes code review easier. We squash and rebase at the end. > Just a waste of your time for no real reason. I wonder what the justification is. We used to be on Gerrit, which I found better for code review as I could stack a bunch of minute changes together. I probably had 50-100% more productivity on Gerrit before my team made the switch. Unfortunately, the industry standard is GitHub PRs. My team wasted a ton of time onboarding people to Gerrit and even after onboarding, less than 5% of people understood stacked changes enough to use them effectively. Since force pushing/rebasing messes up GitHub PRs it was banned. If you have suggestions for alternative code review workflows on GitHub I'm happy to hear them, but ideally they could be incremental.
steveklabnik 1y ago
Github's behavior when branches are force pushed makes some places ban it, that might be your parent's situation.