Feature branching as standardized workflow about covid19-review HOT 4 CLOSED

Rebase always makes me nervous for the reasons described here: https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing

I'm happy to hear from others about their experiences!

from covid19-review.

I haven't used rebasing much in my projects because I've seen it cause confusion. I'm open to anything though. This project seems to be moving even faster with more simultaneously contributions than deep review.

Maybe @mprobson could describe the benefits he's seen on large-scale collaborations?

from covid19-review.

I'm one of the (many) core developers of the Charm++ Parallel Programming System (linked in case you want to take a quick look at the project). It's admittedly a very different use case (software v paper; slow v fast) but we develop our features on separate branches before merging it into the main repo via a PR that gets rebased. The big pro of rebasing is it presents a clean history of linear commits, which is good for debugging, performance regresssion analysis, etc but maybe not applicable here. I definitely understand the hesitancy (merges are basically always safe and rebases can get hairy!) since the PR's (and branches they are generated from) are 'public'. However, I don't think anyone is (or should be) basing their commits off of them and that branch will continue to exist (unless deleted by the user but it can always be restored). As a side note, I'm pretty sure this is the same model GitHub uses underneath for their web interface since it generates a branch, e.g. username-patch-01, for the new PRs. I also know there are cases where rebases aren't possible to do automatically (due to conflicts) and in those cases I think merging the changes in makes the most sense unless someone wants to fix it on the command line, which I'm happy to do. I guess all of this is to say that rebasing should be an aim here when people contribute separate changes and can automatically rebase without complex intervention but not a requirement (like it is in Charm) as to not slow us down. That's just my two cents, but y'all have much more experience steering this project at this point so I'm happy to just contribute where I can.

from covid19-review.

Thanks for the details @mprobson. I'm fairly indifferent about merge commits versus rebase for this project. Either way we'll be using branches and pull requests for the main workflow.

For deep review we used squash merges for pull requests, but I recommend not using those here. Now that GitHub supports reviewer suggestions, having a pull request reviewer get some attribution for a suggestion that is accepted is nice. I'm not sure what happens to co-authored commits when they are squashed. I'd guess the co-authorship is lost.

from covid19-review.