> On Jan 9, 2018, at 8:07 PM, Justin Mclean <[email protected]> wrote: > ... > With the current set up we can do both those things i.e. merge PRs and use > issue if we want.
We can get the merge button on the PR's page to show up for all our committers? If so, please make it so! :-) (I already know how to merge w/o it but it’s more of a pain) > I’m all for forks for larger changes - one issue is that longed lived forks / > PR can run into merge issues. It generally why git flow style workflow is now > seen as a poor idea. If I said “gitflow” when I meant the simple “GitHub flow” sorry about the confusion. Yup, there's lots of info on the evils of gitflow. I wasn’t able to locate rants on the evils of GitHub flow. > ... > But that being said I don’t see any reason for now using them. It does tend > towards a more RTC (review then commit) process than a CTR (commit then > review) process. Both are used at Apache. GitHub PRs trivially enable RTC but it only becomes RTC when a committer chooses to ask for a R before they do their C (merge). In Edgent, committers always used PRs and commit-then-review (except when they wanted feedback first - e.g., for potentially controversial or complex changes or simply because they weren’t confident the change was the right way to address the issue). But as you said, to each his own :-) I just wanted to be sure we folks weren’t overlooking the virtues of the simple GitHub flow. — Dale
