> On Sep 23, 2016, at 2:38 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > If you commit directly to master of your fork, then submit a pull > request, you can't do anything else on master until your pull request > is accepted. If you make further changes on master they will be > included in the pull request, which you wouldn't want if they are > unrelated changes. And once your pull request is merged, then what? > GitHub will give you a nice "you can now delete your master branch > because it's been merged" button...
The workflow we recommend should mesh with GitHub's website. Contributors shouldn't feel like they're fighting the pull request UI or doing something unorthodox. It sounds like topic/feature branches are the most natural way to work with pull requests, so that is what we should recommend. On a related note, the workflow should reduce openings for error. As Fred noted, working in a topic branch ensures that updating master results in a fast-forward merge and shifts conflict resolution to the point of merging/rebasing the topic branch, which most users might find less… alarming. (Advanced Git users will ignore our recommendations and do whatever they want anyway, which is fine.) vq _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev