[MacPorts] WorkingWithGit modified

[Lawrence Velázquez]

> On Sep 23, 2016, at 2:38 PM, Ryan Schmidt <ryandesign at 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