[MacPorts] WorkingWithGit modified

[Rainer Müller]

On 2016-09-23 20:38, Ryan Schmidt wrote:
>> On Sep 23, 2016, at 13:33, Clemens Lang <cal at macports.org> wrote:
>> 
>> I didn't include this because it's not how I normally work. I
>> usually only create branches for larger changes. I wouldn't be
>> opposed to include it, but I'm probably not the best person to
>> write these docs.
> 
> How can you not work that way?

I usually do the work on my local master. Only when I want to submit a
pull request, I create a new branch starting from upstream/master to
which I cherry-pick or rebase the changes I want to send in the pull
request. I do it this way because I also want to keep all the fixes in
the local copy I use.

Of course that means I need to keep rebasing my local master from
upstream/master.

> 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...

You could also push from your master to a new remote branch that did not
exist locally:

$ git push origin master:foo-fix

Rainer