Re: [boost] [githelp] Moving from push to pull requests

Subject: Re: [boost] [githelp] Moving from push to pull requests
From: Michael Caisse (mcaisse-lists_at_[hidden])
Date: 2015-04-29 18:29:00

On 04/29/2015 02:42 PM, Fletcher, John P wrote:
> I have been working for some time on boost phoenix using
>
> git push origin develop
>
> to push my changes.  I have now been asked to change to use pull requests and I am not clear about how to get into the new setup.
>
> My current setup on my local computer has phoenix as a subproject in a complete boost clone with branches develop, master and several other branches.  I have not created any branches on the remote repository.
>
> What I want is to have a repository where I can work and then send pull requests for things to go to the main develop.
>
> I have two ideas about how this could be done.
>
> (1) create a separate repository outside the modular structure and put a copy of phoenix there.  I have created an empty structure called phoenix_changes both on my local computer and under my user name on github.  I am puzzled as to how to get the correct content into it.  This could come from my local copy or from the main repository.
>
> (2) Should I instead create a new branch in both my local and the remote copies of boost/phoenix?  If so how do I do that?  Can I branch from the current develop as the starting point?
>
> In either case I want to be able to send pull requests to the other developers.  It would be helpful to have an example of the commands needed.
>
> Please ask me for more information if this is not clear.
>
> Thank you for the [githelp] resource.
>
> John
>

Hi Jon -

I recommend forking the phoenix repository and working from there. It is 
easy enough to switch the phoenix submodule over to your fork/branch.

Simply use:

    git checkout -b my_new_branch_name

to work on some new issue or feature. You can then push that branch to 
the remote (github) and issue a PR to the main repositories development 
branch.

This will keep things all nice. Generally speaking, we (Joel an I) 
prefer PR's that contain all the commit history and having been smashed 
into a single commit for the feature/bug fix.

We (Ciere) run an internal set of testers for Spirit and Fusion that 
also auto-merge with development to check results. I'll add Phoenix and 
your fork to the test infrastructure if you go that route.

As a general guideline for branching methodology, I would recommend 
taking a look at this: 
<http://nvie.com/posts/a-successful-git-branching-model/>

hth -
michael

-- 
Michael Caisse
ciere consulting
ciere.com