Re: Github Fork And Contibutions via Pull Request

Git remotes, I see. Now I understand git remotes. That makes perfect sense.

Thanks Maik and Pascal.

Michael

On 10/18/2012 12:56 PM, Maik Musall wrote:
> Hi Michael,
>
> Am 18.10.2012 um 21:40 schrieb Michael Hast <[email protected]>:
>
>> Thank you very much for the explanation. That makes all sense now.
>>
>> One more question. Do you checkout your Wonder fork from github when you do a production release directly e.g. [email protected]:<your name>/wonder.git, or did you clone your fork to a server in your company?
>
> Currently we have one person that maintains the connection to the projectwonder official upstream, which is me. I have a local repo with 2 remotes: "upstream" is the github projectwonder/wonder repo, and "origin" is another repo on our local company git server (Atlassian Stash 1.3). origin is what we build our projects against. It carries both master and integration branches.
>
> When new changes appear upstream, I will first examine them, and then pull them into my local repo. If I need to have a closer look, I do that. When I'm convinced there's nothing that could break stuff here, I push those changes to origin, which makes them available to the rest of the company. (Others could always directly pull from upstream, their choice, but it makes sense to have only one person play the gatekeeper.) I also push those changes back to my github fork regularly, but that isn't actually so important as I only need that fork when I have pending pull requests.
>
> For my main project, I use Jenkins to do the builds, and Jenkins does checkouts from origin. This offers both maximum control over what code goes into the release, and maximum performance getting the code. It's much faster than connecting to github all the time.
>
> Changes on wonder itself go into a separate branch which is pushed to origin. Jenkins build jobs are then adapted to use that branch until the corresponding pull request is accepted and appears in upstream integration.
>
> Others may do all this differently, though :)
>
> Maik
>
>> What if github is not available or accessible, you still can access your company server and checkout your fork from there? Just wondering.
>>
>> Michael
>>
>> On 10/18/2012 11:16 AM, Maik Musall wrote:
>>> Hi Michael,
>>>
>>> Am 18.10.2012 um 19:20 schrieb Michael Hast <[email protected]>:
>>>
>>>> Thanks Maik:
>>>>
>>>> Just to clarify: Here is what normally do. After creating the fork and doing a clone, I have the master branch checked out. Now we come across a bug or need to do a feature enhancement.
>>>>
>>>> 1. Code the change, commit the change and push it to our fork on github (master branch).
>>>
>>> Well. master is always weeks to months behind. You should checkout integration first and see if the given bug still occurs there. You should also review outstanding pull requests or issues on github to see if someone else already addressed this.
>>>
>>> If not, next choice is what wonder branch to base the changes on. Most people here who contribute to the project work with integration anyway, and for those it's a no-brainer. If you base your production stuff on master and need those changes there before they would make their way through integration and rc into the next master release, you could be better off to base them on master for that purpose, using a new branch based on the latest master release.
>>>
>>> You could then create a separate new branch from integration that you'll use to merge your changes in there periodically. That way you can always check compatibility against the newest wonder developments, and you would use that branch to make your pull request, because that needs to be based on integration for easier merge by the core committers. And you would need to be able to test your changes against newest integration before even making the pull request.
>>>
>>> Maik
>>>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct