Re: Github Fork And Contibutions via Pull Request
Michael Hast <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.wonder-disc |
|---|---|
| Message-ID | <[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? 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