Apache cordova has already a nice step by step manual for pull request on github -> http://wiki.apache.org/cordova/CommitterWorkflow.
It's not just a click on the accept pull request on github. :( Cyrill On Fri, Mar 22, 2013 at 10:11 PM, Frédéric THOMAS <webdoubl...@hotmail.com> wrote: > I don't know very well the GitHub workflow as even though I worked on public > and privates ones but: > > >> A non-committer forks the GitHub repo > > > Can't he clone directly the GitHub Repo ? > > >> which branch(es) will non-committers have to target? > > > I would say, its own branch, I mean a branch with the name of the relative > issues in the JIRA > > Thanks, > -Fred > > -----Message d'origine----- From: RIAstar > Sent: Friday, March 22, 2013 1:02 PM > > To: dev@flex.apache.org > Subject: Re: [Git/Wiki] please review the proposed workflow and comment > >> How would that work, if you don't mind explaining? > > On the non-comitter's side: > - A non-committer forks the GitHub repo > - He now has a complete copy of this repo in his own account > - He clones his own fork to work on it locally > - He works locally, makes some commits, pushes to his fork, makes some > more commits, pushes again, ... until he thinks his feature/bug fix/... > is ready > - On GitHub, he hits the "pull request" button > - He selects the commits that he wants to be packaged in this pull > request (if not all) > - He chooses a source branch in his fork and a target branch in the > original repo and sends the request > > On the committer's side: > - A pull request appears in the list of pull requests (mails are also > sent to notify interested people) > - A committer reviews the commits (GitHub will list all the diffs) and > - a/ sends a message back to the developer with instructions to > tweak his changes in one way or the other > - the non-committer fixes what was requested and submits his > pull request again > - b/ accepts the pull request and merges it into the target branch; > this can happen in two ways > 1/ it's a fast-forward merge: the committer just hits the > button and the new code will be automatically merged > 2/ it's not: the committer resolves conflicts and merges manually > > Regarding the workflow with big projects like Apache Flex: > I don't think the pull request concept is mentioned in the nvie article. > So I guess there's going to be questions like: > - which branch(es) will non-committers have to target? > - will their code be merged into 'develop' directly or is a different > workflow required? > - maybe bugfixes go directly into 'develop', but new components go into > a feature branch? >
