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?
