| Excerpt |
|---|
[OBSOLETE] Thoughts about supporting direct (and informal) collaboration without the need for pull requests. |
| Table of Contents |
|---|
Introduction
...
There are various ways to achieve this but some work better than others.
| Approach | Discussion | ||||
|---|---|---|---|---|---|
| Access collaborators' forks directly | This works, but forks are private by default, so their owners will have to allow access to the repositories (which could include work that isn't to be shared). In order to scale, one collaborator would need to be nominated as the "primary" one. | ||||
| Use pull requests to collaboration branches on the project repository | This works, but requires the formality of a pull request. Until the pull request has been approved and merged, collaborators can't see the code.
| ||||
| Use direct access to collaboration branches on the project repository | This works well. Collaborators create an "upstream" remote to the project repository and can push/pull directly to/from collaboration branches. Branch permissions prevent direct access to the master, develop, feature/xxx and release/xxx branches. |
Experiment
I adjusted the WT-369 project repository's branch permissions. For those of you who can't access them, they now look like this. The key point is that only the branches that we care about (i.e. that are part of our process) are restricted. So we can freely create and use collaboration branches (I suggest branches called collab/xxx). Talk id talk-434
| Talk | ||
|---|---|---|
|
...