| 12 | | After some head-scratching, discussion, and trial runs with help of GCI students, here is what we are doing. |
| 13 | | It may sound complicated, but it is designed to avoid issues we encountered with a less formal procedure, in |
| 14 | | which mentors and students were freely updating from the main repository, without coordination. |
| | 12 | After some head-scratching, discussion, and trial runs with help of GCI students, here are two options we are considering. |
| | 13 | Both are designed to avoid issues we encountered with a less formal procedure, in which mentors and students were freely |
| | 14 | updating from the main repository, without coordination. |
| 23 | | their local working branch for GCI tasks. Students will each have their own branch in the GCI repository to send PRs to |
| 24 | | so reviews and merging of PRs for each student can be done asynchronously. |
| | 23 | their local working branch for GCI tasks. |
| | 24 | |
| | 25 | ''Optionally'', students will each have their own branch in the GCI repository to send PRs to so reviews and merging |
| | 26 | of PRs for each student can be done asynchronously, and so students can be released to work on other tasks more |
| | 27 | quickly, as they will not encounter conflicts. |
| 27 | | is aggregated. As mentors accept pull requests, they will merge them into the staging branch. If there is a conflict at |
| 28 | | this point, it will be with some other student's work, not with an update from the main repository. The mentor can |
| 29 | | resolve the conflict (which the student's assistance if needed). |
| | 30 | is aggregated. |
| | 31 | |
| | 32 | The two options diverge at this point: |
| | 33 | |
| | 34 | If we are not using separate student branches, then the target of student PRs will be the staging branch. |
| | 35 | In that case, other students' work will likely be merged into the staging branch while a student's PR is being reviewed, |
| | 36 | so by the time the PR is ready, there may be a conflict with the other students' work. The mentor will help the student |
| | 37 | with the appropriate git procedure for rebasing and resolving their conflict. This is much like the normal workflow |
| | 38 | for submitting to trunk. |
| | 39 | |
| | 40 | If we are using student branches in the GCI repository, then students will do PRs to their individual branches there. |
| | 41 | When a mentor accepts a PR, it will be merged into the students branch in the GCI repository. Since no-one else is |
| | 42 | updating that branch, there will be no conflict. Mentors will then merge the student's branch into the staging branch. |
| | 43 | If there is a conflict at this point, it will be with some other student's work, not with an update from the main |
| | 44 | repository. Conflicts should be relatively easy to resolve, as commits should be small. The mentor can resolve the |
| | 45 | conflict, with the student's assistance if needed. |