| 80 | | Once the review is done, and you're satisfied with the student's work, ask them to squash their commits and rebase from the |
| 81 | | staging branch. |
| 82 | | |
| 83 | | The big difference here is that ''you will be the one poking that friendly green "merge" button''. If the button isn't green, |
| 84 | | and doesn't say the pull request can be automatically merged, then the student will need to rebase from the staging branch again, |
| 85 | | and fix the conflicts. (Note the student should rebase from staging even if the PR can be automatically merged, as that can |
| 86 | | be true even if the staging branch has changes past the revision at which the student pulled their branch. Doing one last |
| 87 | | rebase will put the commits in time order, with the student's new commit after the others on the staging branch, and avoid an |
| 88 | | internal non-linear "merge commit".) |
| 89 | | |
| 90 | | You may need to assist students with interactive rebase to squash their commits, with rebasing from the staging |
| 91 | | branch, and with fixing conflicts during the rebase, if it's the first time they've done it. |
| | 80 | * Once the review is done, and you're satisfied with the student's work, ask them to squash their commits and rebase from the |
| | 81 | staging branch. |
| | 82 | |
| | 83 | * If their description of what their change does is not clear, ask them to post a comment describing the change briefly. |
| | 84 | |
| | 85 | * If they don't have it already, ask them to add a comment telling how to use their change in the Eden UI, so it can be tested |
| | 86 | by hand. |
| | 87 | |
| | 88 | * The big difference here is that ''you will be the one poking that friendly green "merge" button''. If the button isn't green, |
| | 89 | and doesn't say the pull request can be automatically merged, then the student will need to rebase from the staging branch again, |
| | 90 | and fix the conflicts. (Note the student should rebase from staging even if the PR can be automatically merged, as that can |
| | 91 | be true even if the staging branch has changes past the revision at which the student pulled their branch. Doing one last |
| | 92 | rebase will put the commits in time order, with the student's new commit after the others on the staging branch, and avoid an |
| | 93 | internal non-linear "merge commit".) |
| | 94 | |
| | 95 | * You may need to assist students with interactive rebase to squash their commits, with rebasing from the staging |
| | 96 | branch, and with fixing conflicts during the rebase, if it's the first time they've done it. |
