| 80 | | You may need to assist students with interactive rebase to squash their commits, and with rebasing from the staging |
| 81 | | branch. See the student procedures for more about this. |
| | 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. |
| | 92 | |
| | 93 | Also see the student procedures, so you know what they know. |
