Submitting Assignments via Slack
- Make sure your exercise/project has a
package.jsonfile. The easiest way to create one is to run
npm init -yfrom the exercise/project root folder.
- Push your code to GitHub. (Likely will require a
git add -A,
git commit -m "message describing your changes", and
- Open GitHub and drill down to the exercise/project root folder (the one in which you created the
- Copy the URL from the browser's address bar. (⌘+L, ⌘+C)
- In Slack, open your cohort's channel (e.g:
/submitin the message bar (as if you were going to send that message to the channel) and hit enter
- In the dialog box that pops up, type the name of the assignment and paste (⌘+P) the URL you copied from GitHub.
- Submit the dialog box.
On our end, we'll be opening your code in a tool called CodeSandbox, creating a fork of it on our own GitHub accounts (or the V School GitHub Account), suggesting changes (mostly via comments in the code) and creating a Pull Request (PR) to your repository.
GitHub should notify you of a submitted PR. You can edit your notification settings to ensure you get an email, or you can make sure to check your GitHub web app notifications regularly.
When you click on the PR, you'll see a tab called "Files Changed". Clicking on this tab will show you the suggestions we made (mostly via comments).
Note: Because of a quirk of the CodeSandbox, it may show a bunch of files listed in this "files changed" column that say "no changes". You'll just need to scroll past all the files that say "no changes" looking for the green highlighted areas to find the real changes
How do I implement the changes?
You have a couple of options here.
- Open the suggestions from the PR in GitHub and make the changes directly in your code. Once you've made the changes, you can reject the PR and push your changes up to GitHub.
- Accept the PR, which merges our changes into your code. After accepting and merging our PR, run a
git pullin your project on your machine, which will pull our comments directly into your code. Then go about implementing the changes.
Either method is 100% okay. Experimenting with both will help you become more familiar with how GitHub and the PR process works.
Why so complex?
This process is a bit more complex than it may seem like it needs to be. The reason we've chosen this method is simple - we want to get you very familiar with GitHub and its Pull Request system. Submitting PRs is a very common task at work, and the process of code review will be an invaluable process for you to learn.