Skip to content

Lab Submission

When your lab or assignment is a GitHub repository, submitting your work is simply a matter of commit and push.

You have a couple of ways to accomplish this. You can use the git commands directly from the terminal (I strongly recommend this approach) or you can use some GUI that “wraps around” git.

See the section below for guidance on writing commit messages. Additionally, check out the Terminal Commands for a summary of the various git commands you can use.

The TLDR for using git from the command line is to follow these steps.

  1. Make sure you are in the terminal at the root of your repository. (See terminal commands for navigating folders in the terminal.)

  2. Stage whatever files you want to commit. The simplest way is to add all of the changes you have done. Use this command (and don’t forget the period).

    Terminal window
    git add .
  3. Commit your changes with a meaningful message.

    Terminal window
    git commit -m "Short description"
  4. Push to GitHub.

    Terminal window
    git push

From VS Code’s Built-In GUI

Visual Studio Code has a built-in GUI that offers another way to commit and submit your work. To learn more about version control with VS Code’s GUI tools, see their official documentation.

  1. Click on the source code tab from the sidebar (or press Ctrl + shift + g).

    Extensions Icon
  2. Enter a message in the text box with the Message placeholder.

  3. Click the Commit button.

  4. If you haven’t staged the files for committing, a dialog will open asking if you want to stage and commit directly. Click Yes.

  5. Sync Changes and if a dialog pops up asking you if you want to push and pull, click Ok.


Commit Messages

When you start out, you might think that it doesn’t matter much what message you put for your commit. You’re wrong! Good commit messages have several benefits to “future you” and others you work with. They also indicate a commitment to following professional standards.

Your commit message should clearly indicate the following:

  • What changed - Not in terms of file names, but in terms of the scope or effects of your change.
  • Why it changed - Is it a bug fix? Or is it a new feature? Is it automted tests? Perphaps you’ve added documentation to clarify something important. Or, if it’s just some chore, like clean-up of the code.
  • Where I can find more details - This is typically some reference to an issue (see GitHub Issues).
  • How it fits into the bigger picture - Does it close an issue, or is it a “work-in-progress” (WIP)? Does it involve a breaking change?

Astute writers among you might think, “He’s missing the Who and When.” Actually, git automatically includes the “Who” with your user.name and user.email (something you first set up when you installed git). The “When” is also provided behind the scenes as a timestamp on the commit.

In any case, here are some quick tips for writing good commit messages.

  • Use a good prefix for the first word in the message to indicate the type of commit
  • Don’t end with punctuation
  • Make it descriptive as a summary of what changed
  • Keep it short (less than 50 characters is good)
  • Avoid filler words