Commit & Submit

So, ready to submit? (It’s okay if you’re not; there won’t be much to do on this page if you haven’t started writing code yet, though.)

In this class, we submit to Gradescope through GitLab, so before we get to the actual submission process, lets take a moment to formally introduce Git.

Git Strikes Again¶

Git is very flexible; this has a couple important implications:

1. We won’t be able to cover everything you can do with Git. Git has many features, and they can be combined in many different workflows; for simplicity, we’ll be describing only the bare minimum set of features necessary to get started with Git. You may use other Git functionality, but we will not be providing guides for those. You can check out the official Git documentation for more information or search for other resources. (GitHub, GitLab, and Atlassian tend to have some pretty nice stuff, since they all have repo hosting services.)
2. You should be careful when using Git. Git is a powerful tool, and some of the more powerful functionality may destroy your local repository if used incorrectly. None of the functionality we go over should allow you to do this, but you should definitely understand what you’re doing before running random Git commands you find on the internet.

Fortunately, GitLab should prevent you from destroying the remote repo, so in the worst case, you can just download the code from the remote repo again. You can also come in to office hours for help with Git. (The discussion board tends not to work too well for debugging issues with Git though.)

How Does Git Work?¶

You may have noticed that after you cloned your repository from GitLab using Git, the resulting directory on your machine contains the current version of the repo’s files, but with an extra .git directory inside. (If you’re using Mac or Linux, this folder may be hidden by default.) This .git directory contains all the extra data Git stores, such as the history of changes—in fact, this directory is the actual local repository, a local version of what’s stored on GitLab. Meanwhile, we refer to the directory containing this directory and the other, regular files as the working directory. (However, typically, whenever we refer verbally to the directory or path of a Git repository on your machine, we mean the working directory and not the .git directory inside; this is a minor inconsistency in terminology, so do ask if it’s not clear which we’re referring to.)

This means that there are really two versions of code on your machine: the working directory will contain the copy of the code that you’re actively working on as real files, whereas the local repository will store the entire history of the project as a series of changes between sequential versions.

Regular Git usage involves syncing changes between the working directory and the local repository, and between the local repository and the remote repository. Syncing changes in Git always works in a single direction at a time: new changes get copied from one place to another. Here’s a diagram with the names for basic commands that move changes in each direction:

As you can see, there are three main commands:

• Committing adds changes from the working directory to the local repo.
• Pushing copies changes from the local repo to the remote repo.
• Pulling is a little more complicated: it first copies changes from the remote repo to the local repo, then applies those changes to the working directory.

Committing¶

While tools like Google Docs autosave every change, Git requires us to commit our changes manually. Whenever you want to make a commit, click the green checkmark icon in the navigation bar or through the VCS menu item. You’ll have the option of reviewing your changes to ensure that the commit you’re about to make contains exactly what you want to include. Then, write a helpful commit message to remind yourself what changes you made.

When you make a commit, IntelliJ can also run some basic checks for you, including reformatting code to pass indentation and spacing style guidelines. In the Git commit dialog window, make sure the following checkboxes under Before Commit are ticked:

• Reformat code
• Scan with Checkstyle

The screen should look something like this:

After pressing Commit, IntelliJ may ask you to enter your name and email address the first time.

Pulling¶

You shouldn’t need to do this while working on this project, but if you have a partner for future projects, you’ll need to pull the changes they push to GitLab in order to acquire them on your own machine.

Open VCS » Git » Pull… and click Pull in the popup window.

You’ll also need to go through a slightly different pull process in order to get future assignment code, but we’ll cover that when we get there.

Pushing¶

Once you’ve committed your changes, you’ll also need to push them to your personal GitLab repository. Navigate to VCS » Git » Push to do so.

GitLab Commit History¶

Git is a version control system, so it stores versions of your code and lets you control them. Of course, we can view these old versions (commits), and potentially revert back to them. This might be useful if you introduced a new bug and can’t remember what you changed, and maybe even need to run an older version of code to determine when the bug was created. To see your commit history on GitLab, first go to the repository whose history you want to view, then click on the commit counter (circled in red in the screenshot below).

You will be brought to a page that shows a list of your commit history; your most recent commits are at the top and your oldest commits are at the bottom.

Here you can access some useful information: going from the red circles from left to right:

• Commit message: Clicking this will bring you to a page that shows the changes made in this commit.
• Commit hash: This is basically an ID for each commit. When you get your feedback on projects, we will say at the top which commit was graded.
• Folder icon (‘Browse Files’): Clicking this will bring you to a file explorer view where you can click through all your files as they were at that commit.

If you want to revert a file or multiple files back to an old commit version, one way you can do this is just by copy pasting the file text from GitLab into your file locally. This is probably the easiest for some, but you can also do this through IntelliJ (single file, entire working directory) and through the command line. (If you want to use the command line you can probably do the googling yourself. :D)

Submitting on Gradescope¶

The last step is to submit your work to Gradescope. Gradescope is the site that you’ll use to submit project assignments and view all of the graded work in this course, including scores and feedback on your projects, written exercises, the Midterm Exams, and the Final assignment. You should already have access to Gradescope via an your @uw.edu address. If you don’t have access yet, use the Missing Permissions Form to notify the course staff.

From the CSE 373 dashboard, tap on the P0: CSE 143 Review assignment. In the pop-up that appears, do not upload anything and directly tap the GitLab button at the bottom:

Find your repository in the list and Submit Project. Leave the branch on master.

Once you submit your work, you’ll be shown a waiting page while Gradescope grades your submission. After about a few minutes, the autograder will finish running your code and automatically update the page with the test output and your overall assignment score:

For now, you can submit to Gradescope as many times and as frequently as you like. If you make more than one submission, you can mark the submission you’d like to use as your final score. The final score on Gradescope is the score you will receive on the assignment for any programming portions (before any possible deductions for lateness).

Important Notes¶

• You should only ever commit changes to files we explicitly tell you to modify. The Gradescope infrastructure will only read from those files in your repository, so by changing other files, you increase the likelihood that your submission produces compilation errors when compiled against our grader’s version of code.
  (If you’re curious, the list of files we expect you to change in an assignment is included in the build.gradle file in the assignment’s module.)
• Future assignments will include extra tests in addition to those provided to you in the skeleton code; these will also run on Gradescope, and you’ll be able to see their names and results (and error message/stack trace, if they fail). They will also have stricter time-based submission limiting to prevent you from spamming submissions in quick succession.
• Some future assignments will also include a written analysis portion that will be submitted separately on Gradescope.