This semester, you’ll be using some immensely useful industry tools to submit your assignments.
In addition to storing code, GitLab has many features to help users collaborate with others. Users can share projects with other users, giving them the ability to push/pull code to/from the project. There are also bug tracking utilities, code review tools, and much more.
If that sounds scary, it really isn’t. This semester, you will need to be able to do these few things with git and GitLab:
That’s it! When you push your code to GitLab, the instructor will be able to access your code for grading.
As the semester progresses, Git will seem less and less scary. It is an incredibly useful tool.
I will be using the regular Git command line interface (CLI). If you choose to use a graphical desktop client for Git (e.g., Source Tree, GitHub Desktop, etc.), you’re on your own. Don’t ask me for help with such nonsense.
Do not blindly copy/paste Git commands from the Internet and run them. That’s generally good advice for any commands/code you might find on the Internet. Make sure you understand what a command does before you run it. Not all advice on StackOverflow is good advice.
Before we get into the thick of it, you should configure git on your development machine.
Run the following commands to tell Git who you are
# Use your name git config --global user.name "John Doe" # Use your email address git config --global user.email firstname.lastname@example.org
If you don’t configure git, it will complain and complain whenever you try to commit changes.
git config to tell Git to use your favorite editor.
# In this case, we're telling git that we want to use jpico git config --global core.editor jpico
Setting up an SSH key with GitLab is a convenient (and secure) way to push/pull/clone code without typing your password over and over. Briefly, an SSH key comes in two pieces: a public key and a private key. By adding your public key to your GitLab account, Git will be able to use your private key to securely communicate with GitLab. No need for a password!1
It boils down to a couple of steps:
For more detailed instructions on key generation, refer to GitLab’s documentation on creating an ssh key.
Here’s the breakdown of the assignment workflow:
reflection.mdis present, and it contains any submission comments you wish to make.
Throughout the semester, you will be assigned multiple homework assignments. For each assignment, you will be granted access to a git repository on GitLab, which will contain any starter code necessary for the assignment. Only you and the instructor will be able to see the contents of the project or even see that it exists in GitLab.
You will be granted developer permissions to your repositories. This will allow you to view the project and push changes to it.
Let’s say you’re ready to start a new assignment. The first thing you have to do is retrieve your starter code from GitLab. Here is a step-by-step procedure for doing this:
https://git-classes.mst.edu/2017-FS-CS-2001and end with
email@example.com:2017-FS-CS-2001and end with
git clone <repository URL from step 3>
git clone https://git-classes.mst.edu/2017-FS-CS-2001/2017fs-b-01-mwwcp2.git
That’s it! Now you’ve cloned your repository down, and you’re ready to get started.
Assuming you’ve cloned your code (as described above), then it’s time to start working on your assignment.
As far as working on the files go, there’s nothing special you have to do. Edit them, compile them, have fun with them. When you’re ready to commit (take a snapshot of) your code, you’ll need to interact with git.
git statusto see which files are staged, modified, or untracked.
git add main.cpp
git statusagain to make sure that the correct files are staged for commit.
Now your changes have been committed!
There are a couple of commands that come in handy for viewing the state of your repository:
After you’ve committed something, you can push it to GitLab with
Once you’re all done with your assignment, and you’re happy with your work:
reflection.mdand write a couple paragraphs as described in the section below.
git add) and commit the new file (
reflection.mdis present on the GitLab website and that your code looks the way you want it to.
Periodically, we will snapshot all CS 2001 repositories. There are three times that are of interest to you:
For each snapshot starting with the earliest, we will ask the following questions about your repository:
If no valid submission was found for any snapshot, then you didn’t turn it in. That’s a zero.
Log into GitLab and look at the files in your project.
If you refer to the steps above, you’ll notice that we’ll grade your first snapshot that contains a
If you want to submit late, simply ensure that your repository doesn’t contain a
reflection.md before we take a snapshot.
What if you’ve already started working on your
You have a couple of options:
git rm, commit the file removal, and push that commit to GitLab
reflection.mdto something else, commit the rename, and push that commit to GitLab.
Make sure you check GitLab before the snapshot deadline!
If there’s a
reflection.md when we take a snapshot, we’re going to assume you want your assignment to be graded.
We need a way to know:
Every assignment you do for CPL will require that you write a
reflection.md file that contains a short summary of your experience with the assignment.
This should be the very last thing that is added to your repository.
reflection.md exists in your repository, we will assume you are done with this assignment.
reflection.md does not exist in your repository, we will assume that you are still working on this assignment, and you are not ready to turn it in.
Some facts about
reflection.md. If you are ready to turn in your assignment, you must…
git addto track the file
reflection.mdwill severely hurt your grade.
After we read your
reflection.md, we want to know some or all of the following:
reflection.md should be a reflection on your experience completing the assignment.
As you write your
reflection.md for an assignment, think about your experience from beginning to end.
Think about things that were easy, things that were hard, skills you may need to improve, and skills that you did improve.
You don’t have to blow our minds with insight, but we expect to see some thoughtful discussion about your experience.
We also intend to use the
reflection.mds to help us understand where students are struggling.
That way, we can use this information to better prepare you for future assignments and tests.
So, we’ve given you a bunch of “do” items. Here’s what we don’t want to see:
reflection.md exhibits too many of the items listed above, you will lose credit.
That’s a shame, because these are nearly free3 points.
reflection.md should be professional in tone and written in coherent English.
It isn’t an essay.
In total, your
reflection.md should be around 100 to 150 words in length.
If you feel your write-up should be longer than that, you’re welcome to do so.
Of course, if you have enough feelings to warrant writing an epic essay, we should probably have a conversation in person, too.
Here’s a modestly lengthy
reflection.md we fabricated for an old CS
2001 assignment. It gives us a pretty solid impression of how this
fictional person’s assignment went.
Python 1: A Safe Cracker tool for Carmen Sandiego ------------------------------------------------- Starting this assignment was a challenge for me, as this was my first experience picking up and completing code that I didn't write myself. I understood the looping constructs, although it took some time to get used to Python's for-each loop. The program was frustrating to test, since I had to type in the inputs over and over... I felt like I was in CS 1570 again. It would be cool if we had a way to automate the testing. Overall, the program wasn't too difficult to complete. The topics we didn't cover in class were covered by the posted assignment resources. I did do some additional googling for `argparse`, but that was mostly for my own entertainment.
reflection.mdshould be a well thought-out reflection of your experience completing an assignment.
reflection.mdshould be between 100 and 150 words in length.
reflection.mdfile to your repository.
reflection.mdto indicate that your submission is ready.
These are some nice resources for learning more about Git:
If you see mentions of BitBucket or GitHub around, they’re just web applications like GitLab. Same basic idea, created different people.