Gitlab Guide

Throughout CSE 333, you will use Gitlab and git control flow in order to work collaboratively on exercises and homework. This guide will help you get started with Gitlab and how to use git effectively in this course.

CSE 333 Gitlab Setup

The following instructions are for connecting your CSE Linux environment (attu or CSE Linux VM) to your Gitlab repo in preparation for all of the Homework. The later Git Workflow section has tips and tricks for using git as you work on the Homework, including if you are collaborating with a partner.

All commands shown below should be run from the CSE Linux environment (attu or CSE Linux VM).

Find Your 333 Repository

Navigate to .
- If you have a CSE NetID, use the green "CSE NetID" button to log in; otherwise, use the white "UW NetID" button.
In your list of Projects, click the CSE 333 repo named cse333-23sp-students/cse333-23sp-<netid>.
- These are usually created Wednesday night of Week 1. If it is past then and you still don't see your repo, please contact your instructor ASAP to have one created.

Add Your SSH Key

This will allow you to access your repo without having to authenticate every time (i.e., no more typing your password!) and will greatly improve your workflow.

Check to see if your CSE Linux environment (attu or CSE Linux VM) account already has an SSH key by running:
```
$ cat ~/.ssh/id_rsa.pub
```
- If you see a long string starting with ssh-rsa or ssh-dsa, skip to Step 3.

Generate a new SSH key by running:

$ ssh-keygen -t rsa -C "<netid>@cs.washington.edu"

Print your SSH key to the terminal by running:
```
$ cat ~/.ssh/id_rsa.pub
```
Highlight and copy the complete key (i.e., starting with ssh- and ending with your username and host).
Add your SSH key to GitLab:
- Navigate to by clicking on your avatar in the upper-right, then "Preferences", then "SSH Keys" in the left-side menu.
- Paste your SSH key from Step 4 into the "Key" text box and give a "Title" to identify what machine the key is for.
- Click the "Add key" button below "Title".

Git Configuration

The git commmand looks for a file called .gitconfig located in your home directory that contains a variety of options that control git's behavior. Some commands (e.g., commit and push) will produce verbose warning messages if certain options are unset; these commands will properly configure git. If you've set up git before, this section can be safely skipped as these commands only need to be run once per user (though running them again won't cause any harm).

$ git config --global user.name "<your name>"

$ git config --global user.email "<your netid>@cs.washington.edu"

$ git config --global push.default simple

Your First Commit

Find your repo's URL by navigating to your project's details page, clicking the blue "Clone" button on the right, and then clicking the copy icon under "Clone with SSH".
```
$ git clone <repo url>
```
```
$ cd cse333-23sp-<netid>
```
```
$ touch README.md
```
- This creates an empty file called README.md.
```
$ git status
```
- This prints out the status of the repo; you should see 1 new file named README.md.
```
$ git add README.md
```
- Stages a new file/updated file for commit. This time, it should output git status: README.md staged for commit
```
$ git commit -m "First Commit"
```
- Commits all staged files with the provided comment/message. This time, it should output git status: Your branch is ahead by 1 commit
```
$ git push
```
- Publishes the changes to the central repo, which should now be viewable in the web interface. You may need to refresh your browser first.

Developing with Git Workflow

Once you have a made a local copy of your Gitlab repository in the CSE Linux environment (attu or CSE Linux VM), you can now make changes to files your repository locally!

The repository on Gitlab and your local copy do NOT automatically sync with each other, so we have an additional responsibility of keeping both of them up to date so you (and your partner) don't have stale/outdated copies of files).

The expected git workflow on this page should suffice for CSE 333, but you can find more details in the .

Updating Local and Gitlab Repositories

Update Local from Gitlab

Navigate to anywhere within your local repository and use the command:

$ git pull

You may run into a merge conflict when working with other collaborators. Refer to for resolving merge conflicts. You can reduce the possibility for merge conflicts by consistently making sure your repository is up to date when developing.

Update Gitlab from Local

You only want to commit source files since everything else just takes up unnecessary space in your repo and can be (re)built from the source files. Compilation products also become stale (i.e., out of date) as soon as you make any changes to your source files. A basic .gitignore file is included in your initial repo that will omit object files (.o files) and text editor backup files automatically. You may add more files to be ignored to .gitignore, if desired.

Make sure that you are in your local repository and that all updates to files have been saved before using the following commands:

$ git pull  # make sure your local copy is up to date with Gitlab

```
$ git add <files>  # stages files to commit to Gitlab
```
- It is common to navigate to the top-level repository directory and then use . (period character) as <files>, which will stage all added/deleted/modified files in the local repo because . represents the current directory.
- You should omit any added/deleted/modified files from your git add command that you don't want commited to the Gitlab repository.

$ git commit -m "<message>"  # add a descriptive message about your update

$ git push  # push your changes to Gitlab

Recovery Methods from Weird Git Situations

Keeping your workspace organized is crucial to keeping your workflow smooth, efficient, and as productive as it can be. By making sure to frequently update your local and Gitlab repositories, you reduce the chance of getting into weird situations. Nevertheless, it is common to end up in a "Git spaghetti ball" every so often, so here are some useful survival tips and commands.

Recovering from Local Messiness

The following git commands are ways to manage local changes to your repository before pushing to Gitlab:

Reset your files to the HEAD of the branch if you don't want your changes anymore:
```
$ git reset --hard HEAD
```
Reset a single file instead of the entire branch:
```
$ git checkout HEAD -- <path to file>
```
Revert changes that were already committed:
```
$ git reset --soft HEAD~1
```
Stash/hide local changes and revert to a clean working directory:
```
$ git stash
```
- Revisit your stashed changes after you're done working on a fix:
```
$ git stash pop
```
- Discard the last stashed state:
```
$ git stash drop
```
- More info on .

Reverting to an Old Commit on Gitlab

This is a way to remove a commit that you pushed to Gitlab but no longer like. These instructions take inspiration from .

Log in to the and navigate to your repo for CSE 333. On the left menu, hover over "Repository" and then click on "Commits" to view your repo's commits in reverse chronological order.
Go to the specific commit you want to revert (i.e., the earliest commit you want to remove) by clicking on its title:
Click on options on the top-right side of the page and press revert:
You won't need a merge request for changing your own work (unless you want to), so you can unselect the "Start a new merge request with these changes" checkbox and click Revert:
Your repository has been updated! Don't forget to update your changes in your local repository by running git pull.

Managing Git Tags

Submitting your homework (not the exercises!) requires you to add a specially named tag to a commit in your Gitlab repository (i.e., you do NOT submit anything yourself to Gradescope). This section is about managing those tags.

Note that homework submission time is counted by the time of the tagged commit, not the time of the tagging. For example, if you created your local commit at 11:55 pm but tagged and pushed the commit and tags at 12:05 am, your submission will be considered ON TIME (11:55 pm). However, you need to have created and pushed the tag before the staff runs the script to upload submissions to Gradescope.

Adding a Tag

Make sure to add a tag after you have completed the homework assignment. What the tag does is mark a specific commit in your repository with a name that makes it easy for someone to find.

$ git tag hw<#>-final # this is the required tag naming scheme for CSE 333
$ git push --tags # push tags from local to Gitlab

Removing an Old Tag

If you add or commit changes to the homework after adding a tag, make sure to remove the old tag with the commands below and then add a new tag afterward:

$ git tag -d hw<#>-final
$ git push origin :refs/tags/hw<#>-final