Git information for CSE 374

Background

Version control software is used to help individuals and team maintain a record of their work. Git is an open source, command-line, tool for version control. We use Git in CSE 374 because it is one of the most ubiquitous tools in modern software development. Skillful use of Git not only allows an individual to maintin a record of their own work, but also allows large teams of individuals to contribute to shared projects.

In CSE 374 we use the Allen school Gitlab server. Gitlab is one particular service that provides remote hosting for Git repositories.

The Gitlab service provides extensive HTML (web) access, and some things are easier to do through that interface. This course (and documentation) assume and encourage all students to interact primarily through a shell interface, likely via Calgary.

Getting Started

Step 1: Log into Gitlab

All students in CSE 374 have been given access to the CSE GitLab service for this quarter. You will log-in using your UNetID. If you already had an account on Gitlab you will continue to use that account. Otherwise, a new account has been made for you. Additionally, a new repo has been made for each student, which is accessible only by that studen and the CSE 374 staff. Log on to CSE GitLab by going here: https://gitlab.cs.washington.edu/. You should be able to locate your new repo following the pattern https://gitlab.cs.washington.edu/cse374-26sp/UNETID.

Step 2: Adding an SSH Key

In order to “talk” to the GitLab service from a remote computer (such as Calgary), you’ll want to create something called an “SSH key” on those computers. These offer a way for you to log in to services without needing a password. After creating an SSH key for each of your computers, you’ll want to register that key with your GitLab account.

Caution: You need a different SSH key for every machine. Calgary is a separate machine from your local machine! If you created a SSH key on your local machine for a previous course or on your personal machine, you will still need to log-into Calgary and create a new SSH key there.

To learn more, please visit the CSE department’s guide to generate SSH keys: https://gitlab.cs.washington.edu/help/user/ssh.md. Generally, you should follow the steps under “Generate an SSH key pair” and “Add an SSH key to your GitLab account”.

an ED25519 key is sufficient
We suggest you accept the default location for the key and that you do not add a password
if you’re having trouble finding the SSH keys page, try visiting the URL: https://gitlab.cs.washington.edu/-/user_settings/ssh_keys.
you can view the contents of a key by cating it directly, e.g. cat ~/.ssh/id_ed25519.pub

Step 3: Configure Git

Regardless of whether you are working on Calgary or your personal computer (or another server) you will want to configure Git before you get started:

Set up your user information. You should use your UW email account
```
$ git config --global user.name "Your Name"
$ git config --global user.email yourEmail@uw.edu
```
Tip: You can check what you have set so far using git config –-list.
If you want to use an editor other than vim for commit messages, you may want to set your default editor. For example to use emacs:
```
$ git config --global core.editor "emacs -nw"
```
Tip: Use git commit -m 'commit message here' to add a message inline and not use an editor.
Tip:If you find yourself in vim by mistake, use :q (colon, the letter q, then enter) to quit.
You might get a message that push.default in unset, in which case you can set your push default:
```
$ git config --global push.default simple
```

Step 4: Clone your repo, and make your first commit.

There are a few ways to create a new repo. One way is to turn an existing directory into a repository using git init. Another way is to clone an existing repository. As a new project repository has been created for you, we will use the second way: git clone git@gitlab.cs.washington.edu:cse374-26sp/UNETID.git. (Use your own UnetID for this.)

Now you can start using your new repo:

Open a new file called README.md and add some information to it.
Save your file. Then run git status. This should alert you to your changes to the repo.
Use git add README.md to stage your file
Use git commit -m 'my first commit' to commit your file
Use git push to push your file to the remote (Gitlab) repository.

Note: You may have noticed that there were options and lot of information avialable via the HTML access to your repository. You are welcome to explore this and follow those directions - it may leave your repo in a slightly different state when you do clone it. You can find the SSH address for your repo using the 'code' button in the upper right hand side of the front page: you'll use this SSH address for cloning and interacting with this repo.

Step 5: Set an upstream repository to get sample code

An upstream repository is on that you can draw code from to include in your own repository. In CSE 374 we will use an upstream repository to provide you with all the sample code and homework starter code. You can do that now, and further instructions for use will be provided with individual homework descriptions.

Set a new remote: git remote add upstream git@gitlab.cs.washington.edu:mh75/cse374-materials.git. You can use this command precisely, and should not replace mh75 with your userid.

You should now have a local copy of your repository, and a remote copy called origin. Additionally, you have a remote upstream repository that is pointing the the cse374-materials repository. You can verify this with the command git remote -v.

[mh75@cancun mh75repo]$ git remote -v
origin  git@gitlab.cs.washington.edu:cse374-26sp/mh75.git (fetch)
origin  git@gitlab.cs.washington.edu:cse374-26sp/mh75.git (push)
upstream        git@gitlab.cs.washington.edu:mh75/cse374-materials.git (fetch)
upstream        git@gitlab.cs.washington.edu:mh75/cse374-materials.git (push)

To ensure that the upstream repository doesn't overwrite your own, you will configure git to merge code instead of rebase it when you pull: git config pull.rebase false (You may need to resolve merge conflicts.)
Now you can pull the new code: git pull upstream main --allow-unrelated-histories --no-edit
Fix any merge conflicts if necessary (you will likely need to edit README.md), and then add, commit, push

More information

There are numerous references on the web, including Git and Gitlab documentation. Here are some of our favorites:

OhShitGit