Homework 5: More Version Control (git)

This assignment focuses on using Git as version control software for working on projects across a large team. We assume you will have finished any setup required from HW4. You can do this lab from the CSE VM or from attu. Instructions for submission to the autograder can be found below.

Task 0: Preparing to use CSE GitLab¶

All students in CSE 391 have been given access to the CSE GitLab service for this quarter. If you are a CSE major, you should log in using your CSE NetID; otherwise, use your UW NetID.

Task 1: Contribute to a shared Git repository on GitLab¶

All of the students in CSE 391 have recently been hired by FAANG! The frontend team wants to build a page that features all of the incredible staff at the company. For this task, you will be adding yourself to that page! The purpose of this task is to get practice creating and merging feature branches on a project worked on by many people (your peers)!

You should have been given access to the shared repository described below. If you are having trouble cloning or pushing to the repository due to a permissions problem, you may need to double check your email for an invitation to the repository.

First, Clone a copy of the remote repo – On your machine (e.g. the CSE VM, attu), cd into the directory where you would like to create your local copy of the repo and execute this command:

git clone git@gitlab.cs.washington.edu:cse391/24wi/faang.git

Problem 1 Update your local repository to contain the latest main¶

Since this repo is shared by so many people, we want to keep the main branch “clean” by never pushing to it. Instead, we’ll work on our own feature branch (and eventually merge this in via GitLab).

First, make sure that your current branch is on main by running

git branch

You should see the branch name main with an asterisk (*) next to it, indicating that main is your current branch. If you are not on the main branch, you should switch to it with git checkout main.

Then, to update your local copy of main to match main on the remote repository, type

git pull origin main

If any changes have been made since you first cloned the repo, you should see output that looks something like this, followed by a list of updates made to the repository that you’re pulling down.

From gitlab.cs.washington.edu:cse391/24wi/faang
* branch main -> FETCH_HEAD
 6745c4b..6c8d66e main -> origin/main
Updating 6745c4b..6c8d66e
Fast-forward

Problem 2: Create a new branch for your additions to the staff page¶

Your work on the staff page should be on a feature branch, separate from the main branch. Run

git checkout -b <yourNetID>_staff_page

Problem 3: Add your bio to the staff page¶

From the faang directory open up Staff.java in your favorite text editor. Staff.java is a simple program that contains one method for each employee at FAANG. Create a method, which must be named after your GitLab username, that returns an Employee object that represents you.

An Employee has a:

• String bio
• String picture file path (and accompanying String alt text)
• String job title

The bio and job title are arbitrary Strings (but keep it PG-13). The picture doesn’t need to be an actual photo of you, but something that you feel like represents you! Place a copy of that image in the images/staff directory, and make the parameter the name of the file (not including the images/staff prefix).

The alt text should accurately describe the contents of the image. If you’re curious about what makes “good alt text”, Deque has a great blog post explaining more and the MDN web docs explains what it is in technical terms.

Then, make sure that Staff.java still compiles after your edits. If it doesn’t compile, you won’t be able to merge your changes!

Problem 4: Add your product to the products page¶

The front-end team also wants you to add a new product for FAANG to sell!

Open Products.java and add a Product. Similar to the Employee object, a Product object has a:

• String name
• String description
• String picture file path (and accompanying String alt text)
• double price of the product

Similar to the staff image, place your image inside of images/products.

Then, make sure that Products.java still compiles after your edits. If it doesn’t compile, you won’t be able to merge your changes!

Problem 5: Push your change to the remote repo¶

Use the appropriate commands to commit your changes to your branch and push to the remote repo. You should be able to see your commits in GitLab using the following link:

https://gitlab.cs.washington.edu/cse391/24wi/faang/tree/YOURNETID_staff_page

Alternatively, you can navigate there by going to the repository main page and clicking on “Branch” at the top of the page. Here you will be able to see all of the branches for this repository, including yours.

Problem 6: Make a merge request on GitLab¶

When your work is in a completed state, you’ll typically have another teammate review your code before merging your changes into the main branch. In GitLab, we do this with “merge requests”, which allows teammates to review, comment on, and approve your work.

Create a merge request for your feature branch in GitLab. To do so:

1. go to the repository main page
2. select “Merge Requests” on the left side-nav, and click “New Merge Request”
3. select your own branch in the “Select source branch” dropdown, and set your target branch to main
4. click “Compare branches and continue”
5. give your merge request a reasonable title, and write a description of your changes
6. leave the other dropdowns and options as-is, and submit your merge request! - While often we want to delete the branch, be sure that you UNCHECK the box to delete the branch - we need the branch to still exist to give you credit in Gradescope.

Once this happens, GitLab will automatically run some code to make sure that:

• your branch can be merged properly (with no merge conflicts)
• your branch is “up-to-date” with the main branch. if things have been merged into main since you made your branch, this will likely be false!
  • to fix this, merge the main branch back into your own feature branch. You can do this locally or via the GitLab UI.
• your merge request doesn’t “break” the site. For this project, that means:
  1. all the .java files compile and run with no errors
  2. you haven’t removed any lines of the codebase in your merge request

Problem 7: Leave a comment on your merge request¶

Typically, you’ll request a review from your teammate(s). Right now, they’re a bit too busy with their own changes, so your own “review” will suffice. Leave at least one comment on a change in your merge request. It can say whatever you’d like!

Problem 8: Merge your branch from GitLab¶

Let’s incorporate your changes into main so it can make it on the main website!

There is a “Merge” button close to the top of your page. If you’re able to click it, go for it - you’re done this step!

However, the merge button may be disabled. This is for one of four reasons:

1. there is a merge conflict with main
2. your branch is not up-to-date with the main branch on GitLab
3. your code does not compile and run with no errors
4. your merge request removes one or more lines from the existing codebase

It is your responsibility to resolve these problems!

1. You can resolve merge conflicts using the GitLab merge conflict UI (“Resolve conflicts”) or with the command-line. - make sure to not accidentally delete other people’s changes!!
2. You can merge the main branch on GitLab back into your feature branch
3. You can debug your program if it does not compile / runs incorrectly (this is usually a typo).
4. You can add extra commits that restore the lines you’ve accidentally removed.

Problem 9: Turn In¶

To submit your work, you will submit the homework5.sh file to Gradescope.

You can get the homework5.sh file by running this command in your terminal:

wget https://courses.cs.washington.edu/courses/cse391/24wi/homework/hw5/homework5.sh

This file containts just one function called print_username. Unlike the other homeworks, you will leave the echo command but replace the text string with your GitLab username. You can find this by going to gitlab, and clicking on the profile icon in the top right, your username is the text following the @ sign. It will usually be your CSE or UW IDs - Matt’s is mxw.

function print_username {
  echo "your gitlab username here"
}

Gradescope will give you a score out of 2. However, anything 1.5 or above will count for full points (and anything between 1 and 1.5 counts for 1 point). This core is provisional: if you do not use your own username (i.e. by submitting someone else’s work), you’ll receive a 0 on this assignment.

This autograder is still new (and we’ve recently added even more infrastructure). Running into problems? Post on Ed!

(Optional) Task 2: Use the website¶

The “Easy” Way¶

We’ve set up something called “continuous deployment” that rebuilds and deploys the site on each commit to the main branch. You can visit the site at https://cse391.pages.cs.washington.edu/24wi/faang/.

But, it’s more fun to do it yourself, with…

The “Hard” Way: Build it Yourself!¶

You can compile all the Java files in the repository’s root directory and then run the GenerateSite program (the entrypoint for this site generator).

This will produce an index.html file that contains a list of all the products and staff, as well as individual .html files for each product and employee.

To view the website, you have a few options:

1. If you’re working locally you can navigate to the faang directory using Finder (macOS) or File Explorer (Windows) and double click on the index.html file. This should open the website in your default browser.
2. If you’re working on attu you will need to copy your files over to your local machine to view them. You can do this with the following command:

   scp -r CSENetID@attu.cs.washington.edu:/path/to/faang .
   

   Now that this is copied over, you can view them in a web browser using part a).
3. If you’re working on the VM you can use the File Manager application to navigate to the faang directory and double click on the index.html file, which should open the site in Firefox.

Note: Compiling .java files will generate .class files and GenerateProducts.java will generate several .html files. These should NOT be included in the repository. A git repository should only contain the source code needed to generate all necessary artifacts, but not the artifacts themselves. Every git repository has a .gitignore file in the toplevel directory that contains the names of files should be ignored by git (for example, these files should not appear in git status or git add). If you inspect the .gitignore file for our repository you will see that .class and .html files are listed. DO NOT MODIFY THE .gitignore FILE.

Tips¶

• If you ever run the git status command and see the output "Your branch is ahead of 'origin/main' by N commits", then this means that you have local commits that have not been pushed to the remote repository yet.
• Git will not allow you to pull updates into your repository while you have unstaged changes. Therefore, you must stage (git add) and commit all of your changes before pulling.
• DO NOT try to go back and modify previous commits. This can get you into a huge mess if you are working on a shared project.