Homework 5

More version control

This assignment continues our study of learning how to use git as a version control system. Whereas the prior assignment focused on working on a project alone, this assignment focuses on collaborating with others by contributing to a website. In the process, you’ll practice working with a remote repository, using merge requests, and (potentially) resolving merge conflicts.

Everyone enrolled in CSE 391 has recently been hired by FAANG (hooray) and given access to the faang repository. If you can’t find this repository after logging in, be sure to ask on the discussion board!

Download the homework files on attu

After logging into attu, download the homework files.

git archive --remote=git@gitlab.cs.washington.edu:cse391/25wi/hw5.git --prefix=hw5/ HEAD | tar -x

In homework5.sh, complete the print_username function so that it prints-out your CSE GitLab username.

For this part only, be sure to keep the echo command so that running print_username will print out your CSE GitLab username.

Our autograder will grade this homework by cloning the faang repository and checking for your changes.

Task 1: Contribute to the shared repository

The web team wants your help building a prototype website for listing products.

Clone the shared repository

Let’s clone the repository to attu.

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

Test that it works by building the website.

cd faang
java Build.java

If it’s successful, you should see some printed output listing the products that have been added by others, as well as the index.html file.

Switch to a new feature branch

Since we’ll be collaborating with the rest of the class, we won’t directly push to the main branch. Switch to a new branch prefixed with your GitLab username. You can include a suffix to indicate the particular product that you’re planning to add.

Edit, stage, commit, and push your product

In the Build.java file, prepend a product to the Map<String, Product> products with data of your choice. Each Product has five fields:

  • String displayName and String description,
  • String image filename corresponding to an image in assets/images/ and accompanying String altText (alternative text, or description for the image),
  • and a String price for the product.

Remember to add an image to the assets/images/ directory that matches your chosen image filename. Be sure that your changes meet the following checklist:

  • Are the changes appropriate for a washington.edu publicly-accessible website?
  • Do the changes add a new map entry for the product and its corresponding image?
  • Does the alternative text accurately describe the content of the image?

When entering the Product into the map, you will need to choose a string key that will be used as the basename for the webpage, e.g. the key “dirt” will produce the webpage products/dirt.html. It must be a valid and unique “safe” URL string: spaces and certain special characters are not allowed.

Be sure to prepend your changes to the products map. You should not need to modify any existing lines of code. If you try to instead append your changes to the products map, you may need to add a trailing comma to the end of the preceding product: this becomes a hassle for others to debug.

After ensuring java Build.java still compiles the website, stage, commit, and push your changes. When you push your new branch, GitLab will respond with a message letting you know how to create a new merge request.

Create a merge request

A merge request is GitLab’s way of enabling collaborative code review. Although it sounds like a built-in git feature, merge requests are not a part of the git tool. Instead, they are an enhancement introduced by GitLab. Let’s create a merge request for the changes on our branch.

  1. Follow the link from when you pushed your branch to GitLab. If you can’t find the link, you can also do this manually: create a New merge request in the faang repository, choose your branch under Select source branch, and Compare branches and continue.
  2. Give your merge request a descriptive title and write a description of your changes. Do not modify any other fields.
  3. Create merge request to submit your merge request to the class.

Once this happens, CSE GitLab will automatically run some code to ensure that:

  • Your branch can be merged properly without merge conflicts.
  • Your branch is up-to-date with the main branch. If other commits have been merged into main since the time you began working on your own branch, merge the updated main branch back into your own feature branch from attu or via the CSE GitLab web interface.
  • Your branch’s Build.java file still compiles the website without any errors.

Task 2: Review someone else’s merge request

From the list of Merge requests, choose anyone else’s open merge request that does not yet have an assigned reviewer. In the merge request details, assign yourself as a Reviewer (you should be the only reviewer) and switch to the Changes tab to review their changes:

  • Are the changes appropriate for a washington.edu publicly-accessible website?
  • Do the changes add a new map entry for the product and its corresponding image?
  • Does the alternative text accurately describe the content of the image?

If there are any areas for improvement, add comments accordingly and, if the fix is easy to make, go ahead and make the necessary changes. If the changes would not be easy for you to make, unassign yourself and repeat this process with a different merge request. Once the merge request looks good, write “LGTM” (looks good to me) and Merge the merge request.

Address merge conflicts

In some cases, the Merge button may be disabled. This can occur for any of the following reasons:

  1. The changes cause a merge conflict with main.
  2. The branch is not up-to-date with main.
  3. The branch does not compile and run without errors.

It’s common for merge request reviewers to help address small problems and save the original author some time. You can resolve merge conflicts using either the Resolve conflicts web interface or by switching to the branch on attu, fetching the updated main branch, rebasing onto main, and force-pushing your merge conflict resolution back to the feature branch so that it’s up-to-date with main.

Admire your changes

After someone else reviews, merges, and successfully deploys your merge request, your changes will be visible at https://cse391.pages.cs.washington.edu/25wi/faang/. For the purposes of grading, the Gradescope autograder will only check for the steps that you are individually responsible for: contributing a merge request of your own and merging someone else’s request into the main branch. You may submit to Gradescope and receive credit before your merge request is approved by someone else.