Homework 5: More Version Control (git)

This assignment focuses on using Git for version control. 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: Getting ready to use Git and the CSE GitLab service¶

Log on to 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 on using your CSENetID, otherwise use your UWNetID. Log on to CSE GitLab by going here: https://gitlab.cs.washington.edu/

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

It’s your second week at FAANG and you’re starting to feel more comfortable. The frontend team needs help with the website, and wants to get you integrated into their version-control workflow using git. The purpose of this task is to get practice creating and merging feature branches. 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.

All of the students in CSE 391 have recently been hired by FAANG and the frontend team wants to build a staff page that features all of the incredible staff at the company, for this task, you will be adding yourself to that page!

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/21au/faang.git

The purpose of this task is to get practice creating and merging feature branches.

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

Since this repo is shared by so many people, we want to keep the master branch clean, never pushing directly to it, but instead working on a feature branch and eventually opening a merge request on gitlab. First, make sure that your current branch is on master by running

git branch

You should see the branch name master with an asterisk (*) next to it, indicating that master is your current branch.

* master

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

git pull origin master

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/21au/faang
* branch master -> FETCH_HEAD
 6745c4b..6c8d66e master -> origin/master
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 master 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 git username,

that returns an Employee object that represents you. An Employee has a bio, picture and job title. In addition, you should add a photo that represents you to the images/staff directory. It doesn’t need to be an actual photo of you, but something that you feel like represents you! Simply include the name of the file (not including the images/staff prefix) as part of your Employee object. Be sure that Staff.java still compiles after editing!

The front-end team also wants you to add a new product for faang to sell, open Products.java, and add a product to the file. A product object returns the name of the product, a description, a link to an image of the product, and the price of the product. Once you have added your product make sure to put an image of your product in images/products!

Problem 4: 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/21au/faang/tree/YOURNETID_staff_page

Alternatively, you can navigate there by going to the repository main page https://gitlab.cs.washington.edu/cse391/21au/faang 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 5: Make a merge request on Gitlab¶

When you’ve gotten your work in a completed state, you will typically have another teammate review your code before merging your changes in the master branch. In Gitlab, you can create a “merge request”, which allows a teammate to review, comment on and approve your work. Create a merge request for your feature branch in Gitlab. You can do so by selecting “Merge Requests” on the left side-pane (the icon with the arrow), clicking on “New Merge Request” and then selecting your branch in the dropdown under “Select source branch”. Your target branch should be master. Click “Compare branches and continue”. Give your merge request a title without the WIP: prefix and write a description of your changes. Leave the other dropdowns and checkboxes blank and submit your merge request.

Problem 6: Leave a comment on your merge request¶

After creating a merge request and requesting a review from your teammate(s), they can leave comments on your changes. You can leave comments on your own merge requests, as well. Leave at least one comment on a change in your merge request. It can say whatever you’d like.

Problem 7: Merge your branch from gitlab¶

Let’s incorporate your changes into master so it can make it on the main website! The merge request that you created in Gitlab should have a Merge button at the top of the page. Click it. Your changes should now be in master! If the merge button is disabled because your branch has merge conflicts with master, use the resolve conflicts button to resolve the merge conflicts from Gitlab then proceed to merging to master.

Problem 8: Turn In¶

You will submit homework5.sh to gradescope, this file contains one function called print_username in which you will leave the echo command but replace the text 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 netid i.e. mine is “cjobes”).

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

wget https://courses.cs.washington.edu/courses/cse391/21au/homework/hw5/homework5.sh

You should be able to edit this function and submit:

function print_username {
  echo "your gitlab username here"
}

Like last week, this autograder is brand new, we have tested it but if you are experiencing any issues, make sure to post on ed so we can get them resolved.

(Optional) Task 3: For fun!¶

Compile all java files in the repository’s root directory and run the GenerateSite program. This will produce an index.html file containing a list of all of the products our company sells and the staff who work there, as well as an html file 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/master' 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.