The problem is not to make the right decision; it’s to make the decision right. — attributed to V. Learson by F.P. Brooks, “Quoted Often, Followed Rarely”, Fortune Magazine, 2005

This lab introduces GitHub. If you haven’t already done so, please submit your GitHub ID using the form linked from this week’s guide.

Using GitHub

The distributed configuration management tool we introduce in this course is GitHub, which is based on Git.

We’ll use Git/GitHub both to submit both individual and team assignment code. Git is traditionally used via the command line and these lab materials will present it that way, but you can also use Git GUI tools if you’d like to do so. E.g., WebStorm provides a Git/GitHub plugin (see also GUI Clients).

Cloning Code from GitHub

You’ll be using course-provided code on GitHub.

Do this…

Clone a copy of the course sample code found in https://github.com/kvlinden-courses/cs262-code.

% git clone https://github.com/kvlinden-courses/cs262-code.git
% cd cs262-code

This repo includes useful code for selected class assignments.

Make it a practice of pulling changes from this course repo before you use it to make sure that you have the most recent code. Treat it as read-only.

Pushing Code to GitHub

You’ll also be using GitHub to submit course assignments.

Exercise 3.1

For this exercise, push your Expo applications from the first two labs to new repo(sitory)s on your GitHub account as follows.

  1. On GitHub, create a new private repo under your personal account named cs262, and grant read access to the course instructors and assistants (Do this using SettingsManage accessInvite teams or people; see the Moodle forum for our GitHub IDs). You will submit all lab and homework applications as subdirectories in this repo. Private repos require authentication, which now requires a GitHub personal access token. These tokens are machine-specific and can be saved in IDEs (e.g., Intellij, VSCode) and or command-line tools (e.g., GitBash, Linux).

  2. On your development machine:

    1. Go to your development directory and clone your new (empty) repo into that directory as you did with the class code above. N.b. GitHub will give you the appropriate URL to use (see the green “Code” button).

    2. Copy your completed lab 1 exercise code into a lab01 sub-directory in this new Git repo directory. The structure should look as follows:
      cs262
          .git
          lab01
              my-app
                  .gitignore
                  README.md       (This readme documents the app; Expo creates it automatically.)
                  …
              README.md       (This readme answers the lab questions; you’ll create this one in the next step.)
              screenshot.png
      
          There is no code for labs 2–3; but you will put future assignment sub-directories here, e.g.:
          homework1
          lab04
          …

      Note that a Git repo should generally have only one Git configuration sub-directory at the very root of a repo’s directory structure (i.e., cs262/.git) but that it can have many .gitignore files (e.g., cs262/lab01/.gitignore). The current Expo app creation tool tries to handle all this, but it’s still worth deleting lab01/my-app/.git if it’s there.

    3. Create your lab readme files to fully document each lab with at least the following information, properly formatted using Markdown:

      CS 262 - Lab #

      This lab is based on hyperlink to lab source.

      hacks that I had to make

      Answers to the lab questions:
      • answer #1
    4. From the new cs262 repo directory, add, commit and push your lab code to your new cs262 GitHub repo.
      % git add .
      % git commit -m "a concise, informative commit message"
      % git branch -M main
      % git push origin main
  3. On GitHub:

    • Check to see that you have new code in the repo listed under your account. The readme file should display, properly-formatted, on the bottom of the root page of the repo. node_modules/ should be .git-ignored.

At this point we should both have access to your new repo.

You should now be set up for lab and homework assignment submissions. Remember to submit your GitHub ID so that we can access/grade your submissions (see Guide 3).

Collaborating using GitHub

We’ll also use GitHub for team project code and collaboration.

Exercise 3.2

Your team should do the following.

  1. Designate one team member to go to GitHub and:

    1. Create a new organization and add all team members (and us!) as members with full administrative rights. Name it something appropriate (e.g., calvin-cs262-fall20XX-teamY ).
    2. Create new public repos under this organization:
      • Project — This one holds your project deliverables, e.g., the vision statement you will publish for project 1.
      • Client — This one holds your client application code, e.g., the hello-world prototype you will commit/push for project 1.
      • Service — This one will eventually hold your data service application.

    Here’s an example team organization: https://github.com/calvin-cs262-organization. This organization will hold all your team code and deliverables throughout the semester. You can now begin to collaborate using this organization as a shared resource.

  2. All team members should now do the following:

    1. On their local machines:
      1. Clone all three repos to their local cs262 directory.
      2. Go to the project repo and create a new branch
        % git checkout -b temp/username
      3. In this branch, add a junk text file to the root of the project repo named username.txt. Include a (fun, likely irrelevant) message in the file.
      4. Add the file as a staged Git change by saying:
        % git add newFilename
      5. Commit this change to their local Git branch.
      6. Push their new personal branch to the GitHub repo by saying:
        % git push origin temp/username
    2. On GitHub:

      1. Create a pull request for their new branch by choosing Pull RequestsNew pull request.

    GitHub should now show pull requests from all team members.

  3. Now, a designated team member can go to GitHub, review the pull requests, merge them into main, and verify that the changes from all team members are integrated into the main branch.
  4. Finally, all team members can move back to the main branch on their local machines, pull the changes from GitHub, and verify that all the files have been downloaded locally.

    % git checkout main

Leave the junk files and the test branches out there for a week so that we can confirm that you’ve pushed them; the team should delete them all when lab 3 has been graded.

You’re now in a position to build and push your project 1 (Inception-Vision), hello-world prototype to the client repo.

As with your team Trello board, your GitHub repo(s) should be active throughout the week. Code should be getting written; pull requests made, reviewed and merged; etc. Check out the “Pulse” and the ”Graphs” provided by GitHub for your team repo(s) (see the menu bar on the right). We’ll use these tools to monitor your team progress and participation.

Working with your Team

Running a Sprint Retrospective and Planning Session

Development in Scrum is punctuated by sprint planning and review sessions. In this session we will do the following.

Normally, these planning meetings are separate and each takes time, so we’ll only be able to get you started by hitting the highlights.

Exercise 3.3

Participate actively in your team’s meeting.

Please update your Moodle “Project Teams” entry by adding a hyperlink for your GitHub organization.

Checking in

There is nothing to submit in Moodle for this lab. Push your work to the GitHub repo you identified in the GitHub IDs file given in the guide.