Assignments > Lab 3: A Tour of Git Commands

Credit: This activity was designed by Semmy Purewall

Learning Goals

By the end of this lab, you should be able to:

1. create and use a local Git repository
2. stage, commit, inspect, and compare changes
3. connect a local repository to GitHub and push your work
4. use a branch and pull request to make a small change

Overview

This lab uses one repository: lab03-exercises.

You will create it on your computer first, then connect it to GitHub later in the lab. Git works on your computer without GitHub; GitHub is simply an online home for a Git repository.

You will use one file, README.md, for both project notes and written responses. There is no separate answers.md file.

The programming work in this lab is intentionally small. You already practiced the duplicate-checking problem in Lab 02. Here, you will reuse one of those files so that you can focus on the Git workflow.

Part 1: Create Your Local Repository

1. Open a terminal and move to your csci338 directory. Create a directory for this lab, move into it, and initialize Git:

   mkdir lab03-exercises
   cd lab03-exercises
   git init -b main

   git init turns the current directory into a Git repository. It creates a hidden .git directory where Git stores the repository’s history and settings.

2. List the contents of the directory, including hidden files:

   ls -la

   You should see the hidden .git directory.

3. Create a file named README.md and add the following starter content:

   # Lab 03: Git and GitHub
   
   ## README Responses
   
   ### 1.1 After initialization
   
   ### 1.2 First git status
   
   ### 1.3 After the first commit
   
   ### 1.4 git log
   
   ### 1.5 git diff
   
   Paste the `git status` and `git diff` commands and their output.
   
   How does this `git status` differ from the one in **1.2**?
   
   ### 1.6 Git command reflections
   
   In one or two sentences each, what does each command do?
   
   - `git init`
   - `git status`
   - `git add`
   - `git commit`
   - `git log`
   - `git diff`
   
   ### 1.7 Repository link
   
   ### 1.8 Comparing approaches
   
   In your own words:
   
   - How does the nested-loop approach check for a duplicate?
   - How does the set-based approach check for a duplicate?
   - What is the runtime and memory trade-off of each?
   
   ### 1.9 Pull request merge options
   
   In your own words, what does each GitHub merge option do?
   
   - Create a merge commit
   - Squash and merge
   - Rebase and merge

4. In README.md, under 1.1 After initialization, paste the ls -la command and its output. Use a fenced code block, like this:

   ```text
   ls -la
   ...your output here...
   ```

Part 2: Make Your First Commit

1. Check your repository’s state:

   git status

2. Copy that git status output now, before you change anything else. In README.md, find the heading 1.2 First git status (in the starter outline from Part 1) and paste the command plus that output under it.

3. Stage and commit README.md itself:

   git add README.md
   git commit -m "Create lab README"

4. Run these commands:

   git status
   git log --oneline

   In README.md, under 1.3 After the first commit, paste the git status command and its output. In README.md, under 1.4 git log, paste the git log --oneline command and its output.

   When git status says your working tree is clean, it means Git sees no uncommitted changes.

Part 3: Make and Inspect a Change

1. Add this sentence under the title at the top of README.md:

   This repository documents my practice with 
   local Git, GitHub, branches, and pull requests.

2. Before staging the change, run:

   git status
   git diff

3. In README.md, under 1.5 git diff, paste the git status and git diff commands and their output. Then answer:

   • How does this git status differ from the one in 1.2?

4. Stage and commit the change:

   git add README.md
   git commit -m "Describe repository purpose"

Part 4: Bring Forward One Existing Program

You do not need to solve a new programming problem for this lab. Reuse one completed program from Lab 02:

• ContainsPair.java, or
• contains_pair.py

1. Create either a java-practice or python-practice directory in lab03-exercises, then copy your chosen Lab 02 file into that directory. Use only one language for this lab.

2. Run the program to confirm it still works.

3. Create a .gitignore file at the root of your lab03-exercises folder containing this line:

   *.class

   This prevents Java’s compiled .class files from being committed. It is fine to include this file even if you choose Python.

4. Stage and commit the program and .gitignore file:

   git add .
   git commit -m "Add duplicate-checking practice program"

Part 5: Add Your Reflection

1. In README.md, under 1.6 Git command reflections, answer in one or two sentences each: what do the following git commands do (do not use GenAI for this):

   • git init
   • git status
   • git add
   • git commit
   • git log
   • git diff

2. Commit your reflection:

   git add README.md
   git commit -m "Add Git command reflection"

Part 6: Connect Your Repository to GitHub

Now create an online home for your local repository.

1. On GitHub, create a repository named lab03-exercises.

   • Make it public.
   • Do not initialize it with a README, .gitignore, or license. Your local repository already has those files.

2. After GitHub creates the empty repository, copy the SSH URL shown under push an existing repository from the command line. It will look like this:

   git@github.com:your-github-username/lab03-exercises.git

3. From your local lab03-exercises directory, connect the remote and push your work. Replace your-github-username with your own GitHub username:

   git remote add origin git@github.com:your-github-username/lab03-exercises.git
   git push -u origin main

4. Check the connection:

   git remote -v
   git status

   Reload the repository page on GitHub. You should see your README.md, program file, .gitignore, and commit history.

5. In README.md, under 1.7 Repository link, paste the URL to your public GitHub repository. Commit and push that update:

   git add README.md
   git commit -m "Add repository link"
   git push

Part 7: Make a Change on a Branch

So far, you have committed directly to main. Next, you will make a small improvement on a separate branch.

1. Create and switch to a branch named more-tests:

   git switch -c more-tests

2. Confirm that you are on the new branch:

   git status

3. Make these two changes on more-tests:

   • Add one new test case to the Java or Python program you brought forward from Lab 02.

     • A test case is one additional program input, its expected result, and a way to see whether the actual result matches your expectation.
     • You are adding another call to your existing program, not rewriting its duplicate-checking method or function.

   • In README.md, under 1.8 Comparing approaches, answer:

     • How does the nested-loop approach check for a duplicate?
     • How does the set-based approach check for a duplicate?
     • What is the runtime and memory trade-off of each?

4. Run your program again to verify the new test case. Then commit the changes:

   git add .
   git commit -m "Document duplicate-checking approaches"

5. Compare the branch with main:

   git diff main..more-tests

   Notice that this command shows the changes that exist on more-tests but not on main.

6. Push the new branch to GitHub:

   git push -u origin more-tests

Part 8: Create and Merge a Pull Request

1. On GitHub, open a pull request with:

   • base: main
   • compare: more-tests

2. Write a short pull-request description using Markdown. Include:

   • a bullet list describing your two changes
   • a code block showing the command you used to run your program
   • a link to a relevant resource, such as the Pro Git book – to practice making Markdown links.

3. Before merging, use GitHub’s branch selector to look at both branches and confirm that more-tests contains the changes you expect.

4. Still on the pull request page, click the merge button’s dropdown (do not merge yet). Read GitHub’s descriptions of the three options. Then in README.md, under 1.9 Pull request merge options, answer in your own words: what does each option do (Create a merge commit, Squash and merge, Rebase and merge)?

5. Commit and push that README update to more-tests (this adds a new commit to the open pull request; you still have not merged):

   git add README.md
   git commit -m "Explain pull request merge options"
   git push

6. Back on GitHub, refresh the pull request and confirm the new commit appears. Now merge: choose Rebase and merge. Delete the remote more-tests branch when GitHub offers.

Part 9: Update Your Local Repository

Merging on GitHub does not automatically update the copy on your computer.

1. Fetch information from GitHub:

   git fetch

2. Run git status and git branch. Notice what changed locally and what did not change yet.

3. Switch to main and pull the merged work:

   git switch main
   git pull

4. Delete your local feature branch:

   git branch -d more-tests

5. Run one final check:

   git status
   git log --oneline

   Your local main branch should now include the work that was merged through the pull request.

What to Submit

Submit the link to your merged pull request in Canvas. Before submitting, confirm all of the following: