Introduction

This lab exercise will familiarize you with some more features of git.

You will need to sign in to https://git-classes.mst.edu and clone the repository for this lab.

Your repository will be named something along the lines of 2017FS-<section>-lab03-<username>1. Make sure to clone with the HTTPS URL (unless you’ve set up SSH keys).

Feel free to consult with your favorite search engine, relevant man pages, the lab instructor and assistants, and your fellow labmates when you need help.

Just make sure that what you turn in is your own work!

Scenario

Jake the Dog created a git repository for the filter program from Lab 2. He wants to collaborate with you to add some features to it.

Problem 1: .gitignorance is bliss

Remember how it’s bad practice to commit generated files to a repository? Well, Jake managed to add a.out anyway. Oops.

  1. Use git rm to delete a.out from the repo.
  2. Check git status to see what this change looks like.
  3. Make a .gitignore file that ignores a.out.
  4. Add your .gitignore to the repository and commit.

Note that your commit in step 4 should commit two changes:

  • Remove a.out
  • Add .gitignore

Problem 2: Peace in the repository

Jake has added another feature: ignoring whitespace at the start of lines. Now, your program can filter lines that contain whitespace (tabs and spaces) before a #.

Jake is very busy at the moment, so you’ll have to help him merge his feature into master:

  • Use git checkout to check out Jake’s branch (named whitespace).
  • Use git diff master to see exactly what Jake changed in filter.cpp.
  • Jake’s code looks pretty good! Now let’s merge his changes into the master branch.
    1. First, use git checkout to check out the master branch.
    2. Run git merge whitespace to merge Jake’s branch into the current branch (master).
    3. Oh no! There’s a merge conflict!
      • Use git status to find out which file is causing the conflict.
      • Open that file with your editor and fix the code, so that it works correctly.
    4. Stage your fixes with git add and commit them with git commit.

Problem 3: Features grow on branches

Okay, so now you’ve got the repository cleaned up!

  1. You removed that pesky a.out.
  2. You merged Jake’s work into the master branch.

Jake wants you to add a new feature to the filter program. Instead of hard-coding the comment character as #, he would like to be able to specify the comment character on the command line.

He wants to be able to do something like….

cat story.txt | filter %

… to filter lines that start with a %.

  1. Make a new branch to develop your feature on.
  2. Modify filter.cpp, so that it behaves as described. Stage your changes, then commit. (Too easy? Try using getopt()!)
    • You’re welcome to make several commits, but you need at least one.
  3. Push your new branch to the remote repository (i.e., Gitlab).
    • The first time you push a new branch, you have to tell git to make a new branch on the remote. When you run git push, it will tell you the right command to run.
    • Check the Gitlab website to make sure your branch is up there.

Alrighty! Now that your new feature is done, let’s merge it into master.

  1. Do that – Merge it into master.
  2. Push your commits to GitLab.

Problem 4: Paradox-free time travel

Jake realized that he deleted a section of the header documentation from filter.cpp!

  1. Figure out which commit deleted the documentation.
  2. Use git revert to undo that mistake!
  3. Make sure to push your revert to the remote repo.

Epilogue: Submitting

Your repo on gitlab is your submission, so whatever is up there is what we will grade. Make sure you’ve pushed both your feature branch and master. You can double-check on the Gitlab website to make sure your submission looks the way you want it to.

We expect to see the following files on the master branch:

  • README.md
  • .gitignore
  • filter.cpp

Hints

  • Use git help <command> to learn more about a command.
    • For example, git help commit to learn about git commit
  • Use GitLab’s Network view (under the Repository tab) to see a pretty graph of your commit history. You’ll also see your branch names and their corresponding commits there.
  1. … where <section> is your section (a or b) and <username> is your username.