Git Tips for Assignments

Well the first assignment is done. Whew! There were some common git issues that came up, and I hope we can cut back on them by documenting them here.

Learn how to navigate!

The command line is very new to everyone, and I did a lousy job of explaining how to traverse the filesystem from the terminal. I have now posted some instructions that should help with this. Pro tip: in both Windows and Mac, you can open a terminal/git-bash window by right clicking on a location and clicking the “terminal here” or “bash window here” buttons (screenshots anyone?). This should help reduce the amount of time spent hopelessly floundering in the early stages of command-line training.

Don’t commit .DS_Store

Mac users: MacOS creates these annoying files in every directory. They are useless for non-mac users and clutter up the repository. I have taken steps that should stop you from accidentally adding these files to your repository, but if you have already started work on Assignment 1 you may have cloned the repository too early to get the benefits of that work. Here’s how you remove `.DS_Store` files from a repository:

  • first, navigate to the repository root directory in a terminal window
  • then, type the following commands (dark magic!):
find . -name .DS_Store -print0 | xargs -0 git rm -f --cached --ignore-unmatch
echo ".DS_Store" >> .gitignore
git commit -a -m "Git thee behind me, .DS_Store"

For an explanation of these commands, you can look at random posts o n the Internet, ask Stackoverflow, or read the official manuals (at least on MacOS) by typing man find, man xargs, man echo, and man gitignore. A lot of those explanations will be kind of complicated, though, especially the (insanely complicated) find manual.

Note: this command doesn’t actually delete the files - -they will still be there, but git will act as though the files have been deleted, and will not “see” and files named .DS_Store when it looks for untracked files.

Beware package-lock.json

Deprecation notice: you shouldn’t have to follow these instructions. check to make sure that package-lock.json is not present in your web fork. If it is, then something has gone wrong and you should follow these steps.

Unfortunately I rather misunderstood how package-lock.json works (because of outdated documentation). As a result I have removed it from the repository. You should remove it, too. As above, you can do so by navigating to the repository root and typing:

git rm --cached package-lock.json
echo "package-lock.json" >> .gitignore
git commit -a -m "Goodbye, package-lock.json!"

Again, the file package-lock.json will still be on your computer, but git will act as though it had been deleted, and won’t ask you to change it anymore.


I’ve made some late-breaking changes to Assignment 1 to help with these issues. I’ve managed to push those changes to all of your repositories, so please pull in my changes by executing `git pull`. Everything below is DEPRECATED, but I’m keeping the info up here just in case something goes wrong.


You have 2 choices:

  • take the steps described above, then manually update package.json and test/test-node.js as described below
  • take the steps described above, then carefully read the new instructions – which tell you to name your reflection Reflection/ rather than Reflection/ – and ignore the fact that your tests are failing
  • take a chance and do some fancy gitwork as described in the final section, below.

package.json and test/test-node.js have been updated. Be careful!

I’ve updated the tests a little bit to make it easier to run automated tests. My recommendation is as follows:

Pulling changes from Assignment 1 [ADVANCED!]

Alternatively… you can take care of almost all of the above issues by pulling my changes directly from the assignment repository. But, beware! There’s a chance there will be “merge conflicts” and your whole repo will get screwed up. Still, here’s how i would do it:

  • first, make sure all of your changes have been committed with git commit -a -m "emergency commit"
  • Then make a note of the current git commit “hash” by executing git log. The output will look kind of like this:
commit cf369d7a9d7282270a95ab1ff0f8718b84015bfb (HEAD -> development, origin/development)
Merge: bd1c351 734d07c
Author: Matt Price <>
Date:   Thu Jan 18 08:37:22 2018 -0500

    Merge tag 'fix-json' into development

    fix it!

commit 734d07cd1b25ff428d13b802b07741aed470c5cd (tag: fix-json, origin/master, origin/HEAD, master)
Merge: 62423b7 e9c8f65
Author: Matt Price <>
Date:   Wed Jan 17 22:07:30 2018 -0500

    Merge branch 'hotfix/fix-json'

commit e9c8f6507ec13a4c53cff1c35293fc2c70d68f8e
Author: Matt Price <>
Date:   Wed Jan 17 22:05:27 2018 -0500

    remove syntax-breaking comma

    travis build should succeed now

The strange string of numbers and letters is called the “commit hash”. Copy the one at at the top to a safe location. In this example the hash to save would be cf369d7a9d7282270a95ab1ff0f8718b84015bfb.

  • now the dangerous step – pull from my repo and merge into yours! git pull master
  • if there are conflicts, you can either try to fix them, or (my recommendation) completely undo the merge by resetting your repo to the last working state. For this you need that hash you copied a couple of steps ago. This command will completely reset your master branch to the place it was before you tried to merge in my work: git reset --hard cf369d7a9d7282270a95ab1ff0f8718b84015bfb (remember to use YOUR hash, not mine!)

Looking forward to hearing how all of this goes!