Quiz

1. what version should we be using for the class?

   The CS server (Tempest) has git version 2.39.3 installed. That will be fine.

2. When I checked with git --version, I noticed my git account only shows up when I’ve got a remote SSH connection open. If I’m just using the terminal on my computer, or VSCode without an SHH connection, git --version gives an error. Is it okay to access git through SSH, or should I also install it on my laptop?

   Two answers, one short and one long.

   The short answer: using the server is fine. It's what I assume that most students will do.

   The long answer is that it is possible to do your project work on your own laptop, running node.js on your laptop, connecting to MongoDB from your laptop, and syncing with your partners via Github. Our work with symlinks means that we won't be syncing a ton of built-in Node modules to Github or copying them back and forth from the server. However, that's slightly more cumbersome and so I assume that most students will work on the server.

3. Can we go over what the staging area is and why it's important again? Is the staging area sitting on your computer in an actual folder somewhere or is it more of an analogy?

   For sure! It's a real thing, consisting of list of files that will be operated on when the "git commit" happens. The staging area allows you to think about what it is that you are committing, instead of mindlessly committing every (modified) file every time. A commit should really be a thoughful act.

   It's most important when there are files that you have modified that should *not* be part of the commit. (Maybe you were thinking about some other feature and started implementing it...) If you just committed every modified file, that wouldn't be right.

4. If you have to make changes to files in your staging area, do you have to delete the old version first and then re-add it to the staging area?

   Great question! I don't believe you do. The files to be committed are just listed, and so the moment of the "commit" is when stuff happens. (Unlike, say, attaching a file to an email, where if you modify the file, you have to delete the attachment and attach the updated file.)

5. I know that in GitHub when people are working on different branches and they need to combine them together there can be different conflicts that occur because the code is different, how should those merging conflicts be resolved?

   Merge conflicts are important, but we will reserve those for another day, namely a week from Wednesday.

6. N/A. This reading is fairly manageable.

   Great!