lesson_3_reflections.txt

1. When would you want to use a remote repository rather than keeping all your work
local?

    Creating a remote repository allows you to work on files from other computers and allows others to suggest changes.

2. Why might you want to always pull changes manually rather than having Git
automatically stay up-to-date with your remote repository?

    Your remote repository might have changes that you are not ready to share with the public yet, so it is better that
    Git does not automatically stay up to date with your remote repository.

3. Describe the differences between forks, clones, and branches.  When would you
use one instead of another?

    Cloning creates copies of repositories -- either within your local machine or from a remote source (Git Hub) to your local
    machine.  Forks are a type of clone, but they copy someone else's repository that you do not have permission to change, and make
    a clone that you are able to change.  Branches are parts of a repository and thus they can exist withint a clone or fork.

4. What is the benefit of having a copy of the last known state of the remote
stored locally?

   I have to admit, this last section about push, pull, fetch and fast-forward merges was a little bit difficult for me.
   Still, I can answer this question.  Cloning sets up a remote called origin and a local called master.  In addition, there is also a 
   local copy of the last known state/position of the remote.  This is useful so that when you do want to push changes, in case
   there have been other changes from other users or other remote locations, you can compare and contrast these changes before making
   any commits/merges.
   
  Git fetch updates just the local copy of the remote branch and then git log/diff will allow you to see the changes between your local
  copy and the remote.
  
  Git pull origin master  is equivalent to fetching the origin and merging master with the origin/master.

5. How would you collaborate without using Git or GitHub?  What would be easier,
and what would be harder?

    There are somewhat similar simpler mechanisms like collaborating on documents like Googledocs.  Something as old fashioned
    as e-mailing documents iw now unthinkable because it creates many copies of the same file, all slightly different, and it can
    be a nightmare to incorporate all of your changes into one document.  Googledocs is an improvement because it allows multiple users
    to work on one file, but it is more general and does not have all the features for code editting and collaboration that
    Git and GitHub does.  Git is a kind of version control but it adds the functionality of branches and GitHub allows collaboration
    between users with multiple stages of creating/editting/getting feedback and verification that something like GoogleDocs does
    not.  So of course Git/Github is more difficult to learn, but the reward is higher functionality.

6. When would you want to make changes in a separate branch rather than directly in
master?  What benefits does each approach have?

    Making changes in a different branch, especially when working in local vs. remote can be a big hassle.  Thus it's not to be done
    without good reason.  A good reason would be to create an entirely different version of something (aka in another language) or
    to create an experimental feature that may or may not make it into the final edition of something.  The benefit (and additional
    cost) is that you can make significant changes without the fear that your presumably functional master version will get messed up.