lesson_2_reflections.txt

What happens when you create a repository?  Why do you need to do it?

    When I create a repository, Git creates a directory vhere it will keep track
    of all the versions that I save.  Creating the repository also lets Git know
    that I want all the files in this directory to be tracked together, but
    separately from files in different directories.  If I didn't create the
    repository, Git could create the directory to save the versions in
    automatically, but it wouldn't know which files I wanted to track together
    and which I wanted to track separately.

How is the staging area different from the working directory and the repository?
What value do you think it offers?

    The staging area is an intermediate area where I can add changes before
    committing them to the repository.  This allows me to add changes to the
    staging area one-by-one, then commit them all at once, which makes it easier
    to specify what changes should go into each commit.  That makes the commits
    more valuable, since the commit history is easier to navigate when I create
    one commit per logical change.

How can you use the staging area to make sure you have one commit per logical
change?

    If I've made more than one logical change since committing, I can add all
    the changes affected by the first logical change to the staging area, then
    commit those without committing the others.

When would you want to create a new branch, and when would you not?

    I like to use master as a stable version of my code and create a new branch
    when I'm planning on working on something experimental, or that will be
    non-stable for a little while.  That makes it easier to switch back to the
    stable version whenever I need to.  This is particularly helpful when I am
    working with other developers, since the other developers can trust that
    master is stable.  They can always check out my branch if they are
    interested in my experimental changes.

    When I'm working on my own, and I make a change that I do not expect to
    break anything, I frequently don't bother to make another branch.  However,
    making a new branch in Git is so fast and easy that there is really no bad
    time to make a branch, unless I make so many that I cannot keep track of
    them all.

How do the diagrams help you visualize these changes?

    The diagrams show what the parent of each commit is.  When there are
    multiple branches, I can use the diagrams to easily see what changes will be
    part of each branch.  They also let me easily see what commit each branch
    refers to.

What is the result of merging two branches together?  Why do we represent it in
the diagram the way we do?

    The result of merging two branches together is a combined commit with all
    the changes from both branches.  We represent the merge in the diagram as
    having two parents - the two commits that it combined.  For non-merge
    commits, the parent of the commit is the state of the files before that
    commit was made.  For merge commits, there was no one state of the files
    before the commit was made, since the merge commit combines two commits
    together, so it makes sense for the merge commit to have two parents.

What are the pros and cons of Git’s automatic merging vs. always doing merges
manually?

    Git's automatic merging can save the user a lot of time!  Especially when
    multiple people are working together, merging everything manually could be
    very painful.

    The downside of automatic merging is that it's not perfect.  Merging the
    coins branch with the master branch, which included color, resulted in
    inconsistent visuals, where most items were colored but the coins were not.
    Git could even make worse mistakes - for example, if one branch deleted a
    function, and another branch added a call to that function, Git would merge
    those together with no conflict and the resulting code would be broken.

    Overall, Git's merging can save a lot of time, but it's important to always
    double check that the code still works after doing a merge.