lesson_2_reflections.txt

What happens when you initialize a repository? Why do you need to do it?
   
   Git creates a hidden directory for tracking changes inside that directory but does not commit any files
   that are already there. You need to do it in order for git to initialize the history for that directory.

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 area that stands between the working directory and the repository, allowing
   you to decide and make a logical bundle which contains the files from your working directory you 
   will commit to the repository in the next stage.

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

   The staging area allows us to see what the current commit is composed of, so you can review the files 
   that will be commited and the changes they have against the last commit in the repository using the
   command git diff --staged.

What are some situations when branches would be helpful in keeping your history organized? How would branches help?

   When you'd like to experiment something new but don't want to break your main branch. 
   Or when you want to have a different version with some changes in your code but want to keep your
   main development clean.

How do the diagrams help you visualize the branch structure?

   It helps to show each commits father, thus showing you if there are any nodes that aren't reachable
   from any of the branches. It also helps you see from which node each branch was created and how far 
   ahead each branch tip is in the history.

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

   The result is in unifying the code from the las two commits from both merged branches, creating a 
   new node from which you can access all the commits from both branches, this is due to the new node 
   having two parents (both tips from the merged branches). The merged histories will be interleaved 
   by the timestamp from each commit, but each commit parent will still be the same as before the merge.
   We represent it that way cause its easier to see and understand the history of changes and see each
   commits parent.

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

   Pros: time saving.
   Cons: can brake your code, it uses simple heuristics to do the merge, can't know if what is merging
   is correct according to the coders logic.