lesson_2_reflections.txt

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

You need to initialize a repository in order to differentiate it from a regular
directory. Git only works with repositories not regular directories. When you 
initialize a repository, you create a hidden .git directory which holds the 
metadata about the history of the directory. When you initialize a repository, 
it has no commits at that point, and any files inside are untracked. 

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

The staging area is different from the working directory in that it allows you 
to store files in a directory without determining all files in that directory 
must be committed. Instead, you can manually add them to the files that should 
be stored in the repository. The staging area is different from the repository 
in that the repository holds the metadata, while the staging area only holds the
files to be committed. It has value in that you could stage a modification when
it improved your code or checkout earlier versions of your repository when it 
didn't work. Then when it all makes sense you can commit to the repository.

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

You can use the git diff --staged command to check what the difference is 
between the latest commit and the files in the staging area. Then you can 
ensure that the changes that you decide to commit strictly correspond to one
logical change only.

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

You might want to use branches when experimenting with features you're not sure
will work. In that case, you could keep a main branch (perhaps a master branch)
and then create a new branch called 'experiment' to try out changes. Branching
would help because you could always update your main/master branch if necessary
while switching back to your experimental features branch. They could later be 
merged if you find that the experimental branch works out. Branches are useful
because they have names which easily distinguish between separate subdivisions
of updates to your code. 

How do the diagrams help you visualize the branch structure?

When you have many branches, diagrams can help you simplify all the text output
from Git messages in the command line, and instead show the branches as a graph.
This can help you see which commits are unreachable from another branch, which
commits are the tips of the branch. When you might eventually want to merge 
different pieces of code, diagrams can help you better understand what needs to
be merged/ignored.

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

Merging two branches results in a new commit that combines the versions from the 
two branches together. The tip of the branch that was checked out at the time of
merging becomes the tip of that branch. It creates a non-linear structure and 
must be represented on diagrams as such. The new merged commit needs to point to 
two parents because it was derived from two branches. 

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

Git's automatic merging speeds up the process of combining two branches so that 
you can work faster compared to doing merges manually. The down-side of Git's 
automatic merging is that it's not sufficiently intelligent to understand 
new functions and changes in the same function - this means you have to manually
merge a lot of files anyway. Another possible down-side is that manually merging
everything requires that you are familiar with the history of the code or the 
code written by collaborators. However, as stated earlier, this does speed up 
the development process.