lesson_2_reflections.txt

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

When we initialize a repository, Git makes the .git directory in that 
folder and sets it up to track the changes however, it doesn't track 
changes just yet. So, at initialized state repository is set up. We have 
to do the commits to the repository later on. Git doesn't do any commits 
during the initialization because firstly, we might not want to track 
all the files and secondly we won't have an opportunity to add our 
comments to the commit. We need to initialize the repository to create 
it and to let git know that we would like git to set it up for tracking 
changes.

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

We can add files from working directory to staging area and change the 
files before committing them into the repository. We can have many 
untracked files in the working directory, in staging area we will only 
have tracked files and in the repository only committed files will be 
present. It gives us an opportunity to make sure that the commit we are 
about to make does indeed contains a logical commit and also it lets us 
commit only relevant file to the repository.


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

We can use 'git diff' to compare the changes between staging area and 
working directory to see all changes we have made. Then we can add the 
files related to a logical change into the staging area. Then we can git 
diff --staged to compare changes with the last commit. This will ensure 
that we are only going to commit one logical change. Once we are sure we 
can git commit to commit that logical change.

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

Branches are really helpful when we want to experiment with the main 
program. Perhaps, we want to test a new feature, or want to add a 
translation or we want make a simpler versin of program. In such 
scenarios, we want to keep and maintain a working version for the 
current users while the feature(s) is being worked upon. The main 
program and branched instance can go on in a different direction. If any 
bug is found it can be fixed in master branch. Once the feature is 
complete the branches can be merged again.

How do the diagrams help you visualize the branch structure?

Diagrams can help you tracing back to the start of the node where a branch was spawned at. It can also help you visualise what commits from master would are / aren't included in a particular branch. It can also help you to find out if a particular node is unreachable.

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

Merging two branches merge the changes from one branch to the other one so that the two branches become one from there onwards. The branches are
represented like this to keep track of the changes and it also helps us to get the id of the checkouts.

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

Git's automatic merging, merges the commits as long as there are no
conflicts this simplify the task of merging to a some extent and it only 
involves the person when there is a conflict so that correct decision is 
made. If the merges are always done manually then the task of merging 
becomes a tedious task to compare all the changes manually. It will take 
longer though the conflicts will be readlity handled by the person.

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

It is more safe to pull changes manually rather than doing it 
automatically. Staying up-to-date will sometimes create conflicts which 
might need collaboration before the changes are incorporated in local 
repository. That might lead to lost time in what you are doing.