lesson_2_reflections.txt

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

	When a repository is initialized, using the git init command, an empty repository is created thanks to a .git folder.
	This folder is automatically created and will allow the files tracking. No initial commit is made and the master branch is checked-out by default,
	files are listed as untracked file.
	It is required to start using version control in a project.

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 level between the working directory and the repository where the files ready to be committed are added.
	Repository is a set of committed versions stored and tracked.
	On the contrary the working directory is where you are locally working and could contain also not tracked files.
	Only files currently in staging can be commited.

	The staging area value is the opportunity to commit only those files which are needed to commit as a logical change.


	Useful commands:

		git init             # initialize repository
		git add <file>       # add file from work directory to staging area
		git status           # check Git Status (Gives you a hint of difference between work area, staging area, and repository)
		git reset <file>     # unstaged the file
		git diff             # compare work directory and staging.
		git diff --staged    # compare staging and repository.
		git log --graph --oneline master <branch-name>
		git checkout <branch-name>
		git checkout -b <new-branch-name>   # this is the same as
		                                    #   git branch <new-branch-name>
		                                    #   git checkout <new-branch-name>
		git show              # compare latest commit with parent.
		git show commit_id    # compare with parent.
		git branch -d <branch-name>   # to delete the branch.
		git merge --abort

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

	To make sure you have one commit per logical change you should stage files per logical change.
	Indeed the commit will contain only what is in the staging area.
	Consider the git diff --staged command for comparing staging and repository areas.

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

	Branches can be helpful in such situations when you have to develop and test new features and you don’t want to affect the production code.
	So you can experiment new features on a different branch and merge them into the stable master branch at a later time.

How do the diagrams help you visualize the branch structure?

	Diagrams are a visual aid to show the structure of all the commits and branches (which commit belongs to which branch).
	This is very important for reachability considerations.

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 new commit that combines the two branches together.
	We represent it in the diagram the way we do because this new commit takes the commit history of both branches in a timely order.

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

	The pros for git's automatic merging is that it's a time saver. Indeed commits are automatically merged unless there are changes that conflict.
	On the contrary, the automatic merging is not possible in case of conflicts.
	Git inserts appropriate conflict markers and informs the user but no commit is created.
	In such situations, manually merge is the only reliable option and it is the responsibility of the user the merging operation.