lesson_3_reflections.txt

When would you want to use a remote repository rather than keeping all your work
local?

	I will use a remote repository whenever I want to collaborate with other developers and share my work.

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

	Pulling changes manually allows you to avoid conflicts between remote and local repositories.

Describe the differences between forks, clones, and branches.  When would you
use one instead of another?

	Forks are a GitHub feature to create a personal copy of a repository on GitHub to your GitHub account.
	Forks allow you to start working from an existing repository without requiring permissions.
	The original repository will not be changed but it will be linked to the forked one.
	Clone allows you to create a local copy of a remote or a local repository.
	Branches involve non-linear developing and allow you to start a new line of development in your project (e.g. experimental features).

What is the benefit of having a copy of the last known state of the remote
stored locally?

	Using fetch I update my local copy of the remote repository (e.g. inside origin/master).
	The benefit of such operation is that it allows to work on the remote version locally and without conflicting with my own branches.
	Then I can perform calmly the merge locally.

How would you collaborate without using Git or GitHub?  What would be easier,
and what would be harder?

	We could use a cloud service to collaborate without Git or GitHub.
	However this could be feasible only if different developers can work separately on different files.
	It would be harder, indeed, working in parallel on the same files and handling the merge conflicts.
	Not to mention the complication for file tracking and branching.

When would you want to make changes in a separate branch rather than directly in
master?  What benefits does each approach have?

	You should make changes in a separate branch whenever you need to experiment or to develop new feature in your projects.
	You could work directly in master if you work on your own or if you want to release a fast bug fix.
	Working directly on master is much more straightforward. However, when collaborating on GitHub using separate branch is
	very useful to not affect the master, where other people could work on. Furthermore, separate branch can be used for
	code review, commenting proposed changes before finally being accepted and merged into master branch.
	
	
	
Useful commands:

	git remote							# Show all remote locations for the repository
	git remote -v   						# Output the remote locations with verbose information (fetch and push urls)
	git remote add <name of the remote (e.g. origin)> <URL remote>	# Add a new remote location for the current repository
	git push <remote to send changes to> <branch to push> 		# Upload changes to the remote
	git fetch origin  						# Update a local copy of origin/master branch without affecting the local master branch
	git diff master origin/master 					# Examine the differences after git fetch
	git merge origin/master master 					# Merge the changes
	git pull origin master						# = Git fetch origin + git merge master origin/master