lesson_3_reflections.txt

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

I would use a remote when I want the repository to be accessible by other users, either
for use or for collaboration. I would also use one if I'll need to access the repository
myself from more than one computer.

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

If I am not the only person pushing changes to the remote, then it may change at unpredictable
times and in unpredictable ways. If those changes were suddenly applied to my working directory
without warning, they would at best startle me and at worst completely break my own project. I
should choose to pull only at times when I'm ready to understand and deal with what has changed
in the remote when I wasn't looking.

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

A branch is a single series of changes within a single repository, which is (maybe temporarily)
independent of any other series. I would make a new branch when the repository may need to have
unrelated changes committed simultaneously, and I want to choose the time in the future that those
series will be merged together. A clone is a new copy of a repository, complete with change
history, either within one Git installation or between two different installations. In the latter
case, one may be linked to the other as a remote so they can stay synchronized, but otherwise they
are independent. I would make a clone usually when I want to do local work on my own remote
repository. A fork is a clone, but specifically one that is meant to be an independent
continuation of and/or departure from the original. Forks are a special feature of GitHub,
and GitHub will link a new fork back to the original repository as a remote. I would make a fork
whenever I want to do my own work on someone else's public repository.

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

Git can always tell me how my HEAD relates to last known state of the remote, whether I've
committed new changes and am ahead of it, or I've checked out an older commit and I'm behind it.
It can even do this when it can't connect to the remote, or when I'm not ready to deal with a new
pull. Also, when I finally do a pull or push, and Git needs to check for conflicts, it knows that
it can save time by ignoring any older commits to the remote that it already knew about.

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

Obviously I could collaborate using a different multi-user source control system, and the
differences would depend on which one. I could use Git, but not GitHub, which would be harder
because I would have to administer a server myself and I wouldn't have all of GitHub's online
tools; on the other hand, I could customize the server to taste, keep it secure on a LAN,
private for free, etc. I could just use emailed text and files, either person-to-person or with a
listserv. This would require none of the infrastructure of Git or GitHub, but it would create a
ton of tedious chores for each collaborator to keep their working set up-to-date. Finally, I could
use one central fileset shared over a network, but this would completely suck. There would be no
history tracking, branching and merging would be a giant headache, and a lack of concurrent access
to each file would be constantly putting the brakes on people actually working together.

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

One situation would be when I don't have permission to change master directly, or it would be rude
to do so without consulting other collaborators. In such a case, using branches and pull requests
allows the team to reach consensus that the changes are master-ready before they affect anyone but
me. Another is when the changes I want to make are too large, complex, or experimental to put off
committing until I'm fully confident in them. If I commit often, but I don't use a separate branch,
then master will be frequently broken; master should ideally never be broken.