lesson_3_reflections.txt

When would you want to use a remote repository rather than keeping all your work local?
    
    When working from multiple devices a local repo is not practical, as each device 
    would have its own version of the project, and changes made on one device won't be 
    reflected in all the other devices. In this case having a remote repo that all the
    devices can access solves this problem as the latest commits can be pulled from 
    the remote repo before beginning any edits. Once all the changes are made they can
    be pushed back onto the remote repo, allowing all devices access to these updates.
    The same idea holds not just for a single person working off multiple devices, but 
    many people collaborating together.
    
    
Why might you want to always pull changes manually rather than having Git automatically 
stay up-to-date with your remote repository?

    If git was set up to automatically pull from the remote repo then it would disrupt
    your work flow. While in the middle of implementing new functionality to your code
    somebody else could have pushed their latest changes to the repo. These changes 
    may conflict with your current work - which you're not ready to commit yet - and 
    so you'd have to perform a merge. Performing merges is a pretty complex task, it 
    requires you to understand two different pieces of code and decide if they are 
    compatible. It would be disruptive if you had to do this every time somebody else 
    made a commit while you're in the middle of coding your own contribution to the 
    software, and the problem would only get worse as more people contribute to the 
    project.


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

    Cloning is part of git, it allows you to copy a repository to your local computer.
    Note that the origin from which you are copying may either be remote or just 
    another directory on the same computer. You would use this if the remote repo is 
    not associated with GitHub and you wanted a copy on your own machine.

    Forks are a part of GitHub. They are essentially the GitHub version of cloning, and
    allow you to copy a repo stored on GitHub into your own account. By forking somebody
    else's account, GitHub can track statistics on who and how many users are copying
    a repository. So forks refer to copying from a GitHub repo, to another GitHub repo.
    Note that this could be implemented soley with cloning, by copying somebody's GitHub
    repo onto your own machine, then cloning this local copy to your own GitHub account.
    The downside to this method is that it takes more operations, and the cloned version
    you have stored on GitHub would have no link back to the original repo from which
    you cloned it. You would fork when you want to clone a project from GitHub into 
    your own GitHub account.

    Branches are different file histories within the same repository. They exist in all
    projects where git is used as version control. You would branch whenever you want to
    experiment on some new code, or make changes without breaking the master branch.


What is the benefit of having a copy of the last known state of the remote stored locally?
    
    It let's us know what changes we've made since we last synchronised with the remote
    repo. This makes it easier to fetch the latest changes from the remote as git can
    request just those commits submitted to the remote since a particular version. It 
    also allows us to Fast Forward the merge between origin/master and local/master 
    when no commits have been made to origin since our last fetch.


How would you collaborate without using Git or GitHub? What would be easier, and what 
would be harder?
    
    Last year I worked in a team of 3 for my engineering course that required a large(ish)
    report to be submitted by the end of semester. We collaborated by starting a Facebook
    group page, where we would upload all our documents. As we worked on different sections
    of the report we had many of our own individual documents, which later we had to 
    compile into one - this was more effort than it initially sounds like because all 
    the referencing and bibliography had to be checked after combining everything. This
    typically led to about 5 versions of each of our files named something like
    "my_section v1.doc", "my_section_final.doc" and "my_section_final_v2.doc" and got
    messy, but it worked b/c there were only 3 of us.

    Previously I've also used google docs shared folders to accomplish essentially the 
    same thing. Even though there is google text editor it wasn't sufficient for our
    report, so we had the same issue of having to combine several different .doc files
    into one - along with the multiple versions of the same file problem.

    These two solutions were very easy to implement because my classmates all know how
    to use google drive, drop box, and facebook groups, so there is no barrier or 
    learning curve to overcome. Multiple versions of the same file did become a problem
    though.

    For even smaller group work (groups of 2-3 in labs for example) we typically would
    just email each other, with .zip files of the MATLAB code or current version of 
    the report. This got tedious quite quickly as email conversations got quite long
    just trying to make sure our partner had the latest updates we made.


When would you want to make changes in a separate branch rather than directly in master?
What benefits does each approach have?
    
    Making changes in a separate branch make it easier to collaborate with others on the
    project, however there is a lot more over head compared to just editing the master. 
    For projects where I'm working by myself I would prefer to directly edit the master
    because it's quicker and I don't need to talk to anybody else about what changes I 
    wish to make. Branching is more useful in a collaborative environment. It allows many
    people to edit the same code in different branches, then merge them to master (or 
    submit a pull request), which lets everybody else in the project know what they've
    contributed.