-
Notifications
You must be signed in to change notification settings - Fork 0
/
lesson_3_reflections.txt
36 lines (31 loc) · 2.28 KB
/
lesson_3_reflections.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Q: When would you want to use a remote repository rather than keeping all your work local?
A: There are couple of reasons for keeping a remote repository. First, if you are collaborating on a project, different people may have their own local repositories. In this case, it would make sense to periodically sync to a common remote repository. Second, your local machine might not be very reliable (e.g., infrequent back-ups) in which case you may want to keep a remote repository on a more reliable machine.
Q: Why might you want to always pull changes manually rather than having Git
automatically stay up-to-date with your remote repository?
A: You may not want your commit to be visible in your remote repository in
some cases. One example would be when you are trying something out on an
experimental basis.
Q: Describe the differences between forks, clones, and branches. When would
you use one instead of another?
A: clone is used for copying a repository from one location to another. Fork
is similar to clone except that it is used for cloning a repository from one
user account to another on GitHub. Finally, branch is used within a repository
to create another path of commits for reasons like experimentation.
Q: What is the benefit of having a copy of the last known state of the remote
stored locally?
A: Knowing the last state of a remote repository locally helps in resolving
conflicts when local and remote copies diverge.
Q: How would you collaborate without using Git or GitHub? What would be
easier, and what would be harder?
A: Collaborating without Git or GitHub would be very hard. First, without Git
it would be impossible to keep track of version history. Furthermore, it would
be very hard to handle conflicts.
Q: When would you want to make changes in a separate branch rather than
directly in master? What benefits does each approach have?
A: If I am working on an experimental feature, I would prefer to make changes
in a separate branch. This makes it easier to discard the changes should I
decide not to go ahead with the feature. The downside is the complexity of
doing a merge if others have modified the master branch in the meantime, and I
decide to make the experimental feature mainstream.
The advantage of doing changes in the master branch is that it keeps things
more straight-forward.