-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathlesson_3_reflections.txt
60 lines (49 loc) · 2.89 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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
When would you want to use a remote repository rather than keeping all
your work local?
When I want to use different computers and especially when I want to
collaborate with others!
Why might you want to always pull changes manually rather than having
Git automatically stay up-to-date with your remote repository?
I want to decide myself when to publish something. I still can track
any bugs and try things out on my local machine and as long as I
don't need help from collaborators I don't have to be in sync.
Describe the differences between forks, clones, and branches. When would
you use one instead of another?
branches are labels for a series of commits, they are present on the
remote as well as locally. Clones are made on GitHub or locally and
duplicating a whole repository with all its branches and commits.
Forks are only made within GitHub to work on a repository you are
not allowed to push to.
What is the benefit of having a copy of the last known state of the
remote stored locally?
Without an internet connection I can tell if I am behind or ahead of
the origin (my remote in most cases). So when pulling it's
immeadiately clear if this ... no. It would not be clear if it's
fast forward or not. But. The origin can compare if I have the
latest information about the origin. If other people have changed
something.
At least I always know at which state the public version is.
How would you collaborate without using Git or GitHub? What would be
easier, and what would be harder?
Without using Git(Hub) we would check differences manually I
suppose. Or with other tools like "diff" implemented in bash. I
suppose even with two people -- as we have seen -- there can be
quite a messy situation as they can't always tell if they won't
touch the things the other person is working on atm.
It would be much harder to experiment properly as we always have to
manually make copies and keep track of naming the files and so on.
It would be easier because we would not have to learn about git. But
I believe with the desktop app it's quite easy, although there are
tons of things git is capable of. Many things I don't know of yet.
When would you want to make changes in a separate branch rather than
directly in master? What benefits does each approach have?
When there is a bigger experimental feature, which is new to the
master branch I definitely want to have this in a separate branch...
or don't I? Haven't understood that yet properly.
In our case before we just were not allowed to actually push onto
master. Or do I mix something up?
Separate branches are good for new features, as they have the
benefit of being save to play with, without breaking master. Still
everybody can access master directly.
If there is a very secure change I believe master can be updated
directly.