-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathlesson_2_reflections.txt
101 lines (79 loc) · 4.48 KB
/
lesson_2_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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
What happens when you initialize a repository? Why do you need to do it?------
When initializing a repository it gives the computer the 'go' to track changes
in the files that you are planning on using.
It is important because it starts to track changes and allows you to write
messages for the commits you plan to make.
How is the staging area different from the working directory and the
repository? What value do you think it offers?
The staging area is different from the working directory because it is
holding the files that you are using in the working directory but before you
have commit them to repository (which is filled with your 'final or 'updated'
drafts). Staging area is different from repository because files in the
staging area are not finalized and saved in their current form - so they are
still relatively flexible. Files in the repository are in their most updated
or final forms - will no flexibility unless you open them, make changes, store
them in the staging area, and then commit them.
It offers the chance for developers to make sure that they are commit'ing the
right files. It also allows them to see which files they have open - which
can be useful if you are working on multiple projects at the same time.
How can you use the staging area to make sure you have one commit per
logical change?
You can use the staging area to see which files are ready to be committed
and use the diff function to see what the changes are between the latest
commit and the one in the staging area.
What are some situations when branches would be helpful in keeping your
history organized? How would branches help?
Branhces would be helpful if I wanted to work on various prototypes of a
webpage for a client (to give them color/UX designs), if I want to make
various versions of a game (hard/average/easy), or if I wanted to create
different types of the same webpage for potential compliance issues
(such as language, readability, etc).
Branches would help in this case because it would allow me to work on a
seperate file repository without worrying that I would be changing the
master set. In addition, by having a separate branch I could feel that I
can make mistakes without feeling that my work is 'precious' since I would
working away from the master respository. Branches also could help, which
I know is coming later, with collaboration since everyone could be working
from the same foundation of files but working on different aspects of the
major project (subpages, making a site responsive, adding different
functionalities or interative graphics to a site, etc).
How do the diagrams help you visualize the branch structure?
The diagrams visually demonstrate the idea of a "HEAD" and how the commits
trace back to the initial commit. It also explains how a commit can be 'lost'
if it is not tied to a branch head and how working on a separate branch, if
good, would need to be merged with the master branch since it is not always
using the most updated versions of the respository.
What is the result of merging two branches together? Why do we represent it
in the diagraph the way we do?
When you merge two branches together it combines their code and links their
commit lineages into one so that the history is cleaner and doesn't require
knowing the names of two separate heads.
We represent merges in our fashion because it shows that the commits that
are linked via the old HEAD are not lost. Also, it shows which two HEADS
are combined into each other.
What are the pros and cons of Git's automatic merging vs. always doing merges
manually?
Automatic Merging:
Pros
Finds the places where two files are in conflict
Merges a significant amount of code without errors
Allows you to be in control of which branch is being into another
Cons
You have to tell the computer when to merge
It may say that there are conflicts in the code when in reality
there may not, which takes time to manuever the code so it is
permissible to Git
Manual Merging
Pros
You have a clear idea if conflicts exist so you won't stop
yourself from merging or fixing code for aesthetic purposes
You can see the two files that you are looking to merge since you
will be copy and pasting
You have a clear idea of the timeline of your merging process
Cons:
There is a significant potential for error by only manually
merging
Would take up a lot of time to merge files if the coding is
hundreds of lines long
You may not be conscious of potential errors or conflicts
in the coding that a computer could find quickly