-
Notifications
You must be signed in to change notification settings - Fork 0
/
lesson_2.txt
80 lines (60 loc) · 4.22 KB
/
lesson_2.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
What happens when you initialize a repository? Why do you need to do it?
When you initialize a repository, you make it available to start tracking
changes to the files contained within. You have to initialize it before
you can start committing changes to the files. You also will not be able
to see any changes, nor be able to view logs of commits - because there
will not be any commits yet.
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 and the repository
because it is a virtual (but still physical) place where the files ready to
be committed are placed so that they are separated visually whenever the user
runs the "git status" command. I think that the value is that the difference
of files shows up visually to the user. This is much like the commit window
of our CVS system that shows which files are being committed to the repository.
How can you use the staging area to make sure you have one commit per logical change?
Well, I guess that you can simply run the "git status" to keep checking to see
what files have been changed, and then what files are in the staging area. Since
it is easy to commit changes, then we should get into the practice of committing
often and then it will be easier to have the changes become more logical changes.
What are some situations when branches would be helpful in keeping your history
organized? How would branches help?
I feel like a situation when branches would be helpful would be if you wanted to
introduce a new feature to a program and yet make sure that you did not affect the
existing master branch. This separation would keep the master branch intact while
you could keep on working on the experimental branch. This separation would also
keep your code more organized by being able to accurately and easily track the
files that changed in your experimental changes.
How do the diagrams help you visualize the branch structure?
The diagrams help you see how different code commits are related to each other. By
drawing the branches, you are able to determine quickly the path that you need to
take in order to checkout and/or merge your new branched code back into the master
branch.
What is the result of merging two branches together? Why do we represent it in the
diagram the way we do?
The result of merging two branches together is one final branch. Usually this is
performed to merge other branches into the master branch so that it can be seen
as a code update into the reliable stable code. The result in the final branch is
attempted to be merged automatically by keeping the changes that are introduced
and only removing the changes that are removed from both branches. It does this
by comparing the differences with the parent commit from whence the branch was
made. We represent it as a drawing so that the idea is solidified in our mind
that two are becoming one. The diagram helps us to see why we can then delete
the old branch now - not because the code doesn't exist, but rather because the
branch is simply now an unreachable label.
What are the pros and cons of Git’s automatic merging vs. always doing merges
manually?
I think that one pro of Git's automatic merging is that when changes are easily
explainable (e.g. The changes both occur in different sections), then there is
no merge conflict generated. This is helpful when there are more than one person
working on a project - both in different sections - and they have to modify the
same file even though they each are working in different sections. One example
would be in our projects where two features are being developed in a web application
and they have to both update the struts-config.xml file. In this case, since both
updates are not conflicting with each other, Git will automatically merge the two
copies of struts-config.xml without generating a merge conflict. If we were using
our older CVS, then a merge conflict would always generate no matter if the code
changes didn't interfere with each other. This is a pro for Git compared with
always having to do merges manually with CVS. I would think that a con is limited
to when Git mistakes and introduces a bug in the code, but I wonder how often this
would actually happen.