-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathlesson_2_reflections.txt
92 lines (71 loc) · 4.73 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
What happens when you initialize a repository? Why do you need to do it?
When you initialise a repository with "git init" it creates a directory ".git",
the file history and commit logs all get stored into this folder.
(The dot infront means it's hidden, so git can do all its things behind the
scenes).
You need to do this in order for git to start tracking changes to files in your
working directory. Note that the initial "git init" command doesn't actually
make a commit for you. This is because
* If it did so automatically you couldn't write a message associated with
the commit
* You may not want to track ALL the files in the directory. For example it
may contain .c files which you want to track, but in addition .o or .exe
files which aren't important to the project (nobody edits these files,
the compiler does it automatically)
How is the staging area different from the working directory and the repository?
What value do you think it offers?
The working directory is just a normal windows/linux directory that has your
project files in it, it's what's there even if you didn't have version control.
The repository contains the history of all the files in the working directory.
This history is stored in a hidden folder .git within the working directory.
The staging area is different to both of these and is basically a list of the
changes you want to record in the next commit. By choosing which changes to
include in a commit it's easier to split the commits into logically distinct
transactions.
For example we may have been working on our website for a while, and after
a couple of hours have 2 files, blog.html and style.css. Everything in blog.html
is related to our latest review of Star Trek fan fiction, where as style.css
has some colour schemes. Even though both have changed since your last commit,
the staging area allows us to include only one in our next commit. That way our
commit messages won't look something like
"Add review of 'Spock in space'. Also change the background from green to blue"
How can you use the staging area to make sure you have one commit per logical
change?
By adding only files that belong to a logical grouping (eg. all files related to
adding colour to a program) to the staging area we can commit only the changes
reflected in those files.
What are some situations when branches would be helpful in keeping your history
organized? How would branches help?
Branches are helpful by labelling specific commits with a useful name, eg. by
creating a branch v1.0 for the first deliverable version of your software. They
can act as milestones basically. By making new branches to test out experimental
code or designs we can still work on our "main" branch, so that if friend's come
over to view what we're doing we can still show them the main program, while we
could have been making drastic changes in the experimental branch that would
make the game not ready to try and play yet.
How do the diagrams help you visualize the branch structure?
Help visualise what has happened in each branch with short commit messages,
where each branch diverge and merge, what part of the history each
branch (label) points to, and what commits are possibly unreachable if you don't
save a new branch. Most importantly we can see the parent of each commit.
What is the result of merging two branches together? Why do we represent it in
the diagram the way we do?
Mergine two branches together results in the currently checked out branch being
updated. It contains all the edits of both branches, which is possible because
git has the history of each branch's file, so it can determine what their
original state was, and what lines were added and deleted from this in the two
branches.
It's good to represent these branches in the diagram because it is easy to see
what commits are the parents of each, which shows what content each commit had
to begin with before making changes. When we merge the branches the git log only
shows commits in chronological order, but there may be many different logical
steps between two branches commited 1 time step apart. Hence this branch diagram
is a way to show the LOGICAL progression of the code, not the chronological.
What are the pros and cons of Git’s automatic merging vs. always doing merges
manually?
Automatically merging different parts of the text file are great because they're
going to be different parts of the code. Manually merging them however makes it
so that the programmer has to understand the conflict changes, eg. do these
pieces of code actually do the same thing or not? This way the programmer can
decide how to combine two different files into one, and makes it less likely
that the code is semantically incorrect.