-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathlesson_1_reflections.txt
135 lines (88 loc) · 6.11 KB
/
lesson_1_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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
Commands learned (see also: https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf):
- FC (File Compare, in Windows Command Shell): FC java.old java.new
- diff -u (in GitBash): diff -u file.old file.new: Compares file old with file new and shows changes
- git log
- git diff: shows all the changes to files made in the pwd vs. the staging area
- git diff (commit id1) (commit id2)
- git diff --staged: compare staging area to most recent commit
- git --version: determine your current git version
- git clone (URL of repository): copies a repository into the pwd
- git checkout (commit id): 'checks out' the program as is based on the commit id entered
Lesson 2:
- ls -a: shows all files in a folder, including hidden files (starting with a '.')
- git init: initializes/creates new (empty) git repository in the pwd
- git status: shows which files have changed since the last commit (if run right after git init, all files will shown as changed)
- git add: adds files to the staging area before the actual commit
Choosing what changes to commit (example):
****************** ****************** ******************
* PWD * * Staging * * Repository *
* * add to * Area * * *
* * staging area * * Commit * *
* cake.txt * -------> * cake.txt * -------> * cake.txt *
* frosting.txt * -------> * frosting.txt * * frosting.txt *
* chili.txt * * * * *
* * * * * *
* * * * * *
****************** ****************** ******************
- git add (file name): adds speficified file to the staging area
- git commit: commits all files currently in the staging area, opens editor of choice to enter commit message; best practice: http://udacity.github.io/git-styleguide/
- git reset HEAD (file name (of file in staging area)): removes file from staging area
- git reset --hard: discards any changes in the pwd and the staging area (NON-REVERSEABLE!)
- git branch (no args): shows current branches
- git branch (new branch name): creates new branch
- git log --graph --oneline (branch1) (branch2) (etc.): gives visual representation of structure (of branches specified as args)
- git checkout -b [new branch name]: Creates a new branch for the current commit and checks it out at the same time
- git show [commit ID]: Runs 'git diff' on the provided ID against the commit's parent (--> no need to know what the parent actually is,
useful after merging branches)
- git branch -d coins: delets the branch named 'coins' --> doesn't delete commits, only the label
- git remote: lists all remotes that have been created
How to:
- merge two branches/merge branch a into branch b:
1. Check the current branch to be sure branch b (the master branch) is selected (by running 'git branch')
2. Run 'git merge [a] [b]' to create a merged version of the two branches. Name the branch first that will be the master branch
3. Enter commit message for merge commit if wanted
- push a local Git repository to GitHub:
1. Create an empty repository on GitHub
2.
Definitions:
- Commit: Snapshot of every file of your repository at the time you choose to make the commit
- Repository: Multiple files that are tracked together and run together for the program to function properly
- HEAD: Current commit
How did viewing a diff between two versions of a file help you see the bug that was introduced?
Viewing the diff helped me because it showed a succinct version of the differences between
the two files. That means that instead of combing through lines of code, potentially
thousands of them, the program sends an output that becomes much more manageable.
Another advantage of the FC/diff program is that the output can be organized using
attributes.
How could having easy access to the entire history of a file make you a more efficient programmer in the long term?
The ability to access the entire history of a file will minimize room for human error.
What do you think are the pros and cons of manually choosing when to create a commit, like you do in Git,
vs having versions automatically saved, like Google docs does?
The pros: more power and control over when to save. This potentially results in the ideal number of
commits and neither over- nor underpopulates the number of versions saved.
The cons: Manually saving is prone to human error or laziness, thus it can happen that
a) either one forgets to save at an appropriate time and thus work, effort, time, and
money is lost or b) versions aren't documented well enough.
Why do you think some version control systems, like Git, allow saving multiple files in one commit,
while others, like Google Docs, treat each file separately?
Saving multiple files in one commit helps keeping files in order: instead of having to dig through
a large number of interrelated files separately, the system outputs all changes that affected
the file repository. This is particularly useful if writing in code, since a lot of files depend
on other files here. Google Docs does not use this system because Google Docs is not built
with the thought in mind that files would be interdependend.
How can you use the commands git log and git diff to view the history of files?
The 'git log' command lets me see all the different commits that have been made for
a single repository. It lists them in chronological order. Once I know which two
versions or commits I would like to compare, I can use the 'git diff' command
in connection with the commit IDs to see which lines have been added and which
have been removed (use ID of earlier or first version first)
How might using version control make you more confident to make changes that could break something?
It makes it easier to revert to a previous version if need be.
Now that you have your workspace set up, what do you want to try using Git for?
I want to understand how to use it to store my versions of code on Github
Git commands learned:
Lesson 1:
diff (commit1 commit2)
git log
git clone
git checkout