-
Notifications
You must be signed in to change notification settings - Fork 0
/
lesson_2_reflections.txt
executable file
·28 lines (20 loc) · 2.2 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
What happens when you initialize a repository? Why do you need to do it?
1. you make a "snapshot" of the file system or files in the dir.
2. this is how you tell git to track this directory and its contents.
How is the staging area different from the working directory and the repository? What value do you think it offers?
1. Staging area is the holding place for the files that will be part of the next commit, the working directory is any file that is written to the file system.
2. it allows you to be selective with which files are logically related to eachother even if more files exist in the file system as in, if you added three files but only two are related to each other you can add two with one commit and the other with an additional commit
How can you use the staging area to make sure you have one commit per logical change?
1. you can add just what you need to include in the staging area to the stage and then commit that, then add more to the stage and commit that, and so on.
What are some situations when branches would be helpful in keeping your history organized? How would branches help?
1. If you are making a different version for any reason (i.e. making an easier version of a game, making a different language, or doing some experiments on the code, etc.)
2. You could go off in a new direction with the branch (or many branches) and "merge" the two back later all the while never changing the working version!
Lesson three is all about branches and reachability.
Covered detached head and how to checkout a commit.
Then what happens if a commit is checked out and you make a branch out of it.
What is the result of merging two branches together? Why do we represent it in the diagram the way we do?
1. results is a commit that is the new tip of the master branch (assuming you merge the changes into master)
2. the new tip/head/master branch commit have all the history of both branches
What are the pros and cons of Git’s automatic merging vs. always doing merges manually?
1. If the changes are not complex, meaning, two authors added things that don't seem to conflict because the are seperate, then merge...
The idea to me is have got handle the 'low hanging fruit' freeing the human for more complex tasks