-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathlesson_2_reflections
45 lines (29 loc) · 2.8 KB
/
lesson_2_reflections
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
git init = make a new empty Git repository in current directory (.git)
git status = show info
staging area = add files to this to prepare for commit, can choose what files to commit
git add = adds files to the staging area
git checkout master = returns to most recent commit
git branch = shows current branches
git branch ARGUMENT = create a new branch with that name
git log --graph
git merge master BRANCH = merch BRANCH into master
git show = show changes of a commit compared to its parent
git branch - d BRANCH = delete branch
git checkout --b new_branch
git restet --hard = discards changes in working directory or staging area, if changes have not been committed they are gone
git diff with NO arguments will show changes you haven't added to staging area yet!
git diff --staged = show difference between staging area and repository
What happens when you initialize a repository?
A hidden file is created that will store all your commit information. You need to do this in order to be able to access past commits.
How is the staging area different from the working directory and repository? What value do you think it offers?
The staging area is where you can put which files you want to add to the repository from the working directory. It gives more control, so you're not committing every file every time if you didn't make changes to them.
How can you use the staging area to make sure you have one commit per logical change?
You can view the git diff to double check what you have added/removed. If it isn't quite at a logical change, you can continue to edit.
What are some situations when branches would be helpful in keeping your history organized? How would branches help?
If you are making different versions of a code, you can switch between the codes easily. Also if you are experimenting, you can return to the original quickly by going to the master instead of trying to find the commit ID.
How do the diagrams help you visualize the branch structure?
They allow me to see the parents of the commits and where in the system everything is going (on branches)
What is the result of merging two branches together? Why do we represent it in the diagram in the way we do?
Merging branches will merge all the files and changes. Any code added in will be added, any code that has been deleted since they split will be deleted (compares to the last commit that was exactly the same). We represent it in the diagram like so because it includes all the parents and we can trace the commits back.
What are the pros and cons of Git's automatic merging vs. always doing merges manually?
Git makes merging much faster, but can cause conflicts if two people are editing the same part. If you do it manually, you can work with that person to edit the code together. Git merging is ideal for when you are working on a different part of the code.