lesson_2_reflections.txt

What happens when you initialize a repository? Why do you need to do it?

AH! I did not know that "init" stood for initialize. Makes much sense now. I guess when you initialize a repo, your directory is not just a refular directory but a directory that will now be tracked with changes using git. VERSION CONTROL. META DATA! If you want to sound cool.

How is the staging area different from the working directory and the repository? What value do you think it offers?

Well I guess it is like the middle stage or step between the working directory and repository. The difference between working directory and repo is getting clear to me. I am assuming that repo holds what is not to be change for now and the working directory holds what you are working on currently. And when we are doing or is on the statging areaa, we are staging or getting ready to decide what we want to put in the repo or in the terms of this course, "commit to the repo". Is that correct? I thinks so.

 How can you use the staging area to make sure you have one commit per logical change?

 Well you can check or compare what you have on the staging area to your recent commit or working directory. This would be good practice because sometimes you might not want to commit things that are the same or even mistakes.

 What are some situations when branches would be helpful in keeping your history organized? How would branches help?

 Like they had explained, branches would be very helpful when you want to try other things with your code. Like adding a whole new thing that you are not sure it might work but just want to do some experiment with it. Or make a version of your code which is a game in a different language. If we change the whole code without having branches it would be time consuming and tedious to just copy a whole directory and work on that. Branches help with those problems.

 How do the diagrams help you visualize the branch structure?

 It helps to see where things are seperated. It also helps seeing how branches of what your working don't interfere with each other. It is also good to picture how commits are not mumble jumbled together. Because after commits here and commits there it gets hard to organize and picture it. But since we now see see through diagrams, it is nice to have an understanding how it works.

 What is the result of merging two branches together? Why do we represent it in the diagram the way we do?

 The result is onr branch but with changes from both brances. Again it is nice to see it on a diagram. We can see the branches that are not the master branch and we can see what is the master branch. Good visual!

 What are the pros and cons of Git’s automatic merging vs. always doing merges manually?

 Oh wait, there automatic merging? I'm confused. Oh okay, so like merging like not Git. Okay. So Git's automatic merging seems very helpful. It always warns you if there is conflict. I am scared to merge now because I did a mistake on merging master and easy-mode. I was suppose to checkout easy-mode branch first then do the "git merge master easy-mode" command. I guess if done manually, it would be time consuming on a big project.