Generally lesson 2 is centered around creating and modifying a Git Repo.
Major concepts (I think) that were touched on in this lesson included:
Here are my reflections from this lesson.
As seen from [a] previous command I ran in the Shell terminal, initializing a folder (read: repo) using the git init command adds the necessary .git files into that folder which enables git to start tracking the folder for changes.
Regarding why this HAS to be done, I think my previous paragraph answered this question in part – so that git can start tracking the repo!
The staging area (SA) is different from the working directory (WD) in the sense that files which are placed in the SA are considered ready for “commitment”.
The value of having a SA is cleary apparent when you consider the fact that sometimes, not all files present in the WD maybe be finished up and ready for committing. Hence only files ready to be committed can be moved into the SA and be, eventually, committed.
Shit! My grammar is all messed up.
For every “logical change” you’ve made to the project, add all files which were involved in effecting that change to the SA, and commit them all at once.
When you want to test out/add new features, I guess?
Diagrams drawn of the commit history (git log) helps trace and place each commit in the appropriate branch so that in visualizing the whole project’s commit history, there’s a “big picture”.
The result of merging two branches is … one. unified. branch… containing all of the changes from both merged branch – that is, of course, if there were no merge conflicts during the course of automatic merging.
I’d say the representation in ‘the diagram’, apart from the ‘helping one to visualize’ part, is done in that way to show at exactly what point on the master branch, or whichever branch is checked out during the merge, the merge was initiated.
I, honestly, do not know exactly what is meant by manual merging, but if by that you mean manually comparing two versions of the same file to check for any differences and eventually combining them into one single file to ‘represent’ them both, then, here goes …
For one, git’s auto-merge feature eliminates the tedious and rather mundane task of having to check various versions of similar file only to find and merge the retlatively few lines which would need merging. That’s a huge PRO.
The con here would have to be the fact that auto merging would occassionally merge what, logically, may not be meant to be merged. But that’s where the concept of having ‘Merge conflicts’ help, I think. So, this con may have already been conquered. Pun intended :)