Lesson 2 Reflections - How to use Git and Github - Udacity

GIT Repositories are different from other repositories that they store a bunch of meta data about the history of repository.

The history is store in the directory called .git, which is hidden.

TIL: Hidden files and directories start with a period, which tells the OS to hide them.

GIT INIT is the command to create a new repository.

When you initialize the repository, Git doesn’t create any commits for you. You’ll have to create the first commit yourself.

GIT STATUS command shows which files have changed since last commit.

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

ANS 1: When I initialise a repository, Git creates a snapshot of that repository. We need to do it, so as to proceed with the tracking of files.

Staging Area is the intermediate step before the commit. Git adds all the files to the statging area, before commit is made. All the files added in the staging area are then compiled as a single commit, when the commit is made.

The files are added via GIT ADD command. All the files which have been added are now tracked.

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

ANS 2: Working directory is the directory where we are working, it lists all the files present in the directory. We might not be working on all the files, or may even need them.
A repository similarily would have different directories, containing different files, we might not be working on all of them.
Staging area gives us the list of all the files, on which work has been done, but the changes are not committed. So we can know, on which files, the work has been going on since the last commit.

git commit and allow you to write a commit message.

    commit message via the command line by running git commit -m "Commit message" instead of just git commit.

As soon as I typed git commit for the first time in the repository, I was prompted to tell about my user.email and user.name; which I did.
It then showed me the various options for git configuration:

Now when I typed git commit, the editor opened in a new window asking me for commit message.

** The standard Git practice is to write a commit message, as if it were a command.

If there would be nothing to commit, then the command git commit would show "nothing to commit, directory is clean".

git diff : compares working directory and staging area

git diff --staged : compares staging area and commit1

git diff coomit1 commit2 : compares two commits

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

ANS 2: We can check how many files are there in the staging area and then do git diff --staged and if there are more than one logical change, then we do different commits by removing the extra files from staging area.

Linear structure for commits is good for fixing bugs, new features and updating documents.

MASTER is the name given to the main branch in most repositories.
    Eevry time a repository is created, it creates a master branch.

Labels for commits are called BRANCHES.

Branches can be checked out. If a branch is checked-out and a new commit is made, the label automatically adjusts to the new commit. The master branch also automatically checks out, without separately checking it out.

Current last commit of the branch is called the TIP of the branch.

Process of combining two commits is called merging.

GIT BRANCH is the command to create a new branch with arguments. Without arguments it shows the branches in the repository currently.

The asterisk mark in front of the master, when git branch command is made means that it is the current branch which has been checked out, ie any change made would reflect in that branch.

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

ANS 3: Situations like, testing a new experiment or an idea. It helps because I can test the new feature, without tinkering with the original codebase. Essentially, it helps me in making a sandbox, wherein I can test. And if it works,I can add it to the main codebase, or discard it.

So MASTER branch basically is the production code, which never breaks and then there is a BRANCH like developmental, where all the experiment is going on.

BRANCHES are good in compartmentalising the work which one is doing. They are like drawers.

You can close one drawer, and open the next one to start working on it.

Good way to wok in case of projects where multiple people are working is to have a new branch for each bug-fix or feature.

REMOTE BRANCH means some one else has created this branch.

git log --graph --oneline master

REACHABILITY : Whether a commit is reachable or not. Move from recent commit to a commit which does not have a parent.

DETACHED HEAD: Checkout a commit, it is detached from a branch, because the commit was checked out and not the branch. Any commit made in this state can be thus discarded without impacting any of the branches.

    git checkout -b new_branch_name

QUE 4: How do the diagrams help you visualize the branch structure?

ANS 4: We can exactly see from where the branches diverged, what is the reachability and if there is any detached head or not. We can see what all different branches are there.

When a commit is created about two merged commits, it stores information about both of its parents. The new tip of the two branches, would be the tip of the master branch. A branch is always MERGED INTO the Master branch.

After the merger, the master branch would inlcude all the all the changes that it had before the merger and the changes of the new merged branch.

Once the merger is completed, we do not need the labels of the merged branch, and they can be deleted, the commits and the history would still be there.

If a branch is deleted and leaves some commits unreachable from existing branches, those commits will continue to be accessible by commit id, until Git’s garbage collection runs. This will happen automatically from time to time, unless you actively turn it off. You can also run this process manually with git gc.

git show shows the difference what changes were made between a commit and its parent, without knowing the parent.

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

ANS 5: Merging two branches creates a commit with changes made by both the branches. We represent it in the diagram like we do, in order to make it easy to understand the merged entities and their commit histories.

 In general, it’s very common that if you make a branch, either an experimental branch or to work on a new feature, you want to periodically merge master into that branch. This is because master usually contains the official version of the code, and it’s common to want experimental changes to include all of the changes to master.

 Merge would create a new commit with multiple parents, the multiple parents would be the current tip of the the merged branches.

 If Master is being merged into a branch, then the merged would create a new commit, with two parents, with tips of the both the branches. Hence the new merged commit would point to both the existing branches as the parents. The label of the branch in which the Master is being merged, would move to the new commit.

 MERGE CONFLICT happens if the same file and same portion of the file has been changed in the two commits being merged.

 ** common ancestors - to practice

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

 ANS 6: Manually merging is tedious but conflicts can be resolved. Automatic merging is easy but there could be errors, which could lead to bad codebase.