Internal review of git course

courses/git/branches.md

@@ -2,7 +2,7 @@
 
 Coming back to our local repo which has two commits. So far, what we have is a single line of history. Commits are chained in a single line. But sometimes you may have a need to work on two different features in parallel in the same repo. Now one option here could be making a new folder/repo with the same code and use that for another feature development. But there's a better way. Use _branches._ Since git follows tree like structure for commits, we can use branches to work on different sets of features. From a commit, two or more branches can be created and branches can also be merged.
 
-Using branches, there can exist multiple lines of histories and we can checkout to any of them and work on it. Checking out, as we discussed earlier, would simply mean replacing contents of the directory (repo) with contents snapshot at the checked out version.
+Using branches, there can exist multiple lines of histories and we can checkout to any of them and work on it. Checking out, as we discussed earlier, would simply mean replacing contents of the directory (repo) with the snapshot at the checked out version.
 
 Let's create a branch and see how it looks like:
 
@@ -66,7 +66,7 @@ spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
 * df2fb7a adding file 1
 ```
 
-Notice how branch b1 is not visible here since we are checkout on master. Let's try to visualize both to get the whole picture:
+Notice how branch b1 is not visible here since we are on the master. Let's try to visualize both to get the whole picture:
 
 ```bash
 spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all

courses/git/git-basics.md

@@ -94,7 +94,7 @@ Notice how after adding the file, git status says `Changes to be committed:`. Wh
 
 ### More About a Commit
 
-Commit is a snapshot of the repo. Whenever a commit is made, a snapshot of the current state of repo (the folder) is taken and saved. Each commit has a unique ID. (`df2fb7a` for the commit we made in the previous step). As we keep adding/changing more and more contents and keep making commits, all those snapshots are stored by git. Again, all this magic happens inside the `.git` folder. This is where all this snapshot or versions are stored. _In an efficient manner._
+Commit is a snapshot of the repo. Whenever a commit is made, a snapshot of the current state of repo (the folder) is taken and saved. Each commit has a unique ID. (`df2fb7a` for the commit we made in the previous step). As we keep adding/changing more and more contents and keep making commits, all those snapshots are stored by git. Again, all this magic happens inside the `.git` folder. This is where all this snapshot or versions are stored _in an efficient manner._
 
 ### Adding More Changes
 
@@ -131,7 +131,7 @@ spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
 
 ### Are commits really linked?
 
-As I just said, the two commits we just made are linked via tree like data structure and we saw how they are linked. But let's actually verify it. Everything in git is an object. Newly created files are stored as an object. Changes to file are stored as an objects and even commits are objects. To view contents of an object we can use the following command with the object's ID. We will take a look at content of the contents of the second commit
+As I just said, the two commits we just made are linked via tree like data structure and we saw how they are linked. But let's actually verify it. Everything in git is an object. Newly created files are stored as an object. Changes to file are stored as an objects and even commits are objects. To view contents of an object we can use the following command with the object's ID. We will take a look at the contents of the second commit
 
 ```bash
 spatel1-mn1:school-of-sre spatel1$ git cat-file -p 7f3b00e
@@ -253,4 +253,4 @@ spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
 * df2fb7a adding file 1
 ```
 
-We just edited the `master` reference file and now we can see only the first commit in git log. Undoing the change to the file brings the state back to original. Not so much of magic, isn't it?
+We just edited the `master` reference file and now we can see only the first commit in git log. Undoing the change to the file brings the state back to original. Not so much of magic, is it?

courses/git/github-hooks.md

@@ -22,7 +22,7 @@ applypatch-msg.sample     fsmonitor-watchman.sample pre-applypatch.sample     pr
 commit-msg.sample         post-update.sample        pre-commit.sample         pre-rebase.sample         prepare-commit-msg.sample
 ```
 
-Names are self explanatory. These hooks are useful when you want to do certain things when a certain event happens. Ie: if you want to run tests before pushing code, you would want to setup `pre-push` hooks. Let's try to create a pre commit hook.
+Names are self explanatory. These hooks are useful when you want to do certain things when a certain event happens. If you want to run tests before pushing code, you would want to setup `pre-push` hooks. Let's try to create a pre commit hook.
 
 ```bash
 spatel1-mn1:school-of-sre spatel1$ echo "echo this is from pre commit hook" > .git/hooks/pre-commit