Deployed 4239ecf with MkDocs version: 1.2.3

level101/git/branches/index.html

@@ -2151,7 +2151,7 @@
                 
                 
                 <h1 id="working-with-branches">Working With Branches</h1>
-<p>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 <em>branches.</em> 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.</p>
+<p>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 <em>branches</em>. 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.</p>
 <p>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.</p>
 <p>Let's create a branch and see how it looks like:</p>
 <pre><code class="language-bash">$ git branch b1
@@ -2159,14 +2159,14 @@ $ git log --oneline --graph
 * 7f3b00e (HEAD -&gt; master, b1) adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p>We create a branch called <code>b1</code>. Git log tells us that b1 also points to the last commit (7f3b00e) but the <code>HEAD</code> is still pointing to master. If you remember, HEAD points to the commit/reference wherever you are checkout to. So if we checkout to <code>b1</code>, HEAD should point to that. Let's confirm:</p>
+<p>We create a branch called <code>b1</code>. Git log tells us that <code>b1</code> also points to the last commit (<code>7f3b00e</code>) but the <code>HEAD</code> is still pointing to <code>master</code>. If you remember, <code>HEAD</code> points to the commit/reference wherever you are checkout to. So if we checkout to <code>b1</code>, <code>HEAD</code> should point to that. Let's confirm:</p>
 <pre><code class="language-bash">$ git checkout b1
 Switched to branch 'b1'
 $ git log --oneline --graph
 * 7f3b00e (HEAD -&gt; b1, master) adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p><code>b1</code> still points to the same commit but HEAD now points to <code>b1</code>. Since we create a branch at commit <code>7f3b00e</code>, there will be two lines of histories starting this commit. Depending on which branch you are checked out on, the line of history will progress.</p>
+<p><code>b1</code> still points to the same commit but <code>HEAD</code> now points to <code>b1</code>. Since we create a branch at commit <code>7f3b00e</code>, there will be two lines of histories starting this commit. Depending on which branch you are checked out on, the line of history will progress.</p>
 <p>At this moment, we are checked out on branch <code>b1</code>, so making a new commit will advance branch reference <code>b1</code> to that commit and current <code>b1</code> commit will become its parent. Let's do that.</p>
 <pre><code class="language-bash"># Creating a file and making a commit
 $ echo &quot;I am a file in b1 branch&quot; &gt; b1.txt
@@ -2183,7 +2183,7 @@ $ git log --oneline --graph
 * df2fb7a adding file 1
 $
 </code></pre>
-<p>Do note that master is still pointing to the old commit it was pointing to. We can now checkout to master branch and make commits there. This will result in another line of history starting from commit 7f3b00e.</p>
+<p>Do note that master is still pointing to the old commit it was pointing to. We can now checkout to <code>master</code> branch and make commits there. This will result in another line of history starting from commit <code>7f3b00e</code>.</p>
 <pre><code class="language-bash"># checkout to master branch
 $ git checkout master
 Switched to branch 'master'
@@ -2202,7 +2202,7 @@ $ git log --oneline --graph
 * 7f3b00e adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p>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:</p>
+<p>Notice how branch <code>b1</code> is not visible here since we are on the <code>master</code>. Let's try to visualize both to get the whole picture:</p>
 <pre><code class="language-bash">$ git log --oneline --graph --all
 * 60dc441 (HEAD -&gt; master) adding master.txt file
 | * 872a38f (b1) adding b1 file
@@ -2210,10 +2210,10 @@ $ git log --oneline --graph
 * 7f3b00e adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p>Above tree structure should make things clear. Notice a clear branch/fork on commit 7f3b00e. This is how we create branches. Now they both are two separate lines of history on which feature development can be done independently.</p>
+<p>Above tree structure should make things clear. Notice a clear branch/fork on commit <code>7f3b00e</code>. This is how we create branches. Now they both are two separate lines of history on which feature development can be done independently.</p>
 <p><strong>To reiterate, internally, git is just a tree of commits. Branch names (human readable) are pointers to those commits in the tree. We use various git commands to work with the tree structure and references. Git accordingly modifies contents of our repo.</strong></p>
 <h2 id="merges">Merges</h2>
-<p>Now say the feature you were working on branch <code>b1</code> is complete and you need to merge it on master branch, where all the final version of code goes. So first you will checkout to branch master and then you pull the latest code from upstream (eg: GitHub). Then you need to merge your code from <code>b1</code> into master. There could be two ways this can be done.</p>
+<p>Now say the feature you were working on branch <code>b1</code> is complete and you need to merge it on <code>master</code> branch, where all the final version of code goes. So first, you will <code>checkout</code> to branch <code>master</code> and then you <code>pull</code> the latest code from <code>upstream</code> (eg: GitHub). Then you need to merge your code from <code>b1</code> into <code>master</code>. There could be two ways this can be done.</p>
 <p>Here is the current history:</p>
 <pre><code class="language-bash">$ git log --oneline --graph --all
 * 60dc441 (HEAD -&gt; master) adding master.txt file
@@ -2222,7 +2222,7 @@ $ git log --oneline --graph
 * 7f3b00e adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p><strong>Option 1: Directly merge the branch.</strong> Merging the branch b1 into master will result in a new merge commit. This will merge changes from two different lines of history and create a new commit of the result.</p>
+<p><strong>Option 1: Directly merge the branch.</strong> Merging the branch <code>b1</code> into <code>master</code> will result in a new merge commit. This will merge changes from two different lines of history and create a new commit of the result.</p>
 <pre><code class="language-bash">$ git merge b1
 Merge made by the 'recursive' strategy.
 b1.txt | 1 +
@@ -2237,8 +2237,8 @@ $ git log --oneline --graph --all
 * 7f3b00e adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p>You can see a new merge commit created (8fc28f9). You will be prompted for the commit message. If there are a lot of branches in the repo, this result will end-up with a lot of merge commits. Which looks ugly compared to a single line of history of development. So let's look at an alternative approach</p>
-<p>First let's <a href="https://git-scm.com/docs/git-reset">reset</a> our last merge and go to the previous state.</p>
+<p>You can see a new merge commit created (<code>8fc28f9</code>). You will be prompted for the commit message. If there are a lot of branches in the repo, this result will end-up with a lot of merge commits. Which looks ugly compared to a single line of history of development. So let's look at an alternative approach.</p>
+<p>First, let's <a href="https://git-scm.com/docs/git-reset">reset</a> our last merge and go to the previous state.</p>
 <pre><code class="language-bash">$ git reset --hard 60dc441
 HEAD is now at 60dc441 adding master.txt file
 $ git log --oneline --graph --all
@@ -2248,7 +2248,7 @@ $ git log --oneline --graph --all
 * 7f3b00e adding file 2
 * df2fb7a adding file 1
 </code></pre>
-<p><strong>Option 2: Rebase.</strong> Now, instead of merging two branches which has a similar base (commit: 7f3b00e), let us rebase branch b1 on to current master. <strong>What this means is take branch <code>b1</code> (from commit 7f3b00e to commit 872a38f) and rebase (put them on top of) master (60dc441).</strong></p>
+<p><strong>Option 2: Rebase.</strong> Now, instead of merging two branches which has a similar base (commit: <code>7f3b00e</code>), let us rebase branch <code>b1</code> on to current master. <strong>What this means is take branch <code>b1</code> (from commit <code>7f3b00e</code> to commit <code>872a38f</code>) and rebase (put them on top of) master (<code>60dc441</code>).</strong></p>
 <pre><code class="language-bash"># Switch to b1
 $ git checkout b1
 Switched to branch 'b1'