mirror of
https://github.com/linkedin/school-of-sre
synced 2026-01-08 17:48:02 +00:00
Deployed a605e72 with MkDocs version: 1.1.2
This commit is contained in:
@@ -1171,59 +1171,59 @@
|
||||
<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">spatel1-mn1:school-of-sre spatel1$ git branch b1
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
<pre><code class="language-bash">$ git branch b1
|
||||
$ git log --oneline --graph
|
||||
* 7f3b00e (HEAD -> 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>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git checkout b1
|
||||
<pre><code class="language-bash">$ git checkout b1
|
||||
Switched to branch 'b1'
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
$ git log --oneline --graph
|
||||
* 7f3b00e (HEAD -> 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>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
|
||||
spatel1-mn1:school-of-sre spatel1$ echo "I am a file in b1 branch" > b1.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git add b1.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git commit -m "adding b1 file"
|
||||
$ echo "I am a file in b1 branch" > b1.txt
|
||||
$ git add b1.txt
|
||||
$ git commit -m "adding b1 file"
|
||||
[b1 872a38f] adding b1 file
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 b1.txt
|
||||
|
||||
# The new line of history
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
$ git log --oneline --graph
|
||||
* 872a38f (HEAD -> b1) adding b1 file
|
||||
* 7f3b00e (master) adding file 2
|
||||
* df2fb7a adding file 1
|
||||
spatel1-mn1:school-of-sre spatel1$
|
||||
$
|
||||
</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>
|
||||
<pre><code class="language-bash"># checkout to master branch
|
||||
spatel1-mn1:school-of-sre spatel1$ git checkout master
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
|
||||
# Creating a new commit on master branch
|
||||
spatel1-mn1:school-of-sre spatel1$ echo "new file in master branch" > master.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git add master.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git commit -m "adding master.txt file"
|
||||
$ echo "new file in master branch" > master.txt
|
||||
$ git add master.txt
|
||||
$ git commit -m "adding master.txt file"
|
||||
[master 60dc441] adding master.txt file
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 master.txt
|
||||
|
||||
# The history line
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
$ git log --oneline --graph
|
||||
* 60dc441 (HEAD -> master) adding master.txt file
|
||||
* 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>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
<pre><code class="language-bash">$ git log --oneline --graph --all
|
||||
* 60dc441 (HEAD -> master) adding master.txt file
|
||||
| * 872a38f (b1) adding b1 file
|
||||
|/
|
||||
|/
|
||||
* 7f3b00e adding file 2
|
||||
* df2fb7a adding file 1
|
||||
</code></pre>
|
||||
@@ -1232,51 +1232,51 @@ spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
<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>Here is the current history:</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
<pre><code class="language-bash">$ git log --oneline --graph --all
|
||||
* 60dc441 (HEAD -> master) adding master.txt file
|
||||
| * 872a38f (b1) adding b1 file
|
||||
|/
|
||||
|/
|
||||
* 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>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git merge b1
|
||||
<pre><code class="language-bash">$ git merge b1
|
||||
Merge made by the 'recursive' strategy.
|
||||
b1.txt | 1 +
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 b1.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
$ git log --oneline --graph --all
|
||||
* 8fc28f9 (HEAD -> master) Merge branch 'b1'
|
||||
|\
|
||||
| * 872a38f (b1) adding b1 file
|
||||
* | 60dc441 adding master.txt file
|
||||
|/
|
||||
|/
|
||||
* 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>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git reset --hard 60dc441
|
||||
<pre><code class="language-bash">$ git reset --hard 60dc441
|
||||
HEAD is now at 60dc441 adding master.txt file
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
$ git log --oneline --graph --all
|
||||
* 60dc441 (HEAD -> master) adding master.txt file
|
||||
| * 872a38f (b1) adding b1 file
|
||||
|/
|
||||
|/
|
||||
* 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>
|
||||
<pre><code class="language-bash"># Switch to b1
|
||||
spatel1-mn1:school-of-sre spatel1$ git checkout b1
|
||||
$ git checkout b1
|
||||
Switched to branch 'b1'
|
||||
|
||||
# Rebase (b1 which is current branch) on master
|
||||
spatel1-mn1:school-of-sre spatel1$ git rebase master
|
||||
$ git rebase master
|
||||
First, rewinding head to replay your work on top of it...
|
||||
Applying: adding b1 file
|
||||
|
||||
# The result
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
$ git log --oneline --graph --all
|
||||
* 5372c8f (HEAD -> b1) adding b1 file
|
||||
* 60dc441 (master) adding master.txt file
|
||||
* 7f3b00e adding file 2
|
||||
@@ -1284,11 +1284,11 @@ spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
</code></pre>
|
||||
<p>You can see <code>b1</code> which had 1 commit. That commit's parent was <code>7f3b00e</code>. But since we rebase it on master (<code>60dc441</code>). That becomes the parent now. As a side effect, you also see it has become a single line of history. Now if we were to merge <code>b1</code> into <code>master</code>, it would simply mean change <code>master</code> to point to <code>5372c8f</code> which is <code>b1</code>. Let's try it:</p>
|
||||
<pre><code class="language-bash"># checkout to master since we want to merge code into master
|
||||
spatel1-mn1:school-of-sre spatel1$ git checkout master
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
|
||||
# the current history, where b1 is based on master
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
$ git log --oneline --graph --all
|
||||
* 5372c8f (b1) adding b1 file
|
||||
* 60dc441 (HEAD -> master) adding master.txt file
|
||||
* 7f3b00e adding file 2
|
||||
@@ -1296,7 +1296,7 @@ spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
|
||||
|
||||
# Performing the merge, notice the "fast-forward" message
|
||||
spatel1-mn1:school-of-sre spatel1$ git merge b1
|
||||
$ git merge b1
|
||||
Updating 60dc441..5372c8f
|
||||
Fast-forward
|
||||
b1.txt | 1 +
|
||||
@@ -1304,7 +1304,7 @@ b1.txt | 1 +
|
||||
create mode 100644 b1.txt
|
||||
|
||||
# The Result
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph --all
|
||||
$ git log --oneline --graph --all
|
||||
* 5372c8f (HEAD -> master, b1) adding b1 file
|
||||
* 60dc441 adding master.txt file
|
||||
* 7f3b00e adding file 2
|
||||
|
||||
@@ -1388,23 +1388,23 @@
|
||||
<h3 id="creating-a-git-repo">Creating a Git Repo</h3>
|
||||
<p>Any folder can be converted into a git repository. After executing the following command, we will see a <code>.git</code> folder within the folder, which makes our folder a git repository. <strong>All the magic that git does, <code>.git</code> folder is the enabler for the same.</strong></p>
|
||||
<pre><code class="language-bash"># creating an empty folder and changing current dir to it
|
||||
spatel1-mn1:~ spatel1$ cd /tmp
|
||||
spatel1-mn1:tmp spatel1$ mkdir school-of-sre
|
||||
spatel1-mn1:tmp spatel1$ cd school-of-sre/
|
||||
$ cd /tmp
|
||||
$ mkdir school-of-sre
|
||||
$ cd school-of-sre/
|
||||
|
||||
# initialize a git repo
|
||||
spatel1-mn1:school-of-sre spatel1$ git init
|
||||
$ git init
|
||||
Initialized empty Git repository in /private/tmp/school-of-sre/.git/
|
||||
</code></pre>
|
||||
<p>As the output says, an empty git repo has been initialized in our folder. Let's take a look at what is there.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ ls .git/
|
||||
<pre><code class="language-bash">$ ls .git/
|
||||
HEAD config description hooks info objects refs
|
||||
</code></pre>
|
||||
<p>There are a bunch of folders and files in the <code>.git</code> folder. As I said, all these enables git to do its magic. We will look into some of these folders and files. But for now, what we have is an empty git repository.</p>
|
||||
<h3 id="tracking-a-file">Tracking a File</h3>
|
||||
<p>Now as you might already know, let us create a new file in our repo (we will refer to the folder as <em>repo</em> now.) And see git status</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ echo "I am file 1" > file1.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git status
|
||||
<pre><code class="language-bash">$ echo "I am file 1" > file1.txt
|
||||
$ git status
|
||||
On branch master
|
||||
|
||||
No commits yet
|
||||
@@ -1417,8 +1417,8 @@ Untracked files:
|
||||
nothing added to commit but untracked files present (use "git add" to track)
|
||||
</code></pre>
|
||||
<p>The current git status says <code>No commits yet</code> and there is one untracked file. Since we just created the file, git is not tracking that file. We explicitly need to ask git to track files and folders. (also checkout <a href="https://git-scm.com/docs/gitignore">gitignore</a>) And how we do that is via <code>git add</code> command as suggested in the above output. Then we go ahead and create a commit.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git add file1.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git status
|
||||
<pre><code class="language-bash">$ git add file1.txt
|
||||
$ git status
|
||||
On branch master
|
||||
|
||||
No commits yet
|
||||
@@ -1428,7 +1428,7 @@ Changes to be committed:
|
||||
|
||||
new file: file1.txt
|
||||
|
||||
spatel1-mn1:school-of-sre spatel1$ git commit -m "adding file 1"
|
||||
$ git commit -m "adding file 1"
|
||||
[master (root-commit) df2fb7a] adding file 1
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 file1.txt
|
||||
@@ -1438,9 +1438,9 @@ create mode 100644 file1.txt
|
||||
<p>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. (<code>df2fb7a</code> 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 <code>.git</code> folder. This is where all this snapshot or versions are stored <em>in an efficient manner.</em></p>
|
||||
<h3 id="adding-more-changes">Adding More Changes</h3>
|
||||
<p>Let us create one more file and commit the change. It would look the same as the previous commit we made.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ echo "I am file 2" > file2.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git add file2.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git commit -m "adding file 2"
|
||||
<pre><code class="language-bash">$ echo "I am file 2" > file2.txt
|
||||
$ git add file2.txt
|
||||
$ git commit -m "adding file 2"
|
||||
[master 7f3b00e] adding file 2
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 100644 file2.txt
|
||||
@@ -1449,7 +1449,7 @@ create mode 100644 file2.txt
|
||||
<pre><code> **IMPORTANT: Note that commit IDs are long string (SHA) but we can refer to a commit by its initial few (8 or more) characters too. We will interchangeably using shorter and longer commit IDs.**
|
||||
</code></pre>
|
||||
<p>Now that we have two commits, let's visualize them:</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
<pre><code class="language-bash">$ git log --oneline --graph
|
||||
* 7f3b00e (HEAD -> master) adding file 2
|
||||
* df2fb7a adding file 1
|
||||
</code></pre>
|
||||
@@ -1459,7 +1459,7 @@ create mode 100644 file2.txt
|
||||
</code></pre>
|
||||
<h3 id="are-commits-really-linked">Are commits really linked?</h3>
|
||||
<p>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</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git cat-file -p 7f3b00e
|
||||
<pre><code class="language-bash">$ git cat-file -p 7f3b00e
|
||||
tree ebf3af44d253e5328340026e45a9fa9ae3ea1982
|
||||
parent df2fb7a61f5d40c1191e0fdeb0fc5d6e7969685a
|
||||
author Sanket Patel <spatel1@linkedin.com> 1603273316 -0700
|
||||
@@ -1468,18 +1468,18 @@ committer Sanket Patel <spatel1@linkedin.com> 1603273316 -0700
|
||||
adding file 2
|
||||
</code></pre>
|
||||
<p>Take a note of <code>parent</code> attribute in the above output. It points to the commit id of the first commit we made. So this proves that they are linked! Additionally you can see the second commit's message in this object. As I said all this magic is enabled by <code>.git</code> folder and the object to which we are looking at also is in that folder.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ ls .git/objects/7f/3b00eaa957815884198e2fdfec29361108d6a9
|
||||
<pre><code class="language-bash">$ ls .git/objects/7f/3b00eaa957815884198e2fdfec29361108d6a9
|
||||
.git/objects/7f/3b00eaa957815884198e2fdfec29361108d6a9
|
||||
</code></pre>
|
||||
<p>It is stored in <code>.git/objects/</code> folder. All the files and changes to them as well are stored in this folder.</p>
|
||||
<h3 id="the-version-control-part-of-git">The Version Control part of Git</h3>
|
||||
<p>We already can see two commits (versions) in our git log. One thing a version control tool gives you is ability to browse back and forth in history. For example: some of your users are running an old version of code and they are reporting an issue. In order to debug the issue, you need access to the old code. The one in your current repo is the latest code. In this example, you are working on the second commit (7f3b00e) and someone reported an issue with the code snapshot at commit (df2fb7a). This is how you would get access to the code at any older commit</p>
|
||||
<pre><code class="language-bash"># Current contents, two files present
|
||||
patel1-mn1:school-of-sre spatel1$ ls
|
||||
$ ls
|
||||
file1.txt file2.txt
|
||||
|
||||
# checking out to (an older) commit
|
||||
spatel1-mn1:school-of-sre spatel1$ git checkout df2fb7a
|
||||
$ git checkout df2fb7a
|
||||
Note: checking out 'df2fb7a'.
|
||||
|
||||
You are in 'detached HEAD' state. You can look around, make experimental
|
||||
@@ -1494,52 +1494,52 @@ do so (now or later) by using -b with the checkout command again. Example:
|
||||
HEAD is now at df2fb7a adding file 1
|
||||
|
||||
# checking contents, can verify it has old contents
|
||||
spatel1-mn1:school-of-sre spatel1$ ls
|
||||
$ ls
|
||||
file1.txt
|
||||
</code></pre>
|
||||
<p>So this is how we would get access to old versions/snapshots. All we need is a <em>reference</em> to that snapshot. Upon executing <code>git checkout ...</code>, what git does for you is use the <code>.git</code> folder, see what was the state of things (files and folders) at that version/reference and replace the contents of current directory with those contents. The then-existing content will no longer be present in the local dir (repo) but we can and will still get access to them because they are tracked via git commit and <code>.git</code> folder has them stored/tracked.</p>
|
||||
<h3 id="reference">Reference</h3>
|
||||
<p>I mention in the previous section that we need a <em>reference</em> to the version. By default, git repo is made of tree of commits. And each commit has a unique IDs. But the unique ID is not the only thing we can reference commits via. There are multiple ways to reference commits. For example: <code>HEAD</code> is a reference to current commit. <em>Whatever commit your repo is checked out at, <code>HEAD</code> will point to that.</em> <code>HEAD~1</code> is reference to previous commit. So while checking out previous version in section above, we could have done <code>git checkout HEAD~1</code>.</p>
|
||||
<p>Similarly, master is also a reference (to a branch). Since git uses tree like structure to store commits, there of course will be branches. And the default branch is called <code>master</code>. Master (or any branch reference) will point to the latest commit in the branch. Even though we have checked out to the previous commit in out repo, <code>master</code> still points to the latest commit. And we can get back to the latest version by checkout at <code>master</code> reference</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git checkout master
|
||||
<pre><code class="language-bash">$ git checkout master
|
||||
Previous HEAD position was df2fb7a adding file 1
|
||||
Switched to branch 'master'
|
||||
|
||||
# now we will see latest code, with two files
|
||||
spatel1-mn1:school-of-sre spatel1$ ls
|
||||
$ ls
|
||||
file1.txt file2.txt
|
||||
</code></pre>
|
||||
<p>Note, instead of <code>master</code> in above command, we could have used commit's ID as well.</p>
|
||||
<h3 id="references-and-the-magic">References and The Magic</h3>
|
||||
<p>Let's look at the state of things. Two commits, <code>master</code> and <code>HEAD</code> references are pointing to the latest commit</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
<pre><code class="language-bash">$ git log --oneline --graph
|
||||
* 7f3b00e (HEAD -> master) adding file 2
|
||||
* df2fb7a adding file 1
|
||||
</code></pre>
|
||||
<p>The magic? Let's examine these files:</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ cat .git/refs/heads/master
|
||||
<pre><code class="language-bash">$ cat .git/refs/heads/master
|
||||
7f3b00eaa957815884198e2fdfec29361108d6a9
|
||||
</code></pre>
|
||||
<p>Viola! Where master is pointing to is stored in a file. <strong>Whenever git needs to know where master reference is pointing to, or if git needs to update where master points, it just needs to update the file above.</strong> So when you create a new commit, a new commit is created on top of the current commit and the master file is updated with the new commit's ID.</p>
|
||||
<p>Similary, for <code>HEAD</code> reference:</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ cat .git/HEAD
|
||||
<pre><code class="language-bash">$ cat .git/HEAD
|
||||
ref: refs/heads/master
|
||||
</code></pre>
|
||||
<p>We can see <code>HEAD</code> is pointing to a reference called <code>refs/heads/master</code>. So <code>HEAD</code> will point where ever the <code>master</code> points.</p>
|
||||
<h3 id="little-adventure">Little Adventure</h3>
|
||||
<p>We discussed how git will update the files as we execute commands. But let's try to do it ourselves, by hand, and see what happens.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
<pre><code class="language-bash">$ git log --oneline --graph
|
||||
* 7f3b00e (HEAD -> master) adding file 2
|
||||
* df2fb7a adding file 1
|
||||
</code></pre>
|
||||
<p>Now let's change master to point to the previous/first commit.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ echo df2fb7a61f5d40c1191e0fdeb0fc5d6e7969685a > .git/refs/heads/master
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
<pre><code class="language-bash">$ echo df2fb7a61f5d40c1191e0fdeb0fc5d6e7969685a > .git/refs/heads/master
|
||||
$ git log --oneline --graph
|
||||
* df2fb7a (HEAD -> master) adding file 1
|
||||
|
||||
# RESETTING TO ORIGINAL
|
||||
spatel1-mn1:school-of-sre spatel1$ echo 7f3b00eaa957815884198e2fdfec29361108d6a9 > .git/refs/heads/master
|
||||
spatel1-mn1:school-of-sre spatel1$ git log --oneline --graph
|
||||
$ echo 7f3b00eaa957815884198e2fdfec29361108d6a9 > .git/refs/heads/master
|
||||
$ git log --oneline --graph
|
||||
* 7f3b00e (HEAD -> master) adding file 2
|
||||
* df2fb7a adding file 1
|
||||
</code></pre>
|
||||
|
||||
@@ -1181,18 +1181,18 @@
|
||||
</ul>
|
||||
<h2 id="hooks">Hooks</h2>
|
||||
<p>Git has another nice feature called hooks. Hooks are basically scripts which will be called when a certain event happens. Here is where hooks are located:</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ ls .git/hooks/
|
||||
<pre><code class="language-bash">$ ls .git/hooks/
|
||||
applypatch-msg.sample fsmonitor-watchman.sample pre-applypatch.sample pre-push.sample pre-receive.sample update.sample
|
||||
commit-msg.sample post-update.sample pre-commit.sample pre-rebase.sample prepare-commit-msg.sample
|
||||
</code></pre>
|
||||
<p>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 <code>pre-push</code> hooks. Let's try to create a pre commit hook.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ echo "echo this is from pre commit hook" > .git/hooks/pre-commit
|
||||
spatel1-mn1:school-of-sre spatel1$ chmod +x .git/hooks/pre-commit
|
||||
<pre><code class="language-bash">$ echo "echo this is from pre commit hook" > .git/hooks/pre-commit
|
||||
$ chmod +x .git/hooks/pre-commit
|
||||
</code></pre>
|
||||
<p>We basically create a file called <code>pre-commit</code> in hooks folder and make it executable. Now if we make a commit, we should see the message getting printed.</p>
|
||||
<pre><code class="language-bash">spatel1-mn1:school-of-sre spatel1$ echo "sample file" > sample.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git add sample.txt
|
||||
spatel1-mn1:school-of-sre spatel1$ git commit -m "adding sample file"
|
||||
<pre><code class="language-bash">$ echo "sample file" > sample.txt
|
||||
$ git add sample.txt
|
||||
$ git commit -m "adding sample file"
|
||||
this is from pre commit hook # <===== THE MESSAGE FROM HOOK EXECUTION
|
||||
[master 9894e05] adding sample file
|
||||
1 file changed, 1 insertion(+)
|
||||
|
||||
@@ -1315,14 +1315,14 @@
|
||||
<p><strong>What is the difference then, between java and python?</strong>
|
||||
Well, Java's compiler is more strict and sophisticated. As you might know Java is a statically typed language. So the compiler is written in a way that it can verify types related errors during compile time. While python being a <em>dynamic</em> language, types are not known until a program is run. So in a way, python compiler is dumb (or, less strict). But there indeed is a compile step involved when a python program is run. You might have seen python bytecode files with <code>.pyc</code> extension. Here is how you can see bytecode for a given python program.</p>
|
||||
<pre><code class="language-bash"># Create a Hello World
|
||||
spatel1-mn1:tmp spatel1$ echo "print('hello world')" > hello_world.py
|
||||
$ echo "print('hello world')" > hello_world.py
|
||||
|
||||
# Making sure it runs
|
||||
spatel1-mn1:tmp spatel1$ python3 hello_world.py
|
||||
$ python3 hello_world.py
|
||||
hello world
|
||||
|
||||
# The bytecode of the given program
|
||||
spatel1-mn1:tmp spatel1$ python -m dis hello_world.py
|
||||
$ python -m dis hello_world.py
|
||||
1 0 LOAD_NAME 0 (print)
|
||||
2 LOAD_CONST 0 ('hello world')
|
||||
4 CALL_FUNCTION 1
|
||||
|
||||
@@ -1315,13 +1315,13 @@ OUTPUT:
|
||||
|
||||
===> SHORTENING
|
||||
|
||||
spatel1-mn1:tmp spatel1$ curl localhost:5000/shorten -H "content-type: application/json" --data '{"url":"https://linkedin.com"}'
|
||||
$ curl localhost:5000/shorten -H "content-type: application/json" --data '{"url":"https://linkedin.com"}'
|
||||
Shortened: r/a62a4
|
||||
|
||||
|
||||
===> REDIRECTING, notice the response code 302 and the location header
|
||||
|
||||
spatel1-mn1:tmp spatel1$ curl localhost:5000/r/a62a4 -v
|
||||
$ curl localhost:5000/r/a62a4 -v
|
||||
* Uses proxy env variable NO_PROXY == '127.0.0.1'
|
||||
* Trying ::1...
|
||||
* TCP_NODELAY set
|
||||
|
||||
File diff suppressed because one or more lines are too long
94
sitemap.xml
94
sitemap.xml
@@ -1,191 +1,191 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2021-01-06</lastmod>
|
||||
<lastmod>2021-01-07</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
</urlset>
|
||||
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
Reference in New Issue
Block a user