Git Lesson : Update codeblock delimiters (TheOdinProject#27016)

* update codeblocks

* update codeblocks

git/intermediate_git/a_deeper_look_at_git.md

@@ -34,12 +34,12 @@ Let's look at some ways we can change recent and distant history to fit our need
 
 Before we get started with the lesson, let's create a Git playground in which we can safely follow along with the code and perform history-changing operations. Go to GitHub, and as you have in the past, create a new repository. Call it whatever you'd like, and clone this repository to your local system. Now, let's `cd` into the repository we just cloned and create some new files! Once you're in the repository, follow along with the following commands (including the typo). Look them up if you're confused about anything that's happening.
 
-~~~bash
+```bash
   $ touch test{1..4}.md
   $ git add test1.md && git commit -m 'Create first file'
   $ git add test2.md && git commit -m 'Create send file'
   $ git add test3.md && git commit -m 'Create third file and create fourth file'
-~~~
+```
 
 #### Setting up the code editor
 
@@ -51,10 +51,10 @@ To set up your code editor properly, you can follow the instructions provided in
 
 So if we look at the last commit we made *Uh-Oh!*, if you type in `git status` and `git log` you can see we forgot to add a file! Let's add our missing file and run `git commit --amend`
 
-~~~bash
+```bash
   $ git add test4.md
   $ git commit --amend
-~~~
+```
 
 What happened here is we first updated the staging area to include the missing file, and then we replaced the last commit with our new one to include the missing file. If we wanted to, we could have changed the message of the commit and it would have overwritten the message of the past commit.
 
@@ -66,26 +66,26 @@ Now let's say we have commits further back in our history that we want to modify
 
 `git rebase -i` is a command which allows us to interactively stop after each commit we're trying to modify, and then make whatever changes we wish. We do have to tell this command which is the last commit we want to edit. For example, `git rebase -i HEAD~2` allows us to edit the last two commits. Let's see what this looks like in action, go ahead and type in:
 
-~~~bash
+```bash
   $ git log
   $ git rebase -i HEAD~2
-~~~
+```
 
 You should notice that when rebasing, the commits are listed in opposite order compared to how we see them when we use `git log`. Take a minute to look through all of the options the interactive tool offers you. Now let's look at the commit messages at the top of the tool. If we wanted to edit one of these commits, we would change the word `pick` to be `edit` for the appropriate commit. If we wanted to remove a commit, we would remove it from the list, and if we wanted to change their order, we would change their position in the list. Let's see what an edit looks like!
 
-~~~bash
+```bash
 edit eacf39d Create send file
 pick 92ad0af Create third file and create fourth file
-~~~
+```
 
 This would allow us to edit the typo in the `Create send file` commit to be `Create second file`. Perform similar changes in your interactive rebase tool, but don't copy and paste the above code since it won't work. Save and exit the editor, which will allow us to edit the commit with the following instructions:
 
-~~~bash
+```bash
 You can amend the commit now, with
        git commit --amend
 Once you're satisfied with your changes, run
        git rebase --continue
-~~~
+```
 
 So let's edit our commit by typing `git commit --amend`, fixing the typo in the title, and then finishing the rebase by typing `git rebase --continue`. That's all there is to it! Have a look at your handiwork by typing `git log`, and seeing the changed history. It seems simple, but this is a very dangerous tool if misused, so be careful. Most importantly, remember that **if you have to rebase commits in a shared repository, make sure you're doing so for a very good reason that your coworkers are aware of.**
 
@@ -96,11 +96,11 @@ Using `squash` for our commits is a very handy way of keeping our Git history ti
 
 Let's say we want to `squash` the second commit into the first commit on the list, which is `Create first file`. First let's rebase all the way back to our root commit by typing `git rebase -i --root`. Now what we'll do is `pick` that first commit, as the one which the second commit is being `squash`ed into:
 
-~~~bash
+```bash
 pick e30ff48 Create first file
 squash 92aa6f3 Create second file
 pick 05e5413 Create third file and create fourth file
-~~~
+```
 
 Rename the commit to `Create first and second file`, then finish the rebase. That's it! Run `git log` and see how the first two commits got squashed together.
 
@@ -110,11 +110,11 @@ Before diving into Remotes, we're going to have a look at a handy Git command ca
 
 We can open up the tool just like last time, change `pick` to `edit` for the commit we're going to split. But instead, what we're going to do is run `git reset HEAD^`, which resets the commit to the one right before HEAD. This allows us to add the files individually, add, and commit them individually. All together it would look something like this:
 
-~~~bash
+```bash
 $ git reset HEAD^
 $ git add test3.md && git commit -m 'Create third file'
 $ git add test4.md && git commit -m 'Create fourth file'
-~~~
+```
 
 Let's start by looking a bit closer at what happened here. When you ran `git reset`, you reset the current branch by pointing HEAD at the commit right before it. At the same time, `git reset` also updated the index (the staging area) with the contents of wherever HEAD is now pointed. So our staging area was also reset to what it was at the prior commit - which is great - because this allowed us to add and commit both files separately.
 

git/intermediate_git/working_with_remotes.md

@@ -19,31 +19,31 @@ If you haven't updated your local branch, and you're attempting to `git push` a
 
 You might perform a brief query and find the command `git push --force`. This command overwrites the remote repository with your own local history. So what would happen if we used this while working with others? Well, let's see what would happen when we're working with ourselves. Type the following commands into your terminal, and when the interactive rebase tool pops up remove our commit for `Create fourth file`:
 
-~~~bash
+```bash
 $ git push origin main
 $ git rebase -i --root
 $ git push --force
 $ git log
-~~~
+```
 
 Huh, that's interesting. We don't see our fourth file on our local system. Let's check our GitHub repository to see if it's there.
 
 Oh no, we just destroyed it!  In this scenario, the danger - you could potentially destroy the work of those you're collaborating with! `git push --force` is a **very dangerous command, and it should be used with caution when collaborating with others**. Instead, you can fix your outdated history error by updating your local history using `fetch`, `merge`, and then attempting to `push` again.
 
 Let's consider a different scenario:
 
-~~~bash
+```bash
 $ touch test4.md
 $ git add test4.md && git commit -m "Create fifth file"
 $ git push origin main
 $ git log
-~~~
+```
 We look at our commit message and realize *oops*, we made a mistake. We want to undo this commit and are once again tempted to just force the push. But wait, remember, this is a **very dangerous command**. If we're ever considering using it, always check if it's appropriate and if we can use a safer command instead. If we're collaborating with others and want to *undo* a commit we just made, we can instead use `git revert`!
 
-~~~bash
+```bash
 git revert HEAD
 git push origin main
-~~~
+```
 
 Remember when we were working with HEAD, aka the current commit we're viewing, while rebasing? What this would do is it would revert the changes to HEAD! Then we would push our new commit to whichever branch we're working on, which in this example is main even though normally our work would most likely be on a feature-branch.