Markdown and git

We use Markdown to create README files on GitHub, primarily.

1. Navigate to your SavvyCoders directory using your CLI.

2. Make a new directory called FirstnameLastname (with YOUR first and last name, of course) inside the SavvyCoders directory. (HINT: mkdir FirstnameLastname).

3. Navigate into your Portfolio Project directory (HINT: cd FirstnameLastname).

Also in your CLI, use the command touch README.md to create a new MarkDown file named inside of FirstnameLastname directory. You can open specific directories in VSCode using the code . command from your command line! Here, the . is an argument that we are passing to the code command that reinforces that we want VS Code to open up directly in our current directory.

Shortcut Keys (Especially for VS Code!)

Be sure to make a conscious decision to learn the shortcut keys as you work through this course!

For, now, be aware of 'ctrl/cmd + P' to open a 'fuzzy finder' for opening files. Simply start typing the name of a file (for example 'README') and you wil see it in that one.

Also, you can use 'ctrl/cmd + shift + p' to open up the command pallette. This gives you options for each and every possible at any given juncture. It's also a a 'fuzzy finder.' For example, maybe you want to 'save' some work? Just start typing 'save' - note that it shows you the shortcut keys. This means you should make note of that, hit 'esc' to close the finder and use the shortcut key.

Recommendation: Make it a weekly habit to add 1-2 shortcut keys to your repertoire. So, each week, make it a point to always use some new shortcuts instead of the mouse. In this way, after some time, you will get all of the major ones down.

Markdown

Markdown is a markup language. Markup languages mix in special sequences of coded characters to specify the intended layout and style of their text.

Review this Markdown code and re-type (not copy/paste else your learning outcome will be reduced) into your VSCode code editor. Search for 'markdown preview' (ctrl/cmd + shift + p) to have it parsed and rendered:

# This is a header

## This is an even smaller header

### Even smaller...

###### Quite small

Here is some normal text. A paragraph, even!

_This text is in italics._

**This text is in bold.**

**_This text is in both._**

~~This text is rendered with strikethrough.~~

Sometimes you want to embed some \*stylized text\*
right into **your paragraph.** Pretty cool, right!

- Item
- Item
- Another item

1. Item one
2. Item two
3. Item three

w/ sub-lists

1. Item one
2. Item two
3. Item three
   1. Sub-item
   2. Sub-item
4. Item four

---

[I'm a link to a web page!](http://www.google.com)

![alt text](https://i.imgur.com/81qyN1y.jpg)

Practice MarkDown

Practice each piece of MD shown above. Write a short personal introduction with some appropriate headers! Include some contact information as lists, list some hobbies, add a favorite quote, and include linked images. More specifically, use your personal avatar, and link that to a LinkedIn page, if you have that (if not, set a basic one up b/c you will need to do that prior to graduation anyway).

You'll want to preview this inside of VS Code's MarkDown Preview as described earlier.

Now that you've gotten that practice in, here's a handy guide.

Version Control with git

To help us maintain, back up, and share our code, we're going to use git (the command-line tool) and GitHub (the online repository). These tools are fundamental parts of the web developer's workflow, and you'll be using them every day for the rest of your programming career!

git works a bit like a Time Machine, in the sense that you'll be able to revert to any saved state within a directory. So if you mangle your site's directory structure, you can always use git to revert back to simpler times. The important things to understand about git specifically:

1. This is a CLI utility, so get ready for lots of text. All of our important files when programming will be text, so its only natural that we'd be navigating between save states (called 'commits') using text as well.

2. Arbitrarily or automatically saving code is NOT a feature of git, and it shouldn't be. You only want to save meaningful chunks of code (e.g. a feature), not broken pieces here and there. Otherwise, there's no way to revert back to a useful save-state!

3. Because of point #2, 'saving' your progress with git is handled a bit differently. You are in charge of 'staging' your commits, and 'committing' changes only when you are ready.

the git commit workflow

Practice git 1

Let's get our feet wet with git by configuring our user identity.

1. In any command prompt, type the following (using your name and email, of course):

      git config --global user.name "Firstname Lastname"
      git config --global user.email "[e-mail]"

2. You can check all of your configuration settings by typing

      git config --list

That wasn't so bad, right?

Practice git 2

git works by creating a folder within the 'working directory' (the directory that you would like to track/save over time). The first step to saving any project, then, is to navigate to this 'working directory' and create that git folder (named .git). Let's set up your portfolio project as a git repository to track over time.

1. First, navigate to your ~/Code/SavvyCoders/FirstnameLastname directory.

2. Next, while still the FirstnameLastname directory, type the following:

      git init

3. That should have created a .git folder, which is hidden by default. There are two ways to make sure that our git init command worked. Try these both out:

   • list all of the hidden folders (including .git) in FirstnameLastname:

      ls -a

   You should see a folder called .git in the output. Now try running a simple git command:

      git status

   If you get FATAL: FirstnameLastname is not a git repository, something has gone wrong. If everything worked, you should see something like this:

   $ git status
   On branch master
   Initial commit
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
           README.md
   nothing added to commit but untracked files present (use "git add"    to track)

4. Once git is initialized (init = initialize), we should be able start saving snapshots of our work. Before committing our work, though, we have to stage our changes. You can do that with the following command:

      git add .

   That . at the end is very important! That's telling git to stage everything in the working directory at once. To make sure that everything worked, type in git status again. You should get output that looks something like this:

   $ git status
   On branch master
   Initial commit
   Changes to be committed:
     (use "git rm --cached <file>..." to unstage)
           new file:   README.md

5. As nice as it is to get this far, we still haven't committed our changes yet. So we wouldn't be able to roll back to this point in the event of error, because README.md is still waiting to be fully committed. Let's do that with the following command:

      git commit -m "First commit"

   git forces us to create a commit message whenever a commit is made. This is a short snippet of text that helps you remember exactly what was changed in each commit. Normally committing and creating a commit are two different steps, but you can combine the two by adding the -m flag (for 'message'), followed by your custom commit message in quotation marks. If everything works as planned, you should see something like the following output:

   $ git commit -m "First commit"
   [master (root-commit) ee6ac27] First commit
    1 file changed, 3 insertions(+)
    create mode 100644 README.md

6. Now if you run git log, you'll see a list containing your entire git history (it should be pretty short at the moment). But we still only have one copy of our codebase. To back up our work, let's use GitHub! The first step is to create a new repository on online GitHub account.

7. After you've created your new repository, you'll need to link that repo to your current project directory. You can do that with git remote add origin https://github.com/YOURUSERNAME/YOUR-REPO-ADDRESS.git. If you've done this correctly, you should see the word origin pop up in the command-line when you type git remote.

8. Now we need to push our local commit (called 'First commit', containing only the README.md file) to the remote repository. To do that, enter the following command:

      git push origin master

9. If that worked, you should see your README.md file appear in your GitHub GUI after a page refresh (F5). Now you have two copies of your git repository... nice work!

Here's a guide that summarizes (and introduces a few additional concepts that will be important later).