• Find and install the Live Server extension. This allows you to run a web server that automatically reloads every time you save a file in your web project: 

Click the Extensions icon on the Activity Bar > type "Live Server" in the search box > click Install

• To use Live Server: Open an HTML document in VS Code > Right click in the Editor > select "Open with Live Server". The HTML page will automatically open in your default web browser.

• Find and install the JavaScript ES6 Code Snippets extension.

Click the Extensions icon on the Activity Bar > type "JavaScript ES6 Code Snippets" in the search box > Click install 

• To use ES6 Snippets: Type in a shortcut followed by tab and the snippet will be added.

• Tab size: Search for Tab Size > value: 2 or 4

• Word wrap: Search for Word wrap > value: on or off
• Minimap: Search for minimap > check or uncheck Minimap: Enabled.
• Enable Preview: Search for enable preview > check or uncheck Editor: Enable Preview.
• Vertical Rulers: Search for rulers > click Edit in settings.json > set "editor.rulers" to "editor.rulers": [80, 100], or some other number(s) > Save the file.
• Optionally, disable popup hints/suggestions and breadcrumbs:
• Quick suggestions: Search for quick suggestions > "other" value off.
• Hover (shows hints when hovering over your code): Search for hover > uncheck Hover: Enabled.
• Parameter hints: Search for parameter hints > uncheck Parameter Hints: Enabled.
• Suggest on trigger characters: Search for Suggest on trigger characters > uncheck Editor: Suggest on trigger characters.
• Breadcrumbs: Search for breadcrumbs > uncheck Breadcrumbs: Enabled.

• Run menu: Most used Debugger commands.
• Open LiveServer: In the Status bar, click Go Live.
• This will launch the local development server (Live Server) and open the index.html document. 
• Use to launch the chrome debugger when you have a launch.json configuration file.
• Launch Debugger: Click the button to launch the Debugger. 
• If you have multiple configurations, use the dropdown box to select the appropriate configuration.
• Debug Sidebar: Has panels for Variables, Watch, CallStack, Breakpoints.
• ... Views and More Actions: Show/Hide panels and Debug console.
• Gear icon: Create/Open launch.json file.
• Debug Console: Displays console logs.
• Clear console icon: clears console.
• X: Closes console.
• Breakpoint: Red dot in the Editor margin.

• click on editor margin 
• Run Menu > Toggle Breakpoint | F9
• Right click editor margin > Add Breakpoint

• Run menu > New Breakpoint > Inline Breakpoint | ⇧F9

• Right click breakpoint > Disable breakpoint
• Breakpoints panel > Toggle Activate all Breakpoints toolbar
• Breakpoints panel > Uncheck breakpoint
• Run menu > Disable All Breakpoints

• Click red dot
• Right click breakpoint > Remove breakpoint
• Breakpoints panel > Remove All Breakpoints toolbar
• Breakpoints panel > X (Remove Breakpoint)
• Run menu > Remove All Breakpoints

Console log a message. Put expressions in {}

• Right click editor margin > Logpoint
• Run menu > New Breakpoint > Logpoint
• Right click existing breakpoint > Edit breakpoint > Dropdown > Log Message

• Run menu > New Breakpoint > Conditional Breakpoint

• Right click existing breakpoint > Edit breakpoint > Dropdown > Expression

Expression condition: The breakpoint will be hit whenever the expression evaluates to true. i < 10

throw new Error('This is an uncaught exception.');

try {
  throw new Error('This is a caught exception.')
}
catch(err) {
  console.log(err.message);
}

.eslintrc.json

"rules": {
    "no-console": "off",
    "no-plusplus": "warn",
    "max-len": ["error", { "ignoreComments": true }]
}

• Git is a free, open-source version control system (VCS). 
• A VCS:
• Allows multiple developers to work on the same project simultaneously.
• Prevents changes from being overwritten.
• Maintains a retrievable history of each version.
• Git is also referred to as a source code manager since it is used to manage the source code for development projects.
• Git was developed by Linus Torvalds, the creator of Linux, in 2005.
• There are two types of VCSs: centralized and distributed. Git is distributed.
• Collaborators check out the full project from the central repository. They work on their changes independently, then changes are reviewed and committed.

• You create a repository and periodically store a version of your project by making a commit with the latest changes to the repository. 
• Changes not committed can be discarded.

• From the terminal run: git -v 
• Compare it with the latest version available. See: git-scm.com
• If it is a minor version behind (major.minor.patch) you should update it.

• If you have XCode installed it includes a binary version of Git.
• If you use Homebrew as your Mac installer, it will install the latest version.
• There is an installer link here installs an older version.

• Check that Homebrew is installed: which brew 
• Homebrew reference and installation instructions: brew.sh
• If you have homebrew installed: brew install git

• When you make Git commits, the meta data in each commit will include the user name and email of who made the commit.
• Set the global git variables for user name and email to Joey R. and joey@example.com.

• If there are modified files to commit, the number of files will appear on the Source Control toolbar.
• Click the Source Control toolbar to view, stage, commit modified files.
• Modified files are grouped under "changes".
• Select a modified file to review/stage it:
• The file differences since last commit will appear in the editor.
• To add the changes to the staging area, click the + sign. 
• To discard the changes since the last commit, click the looping arrow icon.
• To commit staged files, enter a commit message in the Message box then click the commit button.

1. The working directory (git calls this the "working tree"): consists of files that you are currently working on.
2. The staging area (git calls this the "index"): a temporary area where you queue up changed files before committing them. Git compares staged files to the same files in the repo. Files with changes are marked as modified.
3. The repository: When you commit the staged modified files, they are added to the repository as a permanent, retrievable record. The commit is a snapshot of all your tracked files at that point in time.

• Git add adds the files in your working directory to the temporary staging area (except .gitignore files).
• Git commit permanently stores the files to the local git repository.
• Git checkout: If you have multiple git branches, git checkout will checkout the specified branch to your working directory.
• If you have a remote repository (e.g., github, heroku): 
• Git push adds the commit to the remote repository.
• Git clone copies a remote repository to your local environment for the first time.
• Git fetch gets meta information about any changes committed by collaborators to a remote repository you are collaborating on.
• Git pull pulls the changes from a remote repository you are collaborating on.

• Untracked files have not been committed. Git doesn't know about them yet. 
• Tracked files exist in the Git repository from a previous commit.
• Tracked files can be either modified or unmodified since the last commit. Modified files can be added to the staging area to be committed.
• Staged files are files added to the staging area. Once you commit these files to the git repository, they become unmodified tracked files.

• git add . Stages all files starting with the current directory. "." is the path to the current directory. If you are in the root directory, it will stage all files.
• git add -A | git add --all stages files in the project regardless of what directory you are currently in.

• Capitalize first word (not each word). 
• Don't end with a period
• Use present tense imperative mood: "Fix bug". Not: "Fixed bug" or "Fixes bug."
• Short messages: One line with max of 50 characters.
• Long messages: First line is a summary following the same rules as above.
• After the summary add a blank line.
• Then add the detailed explanation. Describe what was done and why, but not how.
• Wrap the body at 72 characters.

• Optionally prepend feat: if the commit is a feature. fix: if it is a bug fix. Ref: conventionalcommits.org

1. Both versions will be shown separated by markers.
2. Fix the code and remove the markers. VS Code facilitates this with buttons above the two versions:
•  If you want to accept both changes click "Accept Both Changes".  
• You can manually fix the top version then click "Accept Current Change".
• Or manually fix the bottom version then click "Accept Incoming Change".
• To see the differences side-by-side click "Compare Changes". 
3. Save the file.  
4. git status shows the unmerged file path. Then create a new commit that fixes the merge conflict.
5. git add <filename> Stage the conflicting file.
6. git commit -m 'Fix merge with branchname' Commit the fix.
7. git log -3 View the last 3 commits. The Fix merge commit will be at the top.

• On deletion, you have to stage the deletion first before committing it.
• On renaming, git treats it as two operations. Deleting index.html and adding a new file home.html.

• The long version of the -S option is --staged.
• The git reset [filename] command can also be used to move all (or specified) staged files back to the working directory.

• After modifying and staging several files, committing them with the amend option combines the changes with your prior commit.
• The prior commit is deleted and replaced with the new amended commit.
• The --no-edit option uses the prior commit message for this commit.

• Do not stage any changed files.
• Make a commit with the --amend option and new message: "Add users resource".

• Pick: Use the commit as is.
• Reorder: Cut and paste to reorder the commits.
• Squash: To combine a commit with the one above it, change pick to squash | s.
• Fixup: Like squash but uses message from prev commit. Change pick to fixup | f.
• Reword: To change the commit message, change pick to reword | r.
• Edit: To edit the changes in a commit change pick to edit | e > git add filePath > git commit --amend > git rebase --continue
• Drop: To delete a commit, change pick to delete | d, or just delete the line. Note: This will cause all commits that follow it to be rewritten.

• Temporarily stash your code so you can do a task in a different branch: git stash
• Change branches. Complete the task. Then change back to the original branch.
• Retrieve and delete the stash to continue working on it: git stash pop 

• Experiment with a new feature idea called Feature X without making it a branch yet. 
• Create your files. Then stash them with message 'Feature X': git stash -um 'Feature X'
• Later you want to work on the feature some more. Retrieve the files: git stash pop
• After working on it some more you can either:

1. Create a new stash: git stash -um 'Feature X'
2. Discard the files and changes: git restore . 
3. Make the changes into a branch git checkout -b feature-x 

• If the stash index is not provided with the command, the most recent stash is selected (i.e., index 0).
• To retrieve stashes use git stash pop (deletes the stash), unless you want to make the stash available to multiple branches. In that case use git stash apply (does not delete the stash).
• You can create a branch directly from a stash with the command: git stash branch <branchname> <index>

1. Public/Private: The repository is either Public or Private
2. Watch/Unwatch: Receive/configure notifications from this repo.
3. Fork: Existing forks on this repo | Create a new fork.
4. Code view: Shows file tree. Displays Readme file at the bottom.
5. Issues view: Lists open issues. You can switch to view closed issues.
6. Pull requests view: Lists open pull requests. You can switch to view closed PRs.
7. Settings view: View and modify the repository's settings. Add collaborators.
8. Current branch/tag button: In code view, shows the current branch or tag name. Dropdown menu lets you change your code view to a different branch or tagged commit.
9. Code button: Copy the repo's URL or download the repo code as a zip file.
10. Commits: The number of commits on this repo. Clicking the number will open the commit history view.
11. File list: Code view displays the repository's file names and last commit affecting each file. Clicking a file will display the content.
12. README.md: Code view displays the readme file at the bottom.
13. Releases: Shows the number of releases on this repo with a link to the latest release.

• Create a personal access token.
• Use GitHub CLI.
• Use Git Credential Manager. 

• GCM is a credential helper built on .NET that runs on Windows, macOS, and Linux. You can use it instead of generating a personal access token.
• Ref: github.com/GitCredentialManager/git-credential-manager/blob/main/README.md
• See if git-credential-manager-core is installed: which git-credential-manager-core
• Latest installation instructions: github.com/GitCredentialManager/git-credential-manager/blob/release/docs/install.md
• Install with HomeBrew on MacOS (see Homebrew below):
• brew tap microsoft/git
• brew install --cask git-credential-manager-core
• See if it is up-to-date: brew outdated git-credential-manager-core
• If outdated: brew upgrade git-credential-manager-core 
• Uninstall: brew uninstall --cask git-credential-manager-core 

• Homebrew is a Mac or Linux third-party command line utility for installing applications.
• See if homebrew is installed: brew --version or which brew
• If not, go to their website and follow the installation instructions: brew.sh

1. git checkout -b users Create and switch to users branch.
2. Add, modify, delete files until the branch is complete.
3. git add . Add completed files to the staging area.
4. git commit -m 'Add users resource' Make your final commit.
5. git branch main Switch back to the main branch.
6. git merge users Merge in the users branch.
7. git push Push the main branch to the remote repository.
8. git push heroku Push the main branch to heroku.
9. git branch -d users Delete the users branch.

• By default, protected branches prevent collaborators from deleting the branch and prevents forced (i.e., overriding) pushes. 
• You can change this at the bottom of the branch protection rule page to allow users with push access to force push and/or delete the branch.

• You can require commits to be submitted as pull requests.
• Then require pull requests be approved before they can be merged.

• If git fetch prints nothing to the Terminal you are up-to-date. 
• If there are commits to the remote main branch not included in your local main branch they will be stored in .git/refs/remotes/origin/main.
• If the git fetch prints to the Terminal then run:

• Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
• If you receive feedback that needs to be addressed, convert the pull request to a draft pull request while working on them. Open the PR page. Under "reviewers" click "Convert to draft".

• You can open a Draft Pull Request to start a discussion on the code or topic before the branch is complete.
• Create and push a branch with at least one commit. 
• Change the Create pull request ▾ button to Create draft pull request ▾ before clicking it.
• Ready for review:
• Incorporate feedback on your local branch, make commits, and push them.
• When the branch is ready, click the Github Pull requests tab > Select your pull request > In the merge bock click Ready for review.

• Prevalent with small teams and organizations collaborating on private projects.
• Collaborators are granted push (write) access to a single shared repository.
• Topic branches are created when changes need to be made.
• Pull requests are not required in this model but are useful because they initiate code review and general discussion about a set of changes before the changes are merged into the main development branch. 

1. git pull Sync the main (tracking) branch with the remote.
2. git checkout -b <topicBranch> Create and check out a new branch.
3. Add, modify, delete files until the branch is complete. Make one or more commits:
1. git add . Stage the added/deleted/changed files for commit.
2. git commit -m 'Message' Commit the file changes.
4. git checkout main Switch to the main branch to make sure it is in sync with remote.
5. git pull Sync main (tracking) branch with remote. 
6. git checkout <topicBranch> Switch back to the topic branch. 
7. If main was out of sync, merge main branch: git merge main
8. git push origin <topicBranch> Push topic branch to the remote repository.

1. Click Compare & pull request > Add description > click Create pull request
• For comments only, change Create pull request ▾ to Create draft pull request 
2. Optionally, request reviewers: Reviewer > Select collaborators

Access: Must have write access to approve or request changes. 

1. From Github project page: Click Pull requests > select the request > 
2. Review request: Click Files changed > Review the changes > click Review changes > Type comment summarizing feedback > Select type of review [Comment | Approve | Request changes] > Submit review

1. Make changes in local repo to the topic branch.
2. When complete, commit, push the follow-up commits to the remote topic branch:
1. git add .
2. git commit -m 'message' 
3. git push origin <topicBranch>

• To merge PR:
1. Conversation tab > Select and click a merge button:
1. Create a merge commit: branch commits + a merge commit.
2. Squash and merge: Combine all branch commits into one. Only use squash if you are done with the feature branch.
3. Rebase and merge: branch commits, no merge commit.
2. Optionally change commit message > Click Confirm merge
3. If branch will not be updated, click Delete Branch
• To reject PR: Conversation tab > Type a comment > Click Close pull request.

1. git checkout main Switch to main branch
2. git pull In the main branch, sync with the remote main branch.
3. If there won't be further branch updates: git branch -D <topicBranch>

• Popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.
• Anyone can fork an existing repository and push changes to their personal fork, then open a pull request on the original repo.
• The changes can be reviewed and pulled into the source repository by the project maintainer.

1. Propose changes to someone else's project where you don't have write access. 
2. Copy someone else's project to use as a starting point for your own ideas. In this case you can use forking or cloning.

1. git checkout -b <topicBranch> Create and check out a new branch.
2. Add, modify, delete files until the branch is complete. Make one or more commits:
1. git add . Stage the added/deleted/changed files for commit.
2. git commit -m 'Message' Commit the file changes.
3. git checkout main Switch to the main branch to make sure it is in sync with remote.
4. git pull upstream main Sync main branch with upstream remote. 
5. git checkout <topicBranch> Switch back to the topic branch. 
6. If main was out of sync, merge main branch: git merge main
7. git push origin <topicBranch> Push topic branch to forked remote repo.

1. Click Compare & pull request > Add description > click Create pull request 
• For comments only, change Create pull request ▾ to Create draft pull request ▾ 
• Optionally check Allow edits from maintainers
2. Optionally, request reviewers: Reviewers > Select collaborators

Access: Must have write access to approve or request changes. 

1. Github fork repo: Click Pull requests > select the request
2. Review request: Click Files changed > Review the changes > click Review changes > Type comment summarizing feedback > Select type of review [Comment | Approve | Request changes] > Submit review 
3. If maintainer edits are allowed, maintainers can make their own changes to the pull request.

1. Make changes in local repo to the topic branch.
2. When complete, commit and push branch with new commit to forked remote:
1. git add .
2. git commit -m 'message' 
3. git push origin <topicBranch>

• To merge PR:
1. Conversation tab > Select and click a merge button:
1. Create a merge commit: branch commits + a merge commit.
2. Squash and merge: Combine all branch commits into one. Only use squash if you are done with the feature branch.
3. Rebase and merge: branch commits, no merge commit.
2. Optionally change commit message > Click Confirm merge
3. If branch will not be updated, click Delete Branch
• To reject PR: Conversation tab > Type a comment > Click Close pull request.

1. git checkout main Switch to main branch.
2. git pull upstream main In the main branch to sync with the upstream repo.
3. git push origin main Sync the remote fork repo.
4. If there won't be further branch updates: git branch -D <topicBranch>

• Markdown is a lightweight markup language for creating formatted text documents using a plain-text editor.
• Use Markdown syntax to add formatting such as headings, lists, bold and italic text, hyperlinks, and images.
• You write your document in any plain text editor like VS Code, in a dedicated Markdown application, or in a web form.
• Unlike WYSIWYG editors like MS Word, the formatting does not happen directly in the editor. Rather a software program converts it to HTML, then it is rendered in a browser.
• The syntax is designed to be readable as is, and is much less obtrusive than HTML or other markup languages. 
• Many Markdown variants, including GitHub's, allow you to use HTML tags in your Markdown document.

1. Write text with Markdown syntax in a Markdown file or web form. 
2. Markdown software converts the text to HTML.
3. The converted HTML is rendered in a browser or Preview window. 

• markdownguide.org/tools/vscode  
• code.visualstudio.com/docs/languages/markdown

# Heading level 1
## Heading level 2
### Heading level 3
#### Heading level 4
##### Heading level 5
###### Heading level 6

Heading level 1
===============

Heading level 2
---------------

This is line 1. It ends with two spaces.  
This is line 2. It ends with an HTML break tag.<br>
This is line 3.

This is paragraph 1.

This is paragraph 2.

> This is a blockquote.

    function triple(num) { 
      return num * 3; 
    }; 
    triple(2);

- List item.
- Another list item.
  - Indented item.
  - Another indented item.

1. Item 1
1. Item 2
    1. Indented item 1.
    1. Indented item 2.

1. Item 1
2. Item 2
1. Indented item 1.
2. Indented item 2.

---

Link:
[example](https://example.com) becomes example.com

---

Image:
![Markdown icon](./markdown-icon.png "Markdown")


If you want to set width or height, use the HTML tag. The Markdown application you are using must support HTML tags.
<img src="markdown-icon.png" alt="Markdown icon" title="Markdown" width="52" height="32">
Becomes:

• A plain URL will automatically be converted into a hyperlink. 
• Ex: https://example.com becomes https://example.com
• To display the hyperlink with different text, use the Markdown syntax. 
• Ex: [example.com](https://example.com) becomes example.com 

• For language syntax highlighting, add the language name after the opening ``` or ~~~.
• Languages: html, css, javascript or js, json, python, etc.

``` javascript
function double(num) { 
  return num * 4; 
}; 
double(2);
```

• Alternatively, indent the code block four spaces.

    function triple(num) { 
      return num * 3; 
    }; 
    triple(2);

• h1-h6 headings automatically convert the heading text to an id. The text is lower cased, spaces are converted to dashes. Characters other than letters and numbers are removed (periods, commas, apostrophes, quotes, slashes, etc).

• GitHub automatically generates a hidden Table of Contents for every markdown file. It includes a link to every h1-h6 heading in the file.
• To view it, click the TOC icon at the top left of the displayed markdown file.

# Page Heading
 
## Manual Table of Contents
 
[Topic 1](#topic-1)  
[Topic 2](#topic-2)  
 
## Topic 1
 
Topic 1 content.
 
## Topic 2
 
Topic 2 content.