Skip to content

These are the handwritten notes on, how to set up an IDE, an introduction to Conda environment, how to use Git and GitHub for version control, and mathematics for data science.

Notifications You must be signed in to change notification settings

omkarfadtare/Essential

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

97 Commits
 
 

Repository files navigation

Essential steps to set-up your System:

Setting up an IDE (Integrated Development Environment):

1) Pycharm:

  • PyCharm is an integrated development environment (IDE) specifically designed for Python development.
  • You can download PyCharm here. There are two versions available i.e. Professional version and Community version (free).
  • After successfully installing PyCharm, you need to add new environment variables. Setting environment variables for PyCharm can be done at system level or by using PyCharm run configuration.
  • To set environment variables at the system level on Windows:
    • Go to, edit the system environment variables
    • Environment variables
    • Under user variables select Path
    • Click Edit
    • Click New
    • Add (C:\Users\omkar\AppData\Local\Programs\Python\Python312\ & C:\Users\omkar\AppData\Local\Programs\Python\Python312\Scripts)
    • Click Ok
    • Click Ok
    • Click Ok
  • You can find path and version of Python by running below commands in command prompt:

image

2) VS code:

  • VS Code is a free and open source integrated development environment (IDE) developed by Microsoft.
  • It supports multiple languages and comes with features such as debugging, syntax highlighting, intelligent code completion, snippets, code refactoring, and embedded Git, which is very convenient for version control.
  • It offers numerous settings and a vast marketplace with extensions for adding new languages, themes, debuggers, and connecting additional services.
  • Working with VS Code can enhance your efficiency as a Data scientist. It can manage your entire data science project lifecycle.
  • You can download VS Code here.
  • To open VS Code in specific folder:
    • Right click
    • Open in terminal
    • Run code . command

image

3) Anaconda:

  • To use Jupyter notebook, you need to download Anaconda. You can download Anaconda here.
  • Jupyter notebook is not a traditional integrated development environment (IDE). It is an open-source web application that enables you to create and share documents containing live code, equations, visualizations, and narrative text.
  • After successfully installing Anaconda, you need to add new environment variables. Setting environment variables for Jupyter can be done at the system level.
  • To set environment variables at the system level on Windows:
    • Go to, edit the system environment variables
    • Environment variables
    • Under sser variables select Path
    • Click Edit
    • Click New
    • Add (C:\Users\omkar\anaconda3\ & C:\Users\omkar\anaconda3\Scripts)
    • Click Ok
    • Click Ok
    • Click Ok
  • To open Jupyter in specific folder:
    • Right click
    • Open in terminal
    • Run jupyter notebook command
  • You can find path and version of Jupyter notebook by running below commands in command prompt:

image

Conda environment:

  • Conda environment provides a way to isolate different projects, preventing conflicts between dependencies and package versions required by different projects.
  • Creating a Conda environment is crucial for maintaining a clean, organized, and reproducible development environment. It helps manage dependencies, reduces conflicts, and enhances overall efficiency and reliability in Python projects.
  • Environments allow you to manage specific versions of Python and other packages for a particular project. By specifying exact dependency versions, Conda environments make it easier to share code, enabling others to recreate the same environment without issues.
  • Conda simplifies package management with a single tool for installing, updating, and removing packages, making it more user-friendly than manual dependency management.
  • With Conda, you can easily switch between different Python versions for different projects, particularly beneficial for projects with specific Python version requirements.
  • Use Conda prompt or Command promt or VS Code powershell (ctrl + `) for Conda operations.

Conda commands:

Command Use
conda info Used to verify whether Conda is installed or not
conda --version Used to check Conda version
conda update conda Used to update Conda to the latest version
conda env list Used to get a list of all environments (active environment is shown with *)
conda list List all packages and versions installed in an active environment
conda create --name your_env_name Create a new environment
conda create --name your_env_name python=3.x Create a new environment with a specific python version
conda create --name your_env_name python=3.x package1 package2 ... Create a new environment with a specific python version and specific packages
conda env create --file environment.yml Create a new environment from a .YAML file (in .YML file env_name is already present)
conda create --name your_env_name --file requirements.txt Create a new environment from a .TXT file (in .TXT file env_name is not present so that you need to give env_name)
conda create --name your_env_name python=3.x && conda activate your_env_name Create a new environment with a specific python version and activate it
conda activate your_env_name Activate specific environment
conda deactivate your_env_name Deactivate specific environment and switch back to base environment
conda env remove --name your_env_name Delete specific environment
conda create --clone source_env_name --name new_env_name To make exact copy of a specific environment
conda install package_name Install a specific package to a currently active environment
conda install --name your_env_name package_name Install packages in a specific environment
conda update package_name Update a package in a currently active environment
conda install package_name=1.2.3 Install a specific version of a package to a currently active environment
conda install package1 package2 package3 Install multiple packages at once to a currently active environment
conda install -c channel_name package_name Install packages from a specific channel to a currently active environment
conda install -c channel_name package_name=1.2.3 Install packages from a specific channel with a specific python version to a currently active environment
conda install --file requirements.txt Install packages using a .TXT file to a currently active environment
pip install -r requirements.txt Install packages using a .TXT file to a currently active environment (preferred way)
conda install --name your_existing_env_name --file requirements.txt Install packages using a .TXT file to a specific environment
conda env update --name your_existing_env_name --file environment.yml Install packages using a .YML file to a currently active environment
conda list --export > environment.yml To generate .YML file from a currently active environment (error due to formatting)
conda env export --name your_env_name > environment.yml To generate .YML file from a specific environment (error due to formatting)
conda list --export > requirements.txt To generate .TXT file from a currently active environment (error due to formatting)
conda env export --name your_env_name > requirements.txt To generate .TXT file from a specific environment (error due to formatting)
conda list -e > requirements.txt To generate .TXT file from a currently active environment (error due to formatting)
pip freeze > requirements.txt To generate .TXT file from a currently active environment (error due to formatting)
pip list --format = freeze > requirements.txt To generate .TXT file from a currently active environment (works fine this is the preferred way)

Ways to specify version numbers:

Specification Result
numpy=1.11 1.11.0, 1.11.1, 1.11.2, 1.11.18 etc
numpy==1.11 1.11.0
"numpy>=1.11" 1.11.0 or higher
"numpy=1.11.1 1.11.3"
"numpy>=1.8, 1.8, 1.9, not 2.0

Difference between .YML and .TXT file:

image

image

Git and GitHub:

Terminology:

  • Remote repository is a repository on GitHub account, whereas Local repository is repository in your local machine/computer.

Version control systems:

1) Git:

  • Git is a distributed version control system or tool that enables collaboration among multiple contributors by allowing them to work on the same project concurrently.
  • It helps you manage and track changes in your code or project over time.
  • Git can be used through the command line interface or VS Code terminal or Git Bash, but various GUI tools, such as GitKraken or GitHub Desktop, provide a visual interface for those who prefer not to use the command line interface, but as a programmer it's always a good practice to use terminal.

Installing Git Bash:

  • You can download and install Git Bash here.

2) GitKraken | Tower:

  • GitKraken is a graphical user interface (GUI) for Git, providing a visual representation of your repositories. Visualizes branches, commits, and merges.
  • Tower is a popular Git client that provides a graphical user interface (GUI) for managing Git repositories. It is not an intrinsic part of Git itself but is a third-party tool that facilitates Git-related tasks.

3) GitHub Dekstop:

  • GitHub Dekstop is another graphical user interface (GUI) for Git, providing visual representations and simplifying common Git operations.

4) SVN (Subversion):

  • SVN is a centralised version control system that helps software developers manage and track changes in their code over time.
  • It allows multiple people to work on the same project simultaneously, keeping a history of modifications, and facilitating collaboration.

Repository hosting services:

  • GitHub, GitLab, and Bitbucket are online platforms where you can store, collaborate, and manage your code that uses Git as the version control system. While they share the fundamental purpose of hosting repositories, they may differ in additional features, integrations, and the overall development ecosystem they offer.

1) GitHub:

  • GitHub is a web-based platform, owned by Microsoft, for hosting and collaborating on Git repositories. It's like a cloud-based space to store and work on your code.
  • It provides Git repository hosting, code collaboration, issue tracking, and integration with various development tools.

Creating a GitHub account:

  • You can create and set-up your GitHub account here.

2) GitLab:

  • GitLab is also a web-based platform for hosting Git repositories, similar to GitHub.
  • It offers a complete DevOps platform, encompassing not only version control but also continuous integration and deployment (CICD).
  • It provides Git repository hosting, continuous integration, deployment tools, code review, issue tracking, and more—all within a single platform.

3) Bitbucket:

  • Bitbucket is also a web-based platform for hosting Git repositories, owned by Atlassian, similar to GitHub and GitLab.
  • It provides Git repository hosting, code collaboration, integration with other Atlassian products (such as Jira), and support for both Git and Mercurial repositories.

Authentication methods in Git:

  • When connecting your local machine to a GitHub account or remote repository using Git, you need an authentication method. Here are several commonly used methods:

1) HTTPS:

  • HTTPS authentication in Git uses username and password for authentication but GitHub deprecated password authentication for Git operations in August 2021.
  • So it is recommended to use a Personal Access Token (PAT) instead of your account password.
  • Easy to set up, but may require entering credentials again and again.

Steps to generate PAT:

  • Go to GitHub settings
  • Developers settings
  • Personal access token
  • Token (classic)
  • Generate new token
  • Generate new token (classic)
  • Enter your GitHub password
  • Confirm
  • Set expiry date for token
  • Select scope of token
  • Generate token.
  • Use generated personal access token as a password during Git operations

2) GCM (Git Credential Managers):

  • Enhances authentication by caching credentials.
  • GCM is a one-time process, often requires logging in with a browser.
  • By default, GCM is installed at the time of Git installation.
  • If GCM is not installed in system you can download GCM from here

Step to check whether GCM is installed or not using below command in Git Bash:

git credential-manager-core --version

3) SSH (Secure Shell) Keys:

  • SSH keys provides a more secure method for authentication.
  • It requires generating an SSH key pair and adding the public key to your GitHub account.
  • It enables secure communication via the SSH protocol.

Steps to generate and set SSH key:

  • Open Git Bash and write below command:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
  • Specify location and name of the file to be saved
  • You can optionally set a passphrase for added security. Press Enter to skip or enter a passphrase when prompted.
  • SSH key will be generated and saved to the specified location
  • View SSH public key using below command:
cat file_path.pub
  • Copy SSH public key
  • Add SSH private key to SSH Agent using below command:
eval "$(ssh-agent -s)"
ssh-add E:/file_path
  • Add copied SSH public key to GitHub or Git hosting services, go to GitHub account
  • Settings
  • SSH and GPG keys
  • New SSH key
  • Give a title (just for your reference)
  • Paste SSH public key
  • Add SSH key
  • Enter Github password
  • Confirm

Git branching simplified:

  • Branching is extremely useful because when building new features for an application that might break your code or are not yet finished, you don't want to save them directly to the "main/master" branch. Instead, you want to work on them in a kind of sandbox, a separate branch. This way, you can write and refine the code until it's correct and in the state you want, before merging it back into the main code base. This approach is especially helpful when multiple people are working on the same repository or when there are numerous branches in progress simultaneously.
  • Git branching is like creating separate paths to work on different tasks without messing up the main project.
  • It's like having different notebooks for different tasks, such as writing a story or drawing. This way, you can make changes and try out new ideas without affecting the main story until you're sure you want to include them. Once you're happy with your work in a branch, you can bring those changes back into the main project.
  • Developers use branches to isolate changes, experiment with new features, or fix bugs without affecting the main codebase until they are ready to be merged.
  • It allows developers to isolate changes, experiment with new features, or fix bugs without affecting the main codebase until they are ready to be merged.
  • It helps in managing complexity by allowing developers to work on different tasks independently.
  • It reduces conflicts by isolating changes in separate branches until they are ready to be integrated.
  • It facilitates a more controlled and efficient development process, especially in collaborative environments.

Steps to prepare files to Push them from local to remote repository:

1) git add: This command is used to stage changes for the next commit.

2) git commit: This command creates a new commit with the changes that have been staged (added) using "git add". An ideal commit message consists of two parts Subject (brief summary of the changes made in the commit) and Body (details about the changes introduced in the commit).

3) git push: This command is used to upload local repository commits to a remote repository.

Types of branch:

  • Every Git repository typically contains at least one long-running branch, commonly named "main/master". Additional long-running branches, such as "developement" or "production" or "integration" may exist throughout the entire project lifecycle. These branches often represent different stages in the release or deployment process. It is common to structure branches to mirror the flow of code through various states, such as development, staging, and production.
  • Changes are not directly merged to these branches; instead changes are merged to the "integration" branch, this ensures only tested and reviewed code is introduced into production environments.
  • This practice aligns with the principles of testing, code review, and release bundling, allowing for controlled and scheduled releases. In contrast to long-running branches, short-lived branches are created for specific purposes and are deleted after integration. Common use cases for short-lived branches include working on new features or bug fixes. These branches provide isolation for changes, allowing developers to collaborate on specific tasks without impacting the main development branches.

1) Long lived branch:

  • Long lived branches are branches that exist throughout the entire lifespan of a project. For example "main/master" branch, "developement" branch, "production" branch, "integration" branch.
  • Changes are carefully merged into these branches after thorough testing and review, ensuring that only well-vetted code becomes a permanent part of the project's history.

2) Short lived branch:

  • Short lived branches are branches that are created for a specific, temporary purpose and are not intended to exist throughout the entire lifespan of the project. For example "feature_branch", "bug_fix_branch", "release_preparation_branch", "experiment_branch".

3) Master/Main branch:

  • The "master/main" branch is typically the default branch in a Git repository. It represents the stable, production-ready version of the code. Your main workspace where all the finished code lives.

4) Feature branch:

  • Developers create special areas to work on new things called "feature_branch". These branches are like special areas for working on new features without disturbing the main project.
  • Changes made in a "feature" branch can be brought back into the main project when ready. It's a way to keep everything neat and tidy while trying out and adding exciting features.
  • When we create a new "feature_branch", initially, the code on the "master" branch and this new "feature_branch" will be exactly the same. As you make updates and commit those changes to the "feature_branch", those updates are only visible in the "feature_branch". Similarly, when you make updates and commit changes to the "master" branch, those changes are only seen in the "master" branch.
  • Each branch keeps track of the changes made on that specific branch. The changes made in one branch are isolated to that branch until they are explicitly merged into another branch.

5) Bugfix branch:

  • These are used to fix specific bugs without affecting the main code. Similar to "feature_branch", "bug_fix_branch" are created off the master branch.

6) Developement branch:

  • The "development" branch serves as a central place where developers integrate their changes and collaborate on new features or improvements before these changes are merged into more stable branches, such as a "production" or "main/master" branch.

6) Integration/Staging branch:

  • "Integration/Staging" branch generally refers to a branch where different changes from various developement branches are brought together, integrated, and tested as a whole before being merged into a more stable branch or released into production.

7) Production branch:

  • "Production" branch refers to a long-lived branch that represents the stable and reliable version of the software that is deployed to the production environment.

8) Release branch:

  • These branches are created before releasing a new version for final testing. They are merged into both "master/main" and "development" branches once ready.

image

Branching strategies:

  1. Gitflow
  2. GitHub flow

1) Gitflow:

  • It is a branching model that defines specific roles for different branches.
  • Main branch -> Developement branch -> Feature branch -> Release branch -> Hotfix branch

2) GitHub flow:

  • It is a simplified and continuous delivery-oriented branching model.
  • Main branch -> Feature branch

Git Bash simplified:

1) Pushing local repository to GitHub account:

  • Open local project folder having project files in it and copy folder path
  • Open Git Bash and set username and email address
git config --global user."user_name"
git config --global email."email_address"
  • Check for present working directory in Git Bash
pwd
  • Change present working directory of Git Bash to the project folder path (copied folder path)
cd /e/copied_folder_path
  • Go to GitHub account and create a new repository (local and remote repository name can be differnet, doesn't have to be same) without initializing README file
  • Come back to Git Bash and run below command
git remote add origin https://github.com/user_name/remote_repo_name.git
git status
  • Stage, commit and push all the files to the remote repository
git add .
git commit -m "Commit message"
git push

2) Pushing changes madde in local repository to remote repository:

  • After making changes run below commands:
git add .
git commit -m "commit_message"
git push

3) Clonning remote repository from GitHub account to local machine:

  • Goto GitHub account and initialize a new repository with README file and copy the HTTPS web url
  • Open Git Bash, navigate to the desired path and run below command:
cd /e/
git clone copied_web_url

4) Pulling changes made in remote repository to local repository:

  • Open Git Bash, navigate to the local repository on your machine and run any of the below two commands in Git Bash:
git fetch origin
git merge
git pull
  • "git fetch" will check are there any new changes in remote repository which are not available in your local repository. It's more like counting how many changes are avialable.
  • Whereas "git pull" will fetch and merge/update local repository with all the aviable changes in remote repository.

image

5) Creating a new branch:

  • Open Git Bash, navigate to the project folder and run below commands:
pwd
cd /e/Project
git branch
git checkout -b bug_fix_branch
git branch
git checkout main
git checkout bug_fix_branch
  • When we create a new "bug_fix" branch, initially, the code on the "main/master" branch and this new "bug_fix_branch" will be exactly the same. As you make updates and commit those changes to the "bug_fix_branch", those updates are only visible in the "bug_fix_branch". Similarly, when you make updates and commit changes to the "main/master" branch, those changes are only seen in the "main/master" branch.

6) Merging branch or branch changes:

  • Merging in Git is the process of integrating changes from one branch, for example a "feature_branch" into another branch, for example "main/master" branch.
  • Run either of the below commands in Git Bash to review the differences between branches before merging:
git diff
git diff main..feature_branch
git diff feature_branch..main
git log -p feature_branch
  • Commit changes on your branch, push them to the remote repository.
git add .
git commit -m "commit message"
git push
  • Create a pull request to propose merging your changes into the target branch from GitHub.
  • Once the pull request is approved and merged, you typically delete the "feature_branch" and switch back to the "main/master" branch.
  • You can directly merge changes from "feature_branch" to "main/master" branch by running below Git command to bypass the process of review that pull requests facilitate:
git merge feature_branch
  • You can directly merge changes from "main/master" branch to "feature_branch" by running below Git command to bypass the process of review that pull requests facilitate:
git merge main
  • However, for collaborative projects or when changes need to be reviewed by others before being merged into the "main/master" branch, creating a pull request is the preferred workflow.
  • Pull requests allow for code review, discussion, and collaboration among team members, ensuring that changes are thoroughly vetted before being merged into the "main/master" branch.
  • In such cases, the merging typically occurs on the hosting platform (like GitHub) after the pull request has been approved.

7) Pull requests:

  • Pull requests are a way for team members to discuss and review code changes before they are merged into the "main/master" branch. They're like asking for a second opinion on your work.
  • For instance, when you finish working on a feature, instead of directly merging your code into the "main/master" branch, you create a pull request. This allows other team members to review your changes, provide feedback, and suggest improvements.
  • Once everyone agrees that the code looks good, the pull request can be approved and the changes are merged into the "main/master" branch. It's a collaborative way to ensure code quality and prevent mistakes from being introduced into the project.

image

8) Deleting branch:

  • If you've merged the changes from "bug_fix_branch" into another branch or "main/master" branch, and then deleted "bug_fix_branch" from the remote repository on GitHub, your local repository might still be tracking the branch. This can happen because Git keeps a local reference to the remote branches, untill you explicitly remove them locally.
  • To update your local repository and remove the reference to the deleted branch run below commands in Git Bash:
git fetch --prune
git branch -d bug_fix_branch
git branch
  • If you haven't merged "bug_fix_branch" yet and still want to delete the branch you may need to force delete it by running below command in Git Bash:
git branch -D bug_fix_branch

9) Undoing changes in Git:

  • If you accidentally added files to the staging area (that is "git add"), you can undo this to unstage the files, by running below command in Git Bash:
git reset
git reset file_name
  • If you make a mistake in a commit message or accidentally commit changes, you can undo the commits by running below command in Git Bash:
git reset HEAD~1
  • Here, "HEAD~1" refers to the previous commit. You can specify the number of commits to go back if needed.
  • To find the commit you want to reset to, run below command in Git Bash to view the commit history and find the commit hash (the unique identifier for each commit):
git log
  • Once you have the commit hash, run below command in Git Bash to reset to that specific commit. Be cautious as this will discard any changes made after that commit:
git reset --hard commit_hash

10) Merge conflicts:

  • Merge conflicts occur when Git is unable to automatically merge changes from different branches. This happens when multiple people modify the same part of a file, or when changes made in one branch conflict with changes made in another branch.
  • Merge conflicts arise when Git cannot determine which changes to keep because of overlapping same modifications in different branches.
  • There are couple of ways to resolve merge conflicts but the best way is to use Merge editor in VS Code:
  • Open the conflicted file(s) in a code editor(VS Code)
  • Locate the conflict markers (<<<<<<<, =======, >>>>>>>) and manually resolve the conflicting changes.
  • Save the files after resolving the conflicts.
  • Stage the resolved files using "git add" and then commit the changes using "git commit -m "commit message"".

image

  • If you encounter difficulties resolving conflicts, you can abort the merge by running below command in Git Bash to return to the pre-merge state:
git merge --abort
  • Merging locally wasn't the regular pattern because the "main/master" branch gets updated with changes from other contributors while you're working on your own branch.
  • It's crucial to stay up-to-date with these changes to avoid falling too far behind, making future merges more challenging. Therefore, it's recommended to regularly pull ("git pull") changes from the main branch into your local branch before merging ("git merge"). This ensures smoother integration of your work with the latest updates from the main branch.

11) Forking repository:

  • Forking a repository on GitHub means copying someone else's project to your own GitHub account. It allows you to experiment and contribute to projects without altering the original code. It enables you to contribute to open-source projects by making changes and suggesting improvements.
  • You can make changes, test new features, and fix bugs and if you want your changes to be part of the original project, you can create pull requests.
  • To fork a repository on GitHub, simply navigate to the repository you want to fork and click the "Fork" button in the top-right corner of the page.
  • Once forked, the repository will be copied to your GitHub account. You can access it from your account's repositories list.
  • After forking, you can make changes to the code, create branches, and experiment with the project as needed.
  • If you want your changes to be included in the original project, you can create pull requests from your forked repository to the original repository. The owner of the original repository can then review and merge your changes if they find them valuable.

Git commands:

Command Use
git config --list Used to list all the configuration settings in Git environment
git config --global user.name Used to check global username
git config --global user.name "user_name" Used to set glabal username
git config --global user.email Used to check global email address
git config --global user.email "email_address" Used to set glabal email address
git init To initialize the current directory as a git repository
git remote add <remote_name> <remote_url> To create a new connection of local repository to a remote repository
git clone <HTTPS_web_url> To clone a GitHub remote repository into a local machine
git add <file_name> To stage changes of single file for the next commit
git add -p To stage changes of all files for the next commit
git add . Allows you to review changes before staging file for the next commit
git commit -m "Your commit message here" To record the changes you've staged (using git add) into the Git repository
git commit -am "Your commit message here" Shortcut that combines the actions of both (git add). and (git commit -m "message" ) into a single command
git push Uploads the local commits you've made to the remote repository
git push origin <branch_name> Uploads the local commits you have made on a specific branch to the remote repository
git status List which files are staged, unstaged, and untracked.
git branch Lists all branches in your repository (* represents the current branch)
git checkout -b <branch_name> Create a new branch with specified branch name
git checkout <branch_name> Used to switch to a specified branch
git branch -d <branch_name> Used to delete a specified branch from your local repository
git branch -D <branch_name> Used to delete a specified branch from your local repository (if the branch contains unmerged changes)
git diff <branch_name1>..<branch_name2> Used to compare the difference between two branches in your Git repository
git merge <branch_name> Used to integrate/merge changes from a specified branch into the current branch
git merge --abort Used to abort a merge operation that is currently in progress ( if you encounter conflicts during a merge)
git log Displays the entire commit history
git log --oneline Displays the commit history in a condensed format, showing the commit hash and the commit message for each commit
git log -p branch_name Displays the commit history for a specific branch
git pull Used to fetch and integrate changes from a remote repository into the current branch in your local repository
git fetch Used to retrieve changes from a remote repository (it doesn't merge those changes)
git fetch --prune Retrieves new changes from the remote repository but also removes any local remote tracking branches that correspond to branches deleted on the remote repository
git reset <file_name> Used to unstage (git add) changes for a specific file
git reset HEAD~1 It resets the current branch to the state it was in before the last commit (git commit)
git reset --hard <commit_hash> Git resets your current branch and the staging area to match the specified commit
clear Clears command history in Git Bash
pwd Prints present working directory

Tips and Shortcuts:

  • To clear Git Bash history use (clear) and for terminal use (cls)
  • To paste copied text in Git Bash use (shift + insert)
  • Use (q) to jump off from Git Bash
  • To open terminal in VS Code use (ctrl + `)
  • For snipping tool use (windows + shift + s)

Useful resources:

First level heading

Second level heading

Third level heading

When you use two or more headings, GitHub automatically generates a table of contents that you can access.

Word or Word : Bold characters

  • Word * : Italic character word: Strikethrogh This text is extremely important: Bold and nested italic All this text is important :All bold and italic This is a subscript text: subscript This is a superscript text: Superscript

You can quote text with > Quoting code code To format code or text into its own distinct block, use triple backticks.

git status
git add
git commit

Syntax highlighting code

require 'redcarpet'
markdown = Redcarpet.new("Hello World!")
puts markdown.to_html

Here is a simple flow chart:

graph TD;
    A-->B;
    A-->C;
    B-->D;
    C-->D;
Loading

Creating links This site was built using GitHub Pages. You can also create a Markdown hyperlink by highlighting the text and using the keyboard shortcut Command+V.

You can define relative links and image paths in your rendered files to help readers navigate to other files in your repository. Contribution guidelines for this project

making list

  • George Washington
  • John Adams
  • Thomas Jefferson

order your list

  1. James Madison
  2. James Monroe
  3. John Quincy Adams

Nested list

  1. First list item
    • First nested list item
      • Second nested list item

To create a task list, preface list items with a hyphen and space followed by [ ]. To mark a task as complete, use [x].

You can mention a person or team on GitHub by typing @ plus their username or team name.

Adding emoji You can add emoji to your writing by typing :EMOJICODE: Typing : will bring up a list of suggested emoji. The list will filter as you type, so once you find the emoji you're looking for, press Tab or Enter to complete the highlighted result. :EMOJICODE🩹 https://github.com/ikatyang/emoji-cheat-sheet/blob/master/README.md

You can create a new paragraph by leaving a blank line between lines of text.

Alerts are a Markdown extension based on the blockquote syntax that you can use to emphasize critical information.

Note

Useful information that users should know, even when skimming content.

Tip

Helpful advice for doing things better or more easily.

Important

Key information users need to know to achieve their goal.

Warning

Urgent info that needs immediate user attention to avoid problems.

Caution

Advises about risks or negative outcomes of certain actions.

Microsoft AI 900, DP100, AI102

How to debug the python code in vscode

About

These are the handwritten notes on, how to set up an IDE, an introduction to Conda environment, how to use Git and GitHub for version control, and mathematics for data science.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published