psNotes.txt

TERMINOLOGY
	VERSION CONTROL SYSTEM (VCS) / SOURCE CODE MANAGER (SCM):
		A VCS is a tool that manages different versions of source code. A SCM is another name for version control system.
		Git is a VSC.

	COMMIT:
		A snapshot of the saved state of the project in Git.
		Every time you commit, Git basically takes a picture of what all the files look like at that moment and stores its reference.

	REPOSITORY / REPO:
		A directory which contains the project work, as well as few files used to communicate with Git.
		It is made up of commits.

	WOKRING DIRECTORY:
		The files present in the the computer's file system.
		This is different from the command line's concept of the current working directory.

	CHECKOUT:
		When content in the repository has been copied to the Working Directory.

	STAGING AREA / STAGING INDEX / INDEX:
		A file in the Git directory that stores information about what will go into the next commit.
		Files in the staging area are assured to be committed or added to the Git repository.

	SECURE HASH ALGORITHM (SHA):
		A unique, 40-characters string, ID number for each commit.

	BRANCH:
		When a new line of development is created that diverges from and without altering the main line of development.

git init COMMAND:
	Command used for creating a new repository in the current directory.
	init stands for 'initialize'.
	This command sets up all the necessary files and directories that Git will use to keep track of everything, which are stored in .git hidden directory.

	.git Directory Contents:
		- config file (where all project specific configuration settings are stored)
		- description file (used for GitWeb program)
		- hooks directory (where to place client-side or server-side scripts used to hook into Git's different life cycle events)
		- info directory (contains global excludes file)
		- objects directory (stores all of the commits made)
		- refs directory (holds pointers to commits, basically branches and tags)

git clone COMMAND:
	Command used to create an identical copy of an existing repository.
	syntax: git clone <path-to-repository-to-clone>
	This command:
		- takes the path to an existing repository
		- by default will create a directory with the same name as the repository that's being called
		- can be given a second argument that will be used as the name of the directory (git clone <path-to-repository-to-clone> new-directory-name)
		- will create a new repository inside the current working directory

git status COMMAND:
	Command used to display the current status of the repository.
	It will:
		- display new files that have been created in the working directory that Git hasn't started tracking yet
		- display files that Git is tracking that have been modified
		- display other useful information depending on the state of the files, the working directory, and the repository

git log COMMAND:
	Command used to display all the commits of a repository.
	By default, it displays the SHA, the author, the date, and the message of every commit in the repository. It can display a lot more information.
	git log FLAGS:
		- git log --oneline (used to alter how git log displays information). This command lists one commit per line, shows the first 7 characters of the commit's SHA, shows the commit's message
		- git log --stat (used to display the files that have been changed in the commit, as well as the number of lines that have been added or deleted). It also displays a summary line with the total number of modified files and lines that have been added / removed
		- git log -p / --patch (used to display the files that have been modified, the location of the lines that have been added / removed, the actual changes that have been made)
		- git log --decorate (displays more information on the log output such as tags, branches as well as which branch HEAD is pointing to)
		- git log --graph (add bullets and lines to the leftmost part of the output showing the actual branching that's happening)
		- git log --all (displays log output with all the branches in the repository)
	Supply these commands with a commit's SHA to display information that start at that commit. (git log -p 8fd5759; git log --stat f226b38; git log --oneline 6617a39)
	Supply these commands as well with branches names to display information about the branches. (git log --oneline --graph branch_one branch_two)

git show COMMAND:
	Command used to view information about a specific commit.
	git show alone will display information about the most recent commit. Provide it with a commit's SHA to view information about that commit.
	This command displays the commit, the author, the date, the commit message, and the patch information.
	git show FLAGS:
		- git show --stat (shows how many files were changed and the number of line that were added / removed)
		- git show -p / --patch (default display)
		- git show -w (displays changes made and ignores changes to whitespace)
	Running git show <tag_name> will display annotated tag's information along with the commit that was created (running this on a lightweight tag will only display the commit's information).

git add COMMAND:
	Command used to move files from the working directory to the staging area.
	Syntax: git add <file1> <file2> ... <fileN>
	This command takes a space-separated list of file names and adds them to the staging index.
	Running 'git add .' will stage the current directory and all nested files.

git commit COMMAND:
	Command used to take files from the staging index and save them in the repository.
	Running this command will open the code editor specified in your configuration. Inside the code editor, a commit message must be supplied, lines that start with a '#' are comments and will not be recorded, save the file after adding a commit message, close the editor to make the commit.
	Keep commit messages short, consistent, and explain what the commit does.
	git commit FLAGS:
		- git commit -m "<commit_message>" (create a commit with inline commit message)
		- git commit -a (add and commit all changed files, same as (git add .; git commit))
		- git commit --amend (used to alter the most recent commit, provide a new commit message, add forgotten file(s) to commit. The code editor will open up and display the original commit message.)
		To add forgotten file(s) to the recent commit: edit the file(s), save the file(s), stage the file(s), run git commit --amend to update the most recent commit
	
	git revert COMMAND:
		Command used to reverse a previously made commit.
		Syntax: git revert <SHA_of_commit_to_revert>
		This command will undo the changes that were made by the provided commit, then create a new commit to record the change.

Relative Commit References:
	Reference a commit relative to another commit.
	Ancestry References (special characters used to tell Git about these relative references):
		- '^' (indicates the parent commit)
		- '~' (indicates the first parent commit)
	How to refer to previous commits:
		To indicate the parent commit of the current commit (HEAD^, HEAD~, HEAD~1)
		To indicate the grandparent commit of the current commit (HEAD^^, HEAD~2)
		To indicate the great-grandparent commit of the current commit (HEAD^^^, HEAD~3)
	With a merge commit, the '^' reference is used to indicate the first parent (branch HEAD was pointing at when the merge was made) of the commit, while '^2' indicate the second parent (branch that was merged in).

	git reset COMMAND:
		Command used to erase (reset) commits.
		Syntax: git reset <reference_to_commit>
		It can be used to: move the HEAD and current branch pointer to the referenced commit; erase commits; move committed changes to the staging index; unstage committed changes
		git reset FLAGS:
			- git reset --mixed (unstage changes made after referenced commit, will take the changes and move them to the working directory) git reset by default
			- git reset --soft (stage changes made after referenced commit, will take the changes and move them to the staging index)
			- git reset --hard (erase changes made after referenced commit)
				Always be careful while using this command.

git diff COMMAND:
	Command used to see changes that have been made but haven't been committed yet.
	Running this command will display the files that have been modified, the location of the lines that have been added / removed, the actual changes that have been made.
	git diff alone will compare changes made between the working directory and the staging index.
	This command can also be used to compare and see changes made between commits.
	Running git diff <SHA_first_commit> <SHA_second_commit> will compare changes made between the specified commits.
	Running git diff --staged will compare changes made between the staging area and the most recent commit.

.gitignore FILE:
	File used to tell Git about the files that Git should not track. This file should be placed in the same directory that the .git directory is in.
	Git will not track files listed in .gitignore.
	Check out the concept of globbing on how to list multiple files in .gitignore at once.

git tag COMMAND:
	Command used to add a marker on a specific commit. The tag does not move around as new commits are added.
	Syntax: git tag -a <tag_name> (create an annotated tag with the -a flag)
			git tag <tag_name> (create a lightweight tag)
	Annotated tags are recommended because they include a lot of extra information (the person who made the tag, the date the tag was made, a message for the tag).
	Running git tag will display all tags that are in the repository.
	git tag FLAGS:
		- git tag -a <tag_name> (creates an annotated tag)
		- git tag -a <tag_name> -m <tag_message> (creates annotated tag and specifies a tagging message)
		- git tag -d <tag_name> (deletes a tag from local repository)
		- git tag -l / --list (lists the existing tags)
	Specify the SHA to add a tag to a specific commit.

git branch COMMAND:
	Command used to interact with Git's branches.
	Running git branch will list out the branches in the repository and show the active branch.
	A branch is used to do development or make a fix to the project that won't affect the project (since the changes are made on a branch).
	Once the changes are made on the branch, it can be combined into the master branch (merging).
	Syntax: - git branch <branch_name> (creates a branch)
			- git branch <branch_name> <commit_SHA> (creates a branch and have it point to the specified commit's SHA)
			- git branch -d <branch_name> (deletes a branch once changes have been merged)
			- git branch -D <branch_name> (forces deletion of a branch)
	Git will not delete a branch if HEAD is currently pointing to it.
	Git will not delete a branch if it has commits on it that aren't on any other branch.
	To switch between branches, use git checkout <branch_name> command.
	Running git checkout -b <branch_name> will create a branch and switch to it at the same time (git branch <branch_name>; git checkout <branch_name>). Look out for more information on git checkout COMMAND.

git merge COMMAND:
	Command used to combine Git branches.
	Syntax: git merge <name_of_branch_to_merge_in>
	When a merge happens, Git will:
		- look at the branches that it's going to merge
		- look back along the branch's history to find a single commit that both branches have in their commit history
		- combine the lines of code that were changed on the separate branches together
		- make a commit to record the merge
	Two types of merges:
		- Fast-forward merge (the branch being merged in must be ahead of the checked out branch. The checked out branch's pointer will just be moved forward to point to the same commit as the other branch)
		- Regular merge (two different branches are combined; a merge commit is created)
	Merge conflicts:
		When a merge fails, it's called a merge conflict.
		A merge conflict will happen when the exact same line(s) of a file is(are) changed in separate branches.
		When a merge conflict occurs the merge output will show the word 'CONFLICT' and the file(s) in which the merge conflict occurred (opening the file(s) in a code editor will show the merge conflict indicators).
	Merge conflicts indicators:
		- <<<<<< HEAD (everything below this line until the next indicator shows what's on the current branch)
		- ||||||| some_message (everything below this line until the next indicator shows what the original lines were)
		- ======= (the end of the original lines, everything that follows until the next indicator is what's on the branch that's being merged in)
		- >>>>>>> branch_name (the ending indicator of what's on the branch that's being merged in)
		A file might have merge conflicts in multiple parts of the file, make sure to check the entire file for merge conflict indicators.
	To resolve a merge conflict: choose which line(s) to keep, remove all lines with indicators, save the file, add it to the staging index and commit it.
	git merge FLAGS:
		- git merge --abort (restore the files to their state before the merge started)

git checkout COMMAND:
	Command used to switch between branches or restore working tree files.
	It can also be used to switch between commits.
	Running git checkout <SHA_of_commit> will make HEAD point to the specified commit (detached HEAD).
	git checkout <branch_name> (switches to specified branch, HEAD points to <branch_name>)
	git checkout FLAGS:
		- git checkout -b <branch_name> (create a branch and switch to it)
		- git checkout -f / --force (when switching branches, discards local changes)
		- git checkout --orphan <branch_name> (create an orphan branch and switch to it)
		- git checkout -B <branch_name> (create a branch and switch to it, if it already exists then reset it to the commit at which it starts)

git remote COMMAND:
	Command used to view and create remotes.
	- git remote (show currently added remotes to the repository)
	- git remote add <remote_name> <remote_url> (adds a remote repository). If there is only one remote, it's standard to name it 'origin'
	- git remote -v / --verbose (shows the remote URL after its name)
	- git remote rename <old_remote_name> <new_remote_name> (rename old_remote_name to new_remote_name)
	- git remote remove / rm <remote_name> (remove remote <remote_name>. all remote-tracking branches and configurations settings for the remote are removed)
	- git remote show <remote_name> (show more information about a particular remote)

git push COMMAND:
	Command used to upload local repository content to a remote repository.
	This is how you transfer commits from local repository to a remote repository.
	- git push <remote_name> <local_branch_to_push> (pushes the specified local branch to the specified remote along with all the necessary commits and internal objects)
	- git push <remote_name> -f / --force (forces the push even if it results in a non-fast-forward merge. Use it with care)
	- git push <remote_name> --all (pushes all local branches to the specified remote)
	- git push <remote_name> --tags (pushes all local tags to the remote)
	- git push <remote_name> -d / --delete <remote_branch_name> (deletes specified remote branch from specified remote)
	- git push <remote_name> --prune <remote_branch_name> (removes specified remote branch from specified remote if a local branch with the same name does not exist anymore)

git pull COMMAND:
	Command used to fetch and download content from a remote repository and update the local repo to match that content.
	- git pull <remote_name> <remote_branch_name> (pulls content from specified remote branch on specified remote into local repository)

	git pull <remote_name> <remote_branch_name> = git fetch <remote_name>/<remote_branch_name> ; git merge <local_branch_name> <remote_name>/<remote_branch_name>

git fetch COMMAND:
	Command used to update local copy of remote repository.
	This is used when there are changes on remote repository but have not been added to the local copy of the remote.
	Mostly used when changes have been made both on the local repository and on the remote repository.
	- git fetch <remote_name> (updates all local copies for every remote branch on specified remote)
	- git fetch <remote_name> <remote_branch_name> (updates local copy of specified remote branch on local remote)
	- git fetch --all (updates all local remotes and their branches)
	- git fetch --dry-run (performs a demo run of the command. Show what would be done during the fetch without making any changes)
	Local copies of remote branches are specified by <remote_name>/<remote_branch_name>
	After updating local copies for remote branches of local remote, they can be merged with local branches of local repository by running git merge local_branch_name <remote_name>/<remote_branch_name>
	And then push changes to the remote repository by running git push <remote_name> <branch_name_to_push>

WRITING READMEs
	Anatomy of READMEs:
		A README should provide just enough context to get a user up and running with the code.
		Communicate clearly and concisely any information that is essential for the user.
		- Title and Description (capture the spirit of your project clearly and concisely; the project's logo could also be included)
		- Any information that is absolutely necessary for understanding the code: i.e. dependencies on the software libraries, installation instructions, common usage, known bugs

		There is no formal standard for what a README should look like.

		Quick questions to ask oneself when writing READMEs include:
			- What steps need to be taken?
			- What should the user already have installed or configured?
			- What might they have a hard time understanding right away?

	No matter how large or small the project, include copyright or licensing information when allowing others to contribute to the project.
	Choose to include the full license in the README or link out to it from the README.
	Include in the README preferred ways for others to contribute to the project.

	Readable READMEs with Markdown:
		Markdown is a light language often used for READMEs. It lets you generate well formatted READMEs by translating them into HTML.
		GitHub combines a syntax of formatting text called GitHub Flavored Markdown with a few unique features. 
		Basic Markdown Syntax:
			- to make text bold, surround it with double asterisks ( **this in bold**)
			- to italicize text, surround it with underscores (_this in italic_)
			- to indicate text as an inline code, surround it in backticks (`inline code`)
			- for title sequence i.e. h1 through h6, include a # before the text. The number of #s you include tells which header tag being used (# this is h1; ## this is h2; ### this is h3)
		Explore more ways to write beautiful READMEs on https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/getting-started-with-writing-and-formatting-on-github

		Markdown files should be saved with a .md extension. Files could be previewed by Dillinger (https://dillinger.io) online markdown editor,