added files

Author: aayush301

1-intro.txt

@@ -0,0 +1,27 @@
+Configure Git
+git config --global user.name "xyz"
+git config --global user.email "xyz@gmail.com"
+git config --global --edit
+
+Initialize Git
+git init
+
+git status		// check the status of all files.
+
+Files in Git Repository Folder can be in one of 2 states:
+1. Tracked: Files that Git knows about and are added to repository.
+2. Untracked: files that are in working directory, but not added to repository.
+
+
+Git = Working directory(or working tree) + Staging index + Repository
+
+
+
+// help
+git <command-name> -help	// see all available options for specific command
+git <command-name> --help	// opens Git Manual page for specific command
+git help --all				// list all possible commands
+
+
+Use Shift+G to jump to the end of the list.
+Use q to exit the view.

branch.txt

@@ -0,0 +1,9 @@
+git branch xyz			// will create new branch xyz
+git branch				// will list all non-remote branches
+git branch -r			// will list all remote branches
+git branch --all		// will list all branches (non-remote + remote)
+git branch -d xyz		// will delete branch (you have to be in other branch)
+
+git checkout xyz		// switch to branch xyz
+git checkout -b xyz		// causes a new branch to be created and then checked out.
+git merge xyz			// will merge xyz branch into current branch.

checkout.txt

@@ -0,0 +1,15 @@
+Main function: Switch branches or restore working tree files.
+
+git checkout <branch>
+		// HEAD now points to <branch>. Local modifications to the files in the working tree are kept, so that they can be committed to the <branch>.
+
+git checkout -b <new_branch>
+		// It causes a new branch to be created and then checked out, if it doesn't exist.
+		// If it exists, then error occurs.
+
+git checkout -B <new_branch>
+		// <new_branch> is created if it doesn’t exist; otherwise, it is reset.
+		// Eq. of: git branch -f <branch>; git checkout <branch>;
+
+git checkout <commit>
+		// Head gets detached to commit

commit.txt

@@ -0,0 +1,9 @@
+Commit creates a checkpoint in repository.
+We should always include a message when we commit.
+
+git commit -m "updated files"
+
+git commit -a -m "updated files"
+	// -a will tell the command to automatically stage and then commit files that have been
+	// modified and deleted in working tree (by doing git add and git rm and then commit),
+	// but new files you have not told Git about are not affected.

diff.txt

@@ -0,0 +1,9 @@
+git diff			// show changes between working tree and staging index.
+git diff HEAD		// show changes between working tree and last commit.  (What we would be committing if we run git commit -a)
+git diff --cached	// show changes between staging index and last commit. (What we would be committing if we run git commit)
+git diff --staged	// same as above
+
+git diff <commit1> <commit2>	// show changes between the two commits
+git diff HEAD^ HEAD
+					// compare the version before the last commit and the last commit
+					// (same as git show)

log.txt

@@ -0,0 +1,11 @@
+To view the history of commits
+
+git log
+git log	<branch>		// logs the commits for only <branch>
+git log -5				// limit the no. of commits
+git commit --oneline	// condenses each commit to a single line
+git log -p				// display full diff of each commit
+git log --graph			// Draw a text-based graphical representation of the commit history on the left hand side of the output.
+git log --all --graph 	// Draw graph having commits of all branches.
+git log --all --oneline --graph 	// Draw graph having commits of all branches in one line each.
+git log --author="<pattern>"	// Search for commits by a particular author.

remotes.txt

@@ -0,0 +1,43 @@
+3 types of branches:
+1. local branches (stored locally) (e.g. main)
+2. remote branches (stored at remote) (e.g. main)
+3. local copies of remote branches (stored at locally) (e.g. origin/main)
+
+For example, if at the remote, we have main branch and x branch, then locally, along with local main branch and local x branch, we also have origin/main branch and origin/x branch.
+These branches (type 3) get updated at the time of pulling/pushing only and they convey the info. about latest commits pushed/pulled.
+
+Suppose that currently the local main branch and remote main branch are at sync.
+Now, consider 3 cases:
+
+Case 1: We make a commit on local main branch.
+In this case, the local main branch gets updated to point to the new commit.
+But, neither the local origin/main branch nor the remote main branch gets updated.
+However, when we push the main branch to origin, both the local origin/main branch and the remote main branch gets updated to point to the new commit.
+
+
+Case 2: The remote main branch gets a new commit.
+In this case, the remote main branch gets updated to point to new commit.
+But, neither the local main branch nor the local origin/main branch gets updated.
+However, when we pull the main branch from origin, both the local main branch and the local origin/main branch gets updated to point to the new commit.
+
+
+Case 3: We make a commit (say c1) on local main branch and we also make some other commit (say c2) on remote main branch.
+In this case, the local main branch gets updated to point to commit c1, the remote main branch gets updated to point to commit c2.
+But, local origin/main branch doesn't get updated.
+
+Now, pushing or pulling require merging. It may cause merge conflicts which may be needed to be resolved.
+Hence, it is safer to use git fetch here.
+
+First use [git fetch origin] command which will just update local copy of remote branch (i.e. origin/main). This means that local origin/main branch will point to commit c2.
+Now, the local main branch will point to commit c1, the local origin/main branch to commit c2, and the remote main branch to commit c2.
+Now, we require to merge local origin/main branch into local main branch.
+We can run merge command to merge here.
+Note that we could also run git pull command instead of fetch then merge, since fetching + merging is equivalent to pulling, but then if any merge conflicts arise, then we need to resolve the conflicts as well.
+git pull origin main = git fetch origin + git merge main origin/main
+
+Now, our local main branch is pointing to merged commit (say c3) and local origin/main branch and remote main branch are pointing to commit c2.
+Now, we can push the main branch which will update both the local origin/main branch and remote main branch to point to commit c3.
+Now, all the 3  branches (local main, local origin/main and remote main branch) are at sync with each other.
+
+
+

reset.txt

@@ -0,0 +1,10 @@
+git reset --soft <commit>
+		// resets the current branch head to <commit>. Does not touch the staging index or the working tree at all.
+
+git reset <commit> OR git reset --mixed <commit>
+		// resets the current branch head to <commit>. Resets the index but not the working tree.
+
+git reset --hard <commit>
+		// resets the current branch head to <commit>. Resets the index and working tree.
+
+<commit> defaults to HEAD in all forms.

restore.txt

@@ -0,0 +1,17 @@
+Restore specified paths in the working tree with some contents from a restore source.
+
+git restore --staged <file_name>	
+		// restore file in staging index to match last commit.
+		// This is same as git reset
+
+git restore <file_name>	
+		// restore file in working directory to match the staging index.
+
+git restore --staged --worktree <file_name>
+		// restore file in both the working tree and the index directly to match last commit.
+		// This is same as git reset --hard
+
+git restore --source <source> <file_name>
+		// restore file in working directory to match the contents of source.
+		// Ex. of source: 6ba66ca, Head~2, etc.
+		

rm.txt

@@ -0,0 +1,6 @@
+Remove files from the staging index, or from both working tree and the index.
+It will remove only those files that are known to git.
+
+git rm file.txt		// remove file from both working tree and index (index should be up to date)
+git rm --cached file.txt	// unstage and remove paths only from index.
+

show.txt

@@ -0,0 +1,5 @@
+git show	// to show the changes between last two commits
+			// same as git show HEAD
+			// same as git diff HEAD^ HEAD
+
+git show <commit> // to show the changes between <commit> and its parent

staging.txt

@@ -0,0 +1,14 @@
+Staged files are files that are ready to be committed to the repository.
+Staged files are added into staging index.
+The "staging index" holds a snapshot of the content of the working directory,
+	and it is this snapshot that is taken as the contents of the next commit.
+	Thus after making any changes to the working directory, and before running the commit command,
+	you must use the add command to add any new or modified files to the index.
+
+
+
+git add file.txt						// To stage a file
+git add --all  OR  git add -A			// To stage all files
+git add -i  OR  git add --interactive	// Add modified contents in the working tree interactively to the staging index.
+
+