Git Notes

Basic Git Syntax:
	git [commands] [--flags] [arguments]

Examples:
	git --version
	git status
	git status --short
	git add .

Getting Help:
	Particular Command help:
		git help [command]
	
	Overall Help:
		git help #
		git help 
		git
		
	Concise Help:
		git [command] -h
		
	Example:
		git help init
		git help # (overall help)
		or
		git (displays overall git helps)

		*Get Consise Help: [-h]
		git init -h 


READING HELP:

	-f or --flag	=> change the command's behavior
	|            	=> Or
	[optional]   	=> optional
	<placeholder>   => placeholder
	[<optional placeholder>] => optional placeholder
	()  	=> Grouping
	--      => Disambiguates the command
	...     => multiple occurances possible

	Example:
		git fakecommand (-p|--patch) [<id>] [--] [<paths>...]


SETTING YOUR USERNAME AND EMAIL AND EDITOR:

	git config [--local | --global | --system] <key> [<value>]


	a) No flag or --local  =>  applies only to the current repository (highest precedence)
	b) --global            =>  applies to every repository that you use on your computer
	c) --system            =>  applies to every repository for all users on your computer

	Example: 
		Configure your user name, email address and default Git editor.
		1. View your current setting for your user name with
			>> git config user.name .
		
		2. If you would like to change your user name, use
			>> git config --global user.name "Your Name" .
		
		3. View your current setting for your email address with
			>> git config user.email .
		
		4. If you would like to change your email address, use
			>> git config --global user.email "your@email" .
		
		5. View your current setting for default Git editor with
			>> git config core.editor .
		
		6. If you would like to change your default Git editor, use
			>> git config --global core.editor your_preferred_editor


GIT LOCATIONS:

	working tree -> staging area -> local repository -> remote repository

	1) workinig tree  => a single commit's directories and files
	2) staging area   => files that are planned for the next commit
	3) local repository: => contains the commits of the project
	4) project directory => above 3 repository
	5) remote repository => contains the commits of the project


CREATING A LOCAL REPOSITORY USING COMMAND LINE:
	
	git init - (initialize or create a repository)

	Example: 
		mkdir training
		cd training
		mkdir myproj
		cd myproj
		git init //Initialized empty git repository in myproj/.git/
		ls -a //will show .git generated file
		


COMMANDS TO COMMIT IN LOCAL REPOSITORY

	git status => to view status of files in the working tree and staging area
	
	eg: 
		git status
			or
		git status -s [in short]
	
	git add <file-or-directory> => add to staging area
	
		eg:
			git add fileA.txt
				or
			git add dirA dirB (add all files under these directories)
				or
			git add . (add all untracked files)

	

	git commit -m "message"

	view commit history:
		git log
			or
		git log --oneline [--oneline means condensed version of the log]
			or
		git log --oneline -2 [to view only last 2 commits]

	TO UNSTAGE OR UNTRACK A STAGED FILE
		
		git rm --cached fileA.txt

	TO UNSTAGE A STAGED DIRECTORY:
		
		git rm --cached -r dirA


TO DISPLAY INFORMATION ABOUT REMOTE REPOSITORY ASSOCIATED WITH THE LOCAL REPOSITORY:
	
	git remote --verbose
		or
	git remote -v 

ADDING A REMOTE REPOSITORY TO A LOCAL REPOSITORY
	
	git remote add <name> <url>
	
	eg:
		git remote add origin https:bitbucket/url.git


CLONE: 
	A Clone is a local copy of remote repository
	
	git clone <repository-url>
		or
	git clone <url/to/repository.git> [localProjectName] 



PUSH THE COMMIT IN REMOTE REPOSITORY:=======

	//STEPS
	//do changes 
	//stage changes [git add <>]
	//commit changes [git commit -m "message"]
	//Now push the changes


	1)	git push [-u] [<repository>] [<branch>]
	
		here:
		<repository> can be name(shortcut) or url 
				eg: origin
		-u track this branch (--set-upstream)


	Example:
		
		git push -u origin master 
			. The -u flag sets up the local and remote branches as tracking branches. 
			. origin is a shortcut name for the remote repository. 
			. master is the branch to push. We are pushing the default branch named master .
	
		git status 
			. TO verify that your branch is up to date and there is nothing to commit.
			
		git log --oneline --graph 
			. To log git with graph option

GIT OBJECTS:===============

	Commit         =>  A small text file 
	Annotated tags =>  A permanent reference to a commit
	Tree           =>  Directories and filenames in the project
	Blob           =>  The content of a file in the project

GIT ID:=====
	. The name of  a git object is called git ID
	. 40 characters hexadecimal string
	. Also known as git ID, object ID, SHA-1, hash and checksum

SECURE HASH ALGORITHM (SHA-1): 
	.Git ids are SHA-1 values
	. Unique for a given piece of content
	example:
		1af751ec24aOb99f8cb3984....
	
	git log 

SHORTENED GIT IDS:=========
	The fist portion(4 or more chars) of the git ID
	eg: 
		1af751e
	
	git log --oneline [will show the shortened id]


NOTE: 
	Use: 
		git hash-object <file> 
			to create a SHA-1 for any content
		eg:
			git hash-object fileA.txt


VIEW A PARTICULAR HASH GIT :
	
	git show <shortened-hash>

	eg:
		git show bff5468

GIT REFERENCES :===============

	User-friendly name that points to:
		. a commit sha-1 hash
		. another reference
		. known as symbolic reference
		
	[git log --online]	
		
BRANCH LEBEL:====================
	. Points to the most recent commit in the branch
	. The "tip of the branch"
	. Implemented as a reference

HEAD:===================
	. A reference to the current commit
	. Usually points to the branch label of the current branch
	. One HEAD per repository
		git show HEAD

APPENDING TILDE(~) TO GIT IDS AND REFERENCES:======
	.Refers to a prior commit
		. ~ or ~1 => parent
		. ~2 or ~~ => parent's parent
	
	Eg:
		git show HEAD
		git show HEAD~
		git show master~3
		git show e0cb6c5~~~
	
	
APPENDING CARET(^) TO GIT IDS AND REFERENCES:=====
	.Refers to a parent in a merge commit (^parentnum):
		. ^ or ^1 => first parent of the commit
		. ^2  => second parent of a merge commit
		. ^^  => first parent's first parent
	
		Eg:
			git show master^
			git show HEAD^2
			git show HEAD^^
	


* TAG :===================
	. Tag is a reference/label attached to a specific commit

	. Lightweight Tag: 
		. A simple reference to a commit
	
	. Annotated Tag:
		. A full Git object that references a commit
		. Includes tag author information, tag date, tag message, the commit ID
		. Optionally can be signed and verified with GNU Privacy Guard (GPG)

	NOTE: Tags can be used instead of branch labels or Git IDs in Git commands
	
	VIEW ALL TAGS:
		
		git tag

	SHOW A PARTICULAR TAG:
		
		git show v1.0

	*CREATING A LIGHTWEIGHT TAG: 
		git tag <tagname> [<commit>]
		<commit> defaults to HEAD
	
		Eg:
			git tag v1.0 [tag the current commit]
			git tag v0.1 HEAD^ #[tag the previous tag]

	*CREATING AN ANNOTATED TAG:----
		git tag -a [-m <msg> | -F <file>] <tagname> [<commit>]
		<commit> defaults to HEAD

		Eg:
			git tag -a -m "include feature 2.0" v2.0
	
* TAGS AND REMOTE REPOSITORIES:=============
	.git push does not automatically transfer tags to the remote repository
	
	. To transfer a single tag:
		git push <remote> <tagname>
	
	. To Transfer all of your tags
		git push <remote> --tags

	.To delete a tag:
		git tag -d v1.0
	
	
GIT BRANCHES:======================
	. The set of commits that trace back to the project's first commit is called branch
	. Fast and easy to create
	. Enable experimentation
	. Enable multiple team development
	. Support multiple project versions

	.TOPIC BRANCHS:--
		. A feature, a bug fix, a hotfix, a configuration change, etc

	.Long-Lived BRANCHES:---
		. master, develop, release, etc

	*VIEWING BRANCHES:===
		.To see a list of branch:
			git branch

	*CREATING A BRANCH:
		git branch <name>
	
BRANCH CHECKOUT:============
	. Updates the HEAD reference
	. Update the working tree with the commit's file
	
	. To checkout a branch:
		git checkout <branch_or_commit>

	.To Create and checkout a branch:
		git branch featureX
		git checkout featureX

	.To checkout and create with single command:
		git checkout -b featureX
	
	NOTE: next commit will be made to the branch having the HEAD of checkedout

*DETACHED HEAD:===========
	 . Checking out to a commit leads to detached HEAD
	 . To come back to normal checkout with any branch
 
*DELETING A BRANCH LABEL:======
	. To delete a branch:
		git branch -d <branch>

	.To FORCEFULLY delete a branch use capital D:
		git branch -D <branch>

	eg:
		git branch -d featureX
		git branch -D featureX

*DANGLING COMMITS:====
	* If a commit is not merged yet but tried to delte its branch
	
*UNDOING AN ACCIDENTAL BRANCH DELETE:
	git reflog
	
	=>Above command returns a local list of recent HEAD commits
	
	=> After that checkout to the branch as:
		git checkout -b featureX <git-id>
	
	eg:
		git checkout -b featureX b62cbf8
	
========MERGING=================
	=> topic-branch
	=> base-branch

FOUR MAIN TYPES OF MERGING:====
	1) Fast-forward merge
	2) Merge commit
	3) Squash merge
	4) Rebase

1) FAST-FORWARD(FF) MERGE:============
	=> A FF moves the base branch label to the tip of the topic branch

	=> Conditions for FF merge:
		* Possible iff no other commits have been made to the base branch since branching
	
	=>STEPS TO PERFORM FF MERGE:
		A) git checkout master 
		B) git merge featureX 
			[attempting a fast forward merge in the default]
		C) git branch -d featureX 
			[deleting the branch]
			
		[it may not add additional commit after merge]
 
2) MERGE COMMIT:============
	=> Combines the commits at the tips of the merged branches

	=> Places the result in the merge commit

	=>STEPS FOR PERFORMING A MERGE COMMIT:---
		A) git checkout master
		B) git merge --no-ff featureX
			[accept or modify the merge message/may get conflicts]
			or
		   git merge featureX -m "commit-message"
		C) git branch -d featureX
		
		
	==>PERFORMING A MERGE COMMIT (NO FAST-FORWARD)
		A) git checkout master
		B) git merge --no-ff featureX
			[accept or modify the merge message]
		C) git branch -d featureX
		D) git log --oneline --graph --all
		
==>> TEAM COMMIT HISTORY POLICIES:========
	. Require a linear history
	. Require merge commits
	. Let the person merging decide

==>> AVOIDING MERGE CONFLICTS:
	 . Git merges are usually quite easy
	 . Small, frequent merges are the easiest 

	
***RESOLVING MERGE CONFLICTS================
	. Merge conflicts occur when a person needs to make a decision
	. Merge conflicts only occur if the same file is changed
	. merges changes to different parts (hunks) of files - not a merge conflict - auto resolved

	==>STEPS INVOLVE THREE COMMITS:	
		. The tip of the current branch (B) - "ours" or "mine"
		. The tip of the branch to be merged(C) - "theirs"
		. A common ancestor(A) - "merge base"

	==> BASICS STEPS TO RESOLVE A MERGE CONFLICT:====
		1) Checkout master
		2) Merge featureX
			a. CONFLICT - Both modified fileA.txt
		3) Fix fileA.txt
		4) Stage fileA.txt
		5) Commit the merge commit
		6) Delete the featureX branch label
	
	NOTE: when attempting a merge, files with conflicts are modified by 
			Git and placed in the working tree
		
	Eg:
		git log --oneline --graph --all
		git merge featureX [To merge]
		git status [To check conflicted files]
		## fixing the conflicts: [open file in text editor]
		cat fileA.txt
		git add fileA.txt
		git commit
	
	
	==>CONFLICTS HUNKS:
		. conflicts hunks are surrounded by conflict markers <<<<<<<< and >>>>>>>>
		. <<<<<<<<<< HEAD
		. feature 3 [from ours]
		. ===========
		. feature 2 [from theirs]
		. >>>>>>>>>>> feature2 [comes from feature2 branch]

	**READING CONFLICT MARKERS:=========
		
		. Text from the HEAD commit is between <<<<<<<<<<<< and =============
		. Text from the branch to be merged is between ========= and >>>>>>>>


**TRACKING BRANCH:========
	.A local branch that represents a remote branch <remote>/<branch>
	
	.VIEW TRACKING BRANCH NAMES:
		. git branch --all
			[Displays local and tracking branch names]
		
		. git branch 
			[shows only local branch]

	NOTE: 
		remotes/origin/HEAD : specifies the default remote tracking branch
		Allows <remote> to be specified instead of <remote>/<branch> in Git commands
	
**CHANGING remotes/origin/HEAD:===
	
	.Change the default remote tracking branch with :
		git remote set-head <remote> <branch>

	Eg:
		git branch --all
		git remote set-head origin featureX

** VIEWING TRACKING BRANCH STATUS : 
	git status 
		[will inform you if the cached tracking branch is out of sync with your local branch]
	
	git log --all 
		[to see a combined log of all local and tracking branch]
	
===================NETWORK COMMANDS==============================
	CLONE : Copies a remote repository
	FETCH : Retrieves new objects and references from the remote repository
	PULL :Fetches and merges commits locally
	PUSH :  Adds new objects and references to the remote repository

========FETCH==============
	. Retrieves new obje and reference from another repository
	. Tracking branches are updated
		. git fetch <repository>
		
	. After git fetch, git status will inform you that your current branch is behind the tracking branch:
		. git status
	
	eg:
		git fetch
		git status
	
========PULL================
	. Combines git fetch and git merge FETCH_HEAD
	. If objects are fetched, the tracking branch is merged into the current local branch
	. This is similar to a topic branch merging into a base branch
		. git pull [<repository>] [<branch>]

	eg:
		git pull
	
. Git Pull merging options:
	--ff(default)  =>  fast-forward if possible, otherwise perform a merge commit
	--no-ff        =>  always include a merge commit
	--ff-only      =>  cancel instead of doing a merge commit
	--rebase [--preserve-merges] => discussed later
	

	
==========PUSH===============
	. Pushing the local commits to remote
	. fetching or pulling before push is suggested
		
		git push [-u] [<repository>] [<branch>]
		 [-u Track this branch (--set-upstream)]

	eg:
		git push -u origin master
		

========REBASING=================

	***REWRITING COMMIT HISTORY:===
		
		WARNING: 
			The topics discussed here rewrite the commit history	
			This should be done with caution
		
		GENERAL RULE:
			Do not rewrite history that has been shared with others

		REBASE:
			Moves commits to a new parent(base)
				

		DIFFS:
			. Each commit contains a snapshot of the complete project Git can calculate the difference between commits 
			. This is known as diff or a patch

	***REBASING REAPPLIES COMMITS:========
		. When rebasing, Git applies the diffs to the new parent commit
		. This is called "reapplying commits"
	
	***REBASING PROS AND CONS:=========
		PROS: 
			You can incorporate changes from the parent branch 
				you can use the new feature/bugfixes
				Tests are on more current code
				It makes the eventual merge into master fast-forwardable
			Avoids "unnecessary" commits
				It allows you to shape/define clean commit histories

		CONS:
			Merge conflicts may need to be resolved
			It can cause problems if your commits have been shared
			You are not preserving the commit history
		
	***EXECUTING A REBASE:=======
		1)	Checkout featureX
		2) Rebase onto master

GIT REBASE SYNTAX:=============

	git rebase <upstream>
		. [changes the parent of the currently checked out branch to <upstream>]
	
	git rebase <upstream> <branch>
		. checks out <branch> and changes its parent <upstream>
		. This is a convenience to avoid issuing two commands

		eg:
			git checkout featureX
			git rebase master
			
			.above two commands are equivalent to : 
				
				git rebase master featureX

FIXING A MERGE CONFLICT WHILE REBASING:====
	1) Checkout featureX
	2) Rebase onto master [a. CONFLICT-both modified fileA.txt]
	3) Fix fileA.txt
	4) Add fileA.txt
	5) Continue rebase
	
	
	eg:
		git checkout featureX
		git rebase master [conflict]
		git status
		Fix fileA.txt
		git add fileA.txt
		git rebase --continue
	
ABORTING A REBASE:===========
	To get back to the pre-rebase state:

		git rebase --abort 
		
	
===> TWO TYPES OF REBASE:
	1) Rebase [regular]
	2) Interactive rebase

===============REWRITING HISTORY================

	AMMENDING A COMMIT:===
		You can change the most recent commit:
			change the commit message
			change the project files
		This creates a new SHA-1 (rewrites history)
		
			git commit amend -m "updated message"
			
		use:  --no-edit  option to reuse the previous commit message
		
	INTERACTIVE REBASE:==========
		Interactive rebase lets you commits using commands 
			The commits can belong to any branch
			The commit history is changed - do not use for shared commits
			
		git rebase -i <after-this-commit>
			commits in the current branch after <after-this-commit> are listed in an editor and can be modified
	
	INTERACTIVE REBASE OPTIONS:=======
		. Use the commit as is
		. Edit the commit message
		. Stop and edit the commit
		. Drop/delete the commit
		. Squash 
		. fixup
		. Reorder commits
		. Execute shell commands

		eg: [edit/drop/squash commit]

			git log --oneline --graph
			git rebase -i 0e91
			edit and solve conflict
			git commit --amend
			git rebase --continue
	
SQUASH:============
	Applies a newer squashed commit to an older commit
	Combines the commit messages
	Removes the newer commit
	
SQUASH vs DELETE:========
	Squash: Combine this commit with the older commit, creating a single commit.
			The work of both commits is included
			
	Delete:	No changes from the commit are applied
			The diff is thrown out
			The work of this commit is lost
			Greater chance of a merge conflict
			
		
SQUASH MERGE:====
	Merge the tip of the feature branch (D) onto the tip of the base branch(C) 
		There is a chance of a merge conflict
	Places the result in the staging area
	The result can then be commited(E)

	PERFORMING THE SQUASH MERGE:===
		1) git checkout master
		2) git merge --squash featureX
		3) git commit [a. accept or modify the squash message]
		4) git branch -D featureX
	
=========PULL REQUEST================
	. A feature of Git hosting sites
	. The ultimate goal is to merge a branch into the project
	. Enable team communication related to the work of the branch
		. Notification sent to team members
		. Feedback or comments
		. Approval of the content (code review)

	.WHEN DO YOU OPEN A PULL REQUEST?:
		.When the branch is created
		.When you want comments on the branch
		.when the branch is ready for review/merging

	.PREPARING FOR PULL REQUEST (SINGLE REPOSITORIES)
		1) Create a feature branch
		2) Optionally work on the feature branch
		3) Push the branch to the remote repository


.MERGE STRATEGY:===========
	. Merge commit-> the merge creates a seperate commit object (git merge --no-ff)
	. Squash -> the entire branch is condensed to one linear commit (git merge --squash)

.DELETING REMOTE BRANCH LABELS AFTER MERGE:===========
	git push -d <remote> <branch>
	
	eg:
		git push -d origin featureX
		
	
**FORKING:==========
	. Forking means copying a remote repository to your own online account
	. Both repositories are remote repositories
	. The upstream repository is usually the "source of truth"

	WHAT IS A FORK USED FOR ? :
		. Experiment with/learn from the upstream repository
		. Issue pull requests to the upstream repository
		. Create a different source of truth

	MULTI-REPOSITORY PULL REQUESTS:
		1) Fork the upstream repository
		2) Create a branch
		3) Create a pull request
	
========GIT WORKFLOWS============

	CENTRALIZED WORKFLOW:---
		. Only a single branch
		. no pull requests/discussion
		
	FEATURE BRANCH-WORKFLOW:----
		.Work done on feature/topic branches
		.single remote repository
		.pull requests/discussion
		
	FORKING WORKFLOW:--------
		.Multiple remote repositories
		.Pull requests/discussion
		.don't need write access on upstream
		.backs up your work in progress
		.can rebase your forked branch
		.must synchronize with upstream

NOTE: The above notes is being prepared from the help of the coursera course named : [version-contron-with-git]