Purpose:

Multi person development projects, integrate projects according to certain rules, achieve orderly iteration of project versions, integrate other people's codes safely and efficiently, and control project versions (back, forward, restore)

Differences between GIT and SVN

	git (Distributed version control tool):Version control is formed locally. If the code is merged, it must also pass through the central server
	svn (Centralized version control tool):Version control can only be formed on the same server. If the code is merged, it must also pass through the central server

Advantages of git

	1.Locally formed version
	2.A detailed version description of the version can also be rewritten
	3.git Most of the legal operations in can be revoked( force (mandatory)
	4.There are strong branches(branch)System, which is the default main branch for solving development requirements(master)
	5.git Full backup, svn Incremental backup

Common Linux operations (need to know)

docs In the window ~/Desktop The location is in the desktop folder under the user's home directory 
~  -->  C:\Users\xuanqiyan

cd Switch directory
pwd Print current location
ls List files and folders
	ls -a List all folders and files (including hidden files)
	Linux Zhongyi.The files at the beginning are hidden files and need to be configured-a Parameters can be seen
	ls -l (Equivalent to ll) Lists all files and folders in long format
echo '123' // Output to terminal
echo '123' > a.txt // Redirect output to a.txt (overwrite write)
echo '123' >> a.txt // Redirect output to a.txt (append write)
cat file name // View all contents of the file

rm file name // Delete a file 
rm *.js  // Delete files ending in js
	
rm -r catalogue // Delete directory 
	r recursion 
rm -rf  file/folder
	f force force	
	
rm -rf ./* Empty current folder

mv ./file ./Another file name (rename)

cp Target file new file copy 
cp -r Source directory destination directory
 
ctrl + a Redirect cursor to start position 
ctrl + e Redirect cursor to end position
ctrl + c Force end of current command 

vi Using the editor to edit files 
vi file name
	Command mode (default)
	Insert mode( insert)need i Enter the insert mode. You can edit the file only in the insert mode 
	
	esc (Exit insert mode and enter command mode) save and other operations can be performed only in command mode 
	:wq Save and exit
	:q! Force exit without saving

Common operations of git

Experiment 1: set the local name and email
git init / / initialize git warehouse

1. generate.git Version control warehouse (do not modify, forced modification is illegal)
	All version save information is in this folder
2. Generate a default main branch( master)   
		
	   
	Scope of profile
	system  System level 
	global  User level (common)
	local   This warehouse
	Set mailbox and name
	git config --local user.name 'xuanqiyan'
	git config --local user.email '18211108895@163.com'   
	
	View mailbox and name
	git config user.name
	git config user.email
	
	Delete mailbox and name
	git config --unset user.name
	git config --unset user.email

Experiment 2: git submission version experiment
Scenario: initialize a git repository
touch a.txt
echo '123' > > a.txt / / in the workspace, a new file is created for submission to form a version

		//Currently submitted to staging area in workspace
		git status // View status 
		/*
			On branch master // In main branch 
			No commits yet   // The main branch is not committed and has no version (commit version)
			Untracked files: // tracked To track untracked untracked
			// You can use git add to add files to the staging area (for tracking purposes)
			  (use "git add <file>..." to include in what will be committed)
			        a.txt
			// The staging area has nothing to submit		
			nothing added to commit but untracked files present (use "git add" to track)
		*/
		git add a.txt
		
		git status
		/*
			On branch master
			No commits yet
			Changes to be committed: 
				// stage Staging unstage not staging 
				// Using git rm --cached file, you can restore a file that has been staged to a file that has not been staged (pull it back from the staging area to the workspace)
			  (use "git rm --cached <file>..." to unstage)
			        new file:   a.txt
		*/
	   
		//Operation 1: pull the files in the temporary storage area back to the work area (mode 1: comparative supplementary experiment) (restore the add operation in the previous step)
			git rm --cached a.txt
			git status // The discovery is consistent with that before submission 
		//Operation 2: submit the staging area to the object area (forward submission to form version)
		git commit  // Submit the code of the staging area to version
		open vi Editor purpose: enter the submission description of the current version 
		/*
			[master (root-commit) ceb1dfd] This is a new a.txt to complete a function
			 1 file changed, 1 insertion(+)
			 create mode 100644 a.txt
			ceb1dfd:  Version id (a unique and non repeatable string obtained by sha1 encryption algorithm, 32 bits)

		*/

Experiment 3: View version
git log / / all
git log -n / / previous n versions
Git log -- pretty = online / / view the log in a single line
/*
3f1a23118a45309bc2ba8b1cc1d88eec7f578294 (head - > Master) create a new b.txt
90642a8ead39fbbc0cbc001c5e82f921214aad8a create a.txt
Head -- > points to the current branch (master)
Master -- > refers to the latest commit (the latest version, if it refers to a commit version in history, fallback)
/
git log --pretty=format:"%h - %an , %ar : %s "
/
3f1a231 - yanzhijie, 9 minutes ago: new b.txt
*/

Experiment 4: document accountability
git blame b.txt
3f1a2311 (Yanzhijie 2021-10-27 08:23:38 +0800 1) 1111
410ac15a (zhangsan 2021-10-27 08:40:06 +0800 2) nice
410ac15a (zhangsan 2021-10-27 08:40:06 +0800 3) xxx

Experiment 5: check out (restore) experiment (remove the modification action of the file (change the file, delete), restore the before modification)

	Scenario 1: modify a submitted file
		touch b.txt && echo '123' >> b.txt && git add . && git commit -m 'newly build'
		git status
		/*
			On branch master
			nothing to commit, working tree clean(The files in the workspace and object area are consistent, so clean)
		*/
		//Modify file b.txt
		echo '123123' >> b.txt
		
		git status 
		/*
			On branch master
			// Changes are not staged (b.txt is modified in the workspace)
			Changes not staged for commit:
			  (use "git add <file>..." to update what will be committed)
			  // discard Discard modification
			  (use "git restore <file>..." to discard changes in working directory)
			        modified:   b.txt
			no changes added to commit (use "git add" and/or "git commit -a")
		*/
		Operation 1: submit modification git add . && git commit -m 'modify b.txt'
		Operation two: Check out (restore the file state before modification)
			git restore b.txt
			git status 
			/*
				On branch master
				nothing to commit, working tree clean(The files in the workspace and object area are consistent, so clean)
			*/
			cat b.txt // The modified content is gone 
	Scenario 2: delete submitted files( rm System delete)
		mdkir demo2 && cd demo2 && git init 
		touch a.txt b.txt
		git add .
		git commit -m 'a.txt b.txt'
		
		// Execute system delete rm
		rm a.txt
		git status 
		/*
			On branch master
			Changes not staged for commit:
			  // Use git add to submit the deleted a.txt file 
			  (use "git add/rm <file>..." to update what will be committed)
			  // Remove delete action using checkout
			  (use "git restore <file>..." to discard changes in working directory)
			        deleted:    a.txt
			no changes added to commit (use "git add" and/or "git commit -a")

		*/
		Operation 1: submit deletion
			git add . // The delete operation is committed to the staging area
			git status
			/*
				On branch master
				Changes to be committed:
				  (use "git restore --staged <file>..." to unstage)
				        deleted:    a.txt
			*/
			Operation 1: submit deletion
				git  commit -m "Remove from new version a.txt file"
			Operation 2: cancel (the temporary storage area is cancelled to the work area)
				git restore --staged a.txt
		Operation 2: cancel deletion
			git restore <file>... // Undo delete restore a.txt file, working clean
	
	Scenario 3: delete submitted files( git rm delete)
		mdkir demo2 && cd demo2 && git init
		touch a.txt b.txt
		git add .
		git commit -m 'a.txt b.txt'
		
		// Perform git delete git rm
		git rm a.txt
		git status
		/*
			On branch master
			Changes to be committed:
			  (use "git restore --staged <file>..." to unstage)
			        deleted:    a.txt
		*/
		Operation 1: git commit Submit delete
		Operation 2: git restore --staged Check out to the workspace, and then check out the delete action to restore the delete operation
			git restore --staged a.txt
			git restore a.txt
			
Supplementary experiment: for the code in the temporary storage area, back to the work area (mode 2) 
		mkdir demo2 && cd demo2 && git init
		touch a.txt && echo '123' >> a.txt
		// Add to staging area
		git add .
		git status 
		/*	// Undo to workspace
			git rm --cached <file>..." to unstage)
			new file:   a.txt
		*/
		git commit -m 'newly build a.txt' //Note: there is a version
		
		touch b.txt && echo '123' >> b.txt
		
		git add b.txt // Adds a new file to the staging area 
		git status 
		/*	
			On branch master
			Changes to be committed:
			  //Pull the files in the staging area back to the workspace (restore the action of checking out the files)	
			  (use "git restore --staged <file>..." to unstage)
			        new file:   b.txt
		*/
	   git status
	   /*
		On branch master
		Untracked files:
		  (use "git add <file>..." to include in what will be committed)
		        b.txt
		
		nothing added to commit but untracked files present (use "git add" to track)
	   */

Experiment 6: git ignore (. gitignore)
#Ignore files starting with a
a.*
#Don't ignore a.css
!a.css
#Ignore individual files
b.html

Automatically ignore empty directories
 Ignore directory
/test
/test/*.txt
/test/*/a.* ignore /test/a/a.* /test/b/a.* Will not ignore/test/a/b/a.*
/test/**/a.* Ignore all of any subdirectories a.*file

Experiment 7: branch basic command
Multiple commit (versions) form a work record line in chronological order (the order of development versions)
Note: creating a branch must be based on commit

	Basic branch operation 
	 git branch  Branch name  //Create branch 
	 git branch  //View branch
	 git checkout Branch name // Switch branch	
	 git checkout -b Branch name // Create and switch branches	 
	 git branch -d Branch name  // Delete branch D force delete

Experiment 8: can a branch be deleted?
If there is and only the changed branch points to a commit, then this branch cannot be deleted directly using d
You can use D to force deletion. As a result, the commit cannot be found
How to get it back?
git reflog operation log found sha1 of commit
By creating a new branch, you can make the branch point to the commit
git branch dev sha1 / / associate this branch with commit
You can retrieve this version

Experiment 9: can a branch be deleted?
1. The current branch cannot be the current branch
2. If there is an unconsolidated Version (and only the current branch points to this version), it cannot be deleted

Experiment 10: status of files between branches
Scenario: two branches (dev/master) are based on the same commit
If there is a new write operation (add, delete, modify) in the dev branch, the write operation is in the workspace or staging area
, the write operation can be seen in the master, indicating that the workspace and staging area are shared

Experiment 11: Branch merging
Scenario: the master is one commit dev behind and one commit ahead, and the dev branches are merged in the master branch
git checkout master
git merge branch name / sha1 (branch to merge – commit – sha1)
/*
Updating 3324d11...548e134
Fast forward - > FF merge (default)
b.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
*/
Features of ff consolidation:
1. The essence of branch merging is the movement of branch pointer, and the intermediate commit will be retained in the merging
2. After merging, the two branches point to the same commit
3. Branch information will be lost when merging
git log --graph

	Scenario: master Two behind commit dev Two ahead commit ,stay master Branch merge dev branch	
		use no-ff merge 
		git checkout master
		git merge --no-ff dev 
		/*
			Merge made by the 'recursive' strategy.
			 b.txt | 0
			 c.txt | 0
			 2 files changed, 0 insertions(+), 0 deletions(-)
			 create mode 100644 b.txt
			 create mode 100644 c.txt
		*/
	   no-ff Characteristics of consolidation:
			1.The merged branches do not point to the same commit ,Actively merged branches point to new ones commit 
			2.Branch information will not be lost 
				git log --graph 

Experiment 12: conflict experiment (conflict may occur only when two versions without logical and temporal relationship are merged)
Scenario: two branches (master dev) point to the same version (a.txt) with the same content
//Two versions have different implementations for the same line of the same file
master modifies the second line of a.txt file and submits a
dev modify the second line of the a.txt file and submit a

		master merge dev (Conflict)
		/*
			$ git merge dev
			Auto-merging a.txt
			CONFLICT (content): Merge conflict in a.txt
			Automatic merge failed; fix conflicts and then commit the result.
		*/
	    Conflict resolution:
			1. Notify the person affected by the conflict
			2. vi Modify the conflict file (decide how to modify the code through negotiation)
				123
				master,dev~~
				In command mode, dd Delete the line of the cursor
				Save exit
			3. git add . && git commit -m 'solve master and dev stay a.txt File conflict' 

Experiment 13: scene without conflict
1. Merging two versions with logical relationship (time relationship) will not cause conflict fc
2. Two versions without logical relationship
Modifying different files will not cause conflicts
When modifying the same file, different lines have the same implementation and different implementations on the same line will conflict
If you modify the same file and the same line is consistent, there will be no conflict

		Summary:
			1.merge Generate a new version (a conflict is a conflict resolution version, and a new version will be generated if there is no conflict)
			2.merge Merge will bring the merged branch version to the current branch
			3.Two versions without logical relationship may conflict

Experiment 14: forward and backward of version
git reset --hard HEAD ^ back one
git reset --hard HEAD ^ ^ back two
git reset --hard HEAD~n back n + 1 (skip n) version
git reset --hard sha1 moves the pointer to the specified version (back and forward)

	Need help git reflog View version of sha1 
	git reflog Complete submission instructions are required 

Experiment 15: dissociation operation
git checkout -- file name (restore checkout)
git checkout branch (switch branch)
git checkout sha1 (free state)

	Concept: use checkout sha1 You can switch to this version, but it is in a free state (no branch points to the current version) commit)
		All modification operations must be submitted, and a new branch is created to associate the submission
		git switch -c New branch
		git branch New branch sha1  / git checkout New branch
		git checkout -b New branch sha1
		
Supplementary experiment:use checkout Check out files 
	git Recommended restore Actually, for the old git Version recommended checkout detection
	Perform modifications to a submitted file 
	modified: a.css
	git checkout -- a.css //Remove previous modifications -- check out