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 '[email protected]' 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