1. Introduction of git

Git is the most advanced distributed version control tool in the world.

2. The extension:

  • Linus wrote only a Linux version of Git,

  • The Windows version of Git is a later addition, which is equivalent to installing a small Linux virtual machine on a Windows system.

2. Setup command after git installation

1. After git is installed, set your own name and email (only enter it once, unless you want to change it!)

Git config --global user.email "[email protected]" git config --global user Git config user.email You can view the configured email addressCopy the code
  • Because Git is a distributed version control system, every machine must identify itself: your name and Email address.

3. Basic Linux commands (extensions)

Mkdir XXX Create a folder (directory) CD XXX Go to the XXX directory CD.. Return to the upper directory ls List all the files in the current folder PWD Display the current directory cat x.tx Display the file contents Clear the screen vi x.TX Create a file (Visual Editor) Enter I to enter editing mode ESC + : + q! Do not save and exitCopy the code

4. Git three regions – Workspace + version area + staging area (users can only see workspace)

Illustration:

5. Basic use of Git

5.1 Create version libraries and commit files (important!)

1) git add x.x: Git add * or git add. : Add all files in your workspace to the staging area. Red means in the workspace. 2. Green indicates in temporary storage area. 3. No display indicates that all files are in the version area. 4) git commit -m 'XXX' : Try to write realistic modification information!Copy the code

5.2 Comparison of Differences (Understanding)

Git diff: compares staging with workspace git diff --cached: compares staging with workspace git diff master: compares staging with workspace git diff --cached: compares staging with workspace git diff master: compares staging with workspaceCopy the code

5.3 Viewing Logs and Version Numbers

Git reflog Displays the commit ID for each commit (commit)Copy the code

5.4 Version Rollback (important!) + version shuttle + version undo

Git reset --hard HEAD^ : rollback to the specified commit id Git rm --cached. TXT: git reset HEAD: replace all files in the staging area with files in the version library. Git checkout -- x.tx: Replace workspace specified files with staging specified files (danger!) Git Checkout HEAD x.tx: Replace the staging and workspace files with files from the repository (danger!)Copy the code

5.5 Deleting a File

Git rm. TXT delete the file git rm -r XXXX delete the folder. Empty folders are ignored by Git and cannot be deleted.Copy the code

Note:

  • Delete their own files, temporary storage area and version area do not know. Deleting a file with a command notifies the staging area, but the version area doesn’t know either.
  • Git version control is required to delete files using commands.
  • You cannot delete the current folder by running commands while standing in the folder.

6. Git complete working diagram

7. The git branch

7.1 Introduction to Git Branches

1. Master branch: Master — After the code has been unit-tested by the developer and passed a detailed set of tests by the tester, it is ok

2. Development branch: dev — All code for developers is submitted to this branch

3. Test branch: test — used by testers (where code that has been unit tested by developers goes)

4. Milestone branch: tags — V1.0.0

5. Project version number, for example, 1.0.0

  • First: large version number

  • Second: minor feature updates

  • Number three: Bug fixes

Extension:

  • Types of tests: regression tests, stress tests, performance tests, unit tests (develop your own tests)

7.2 Git Branch Commands

Git checkout -b dev Git branch git checkout master git merge dev git branch git branch Git diff branch1 branch2 git diff branch1 branch2 git diff branch1 --stat git diff branch1 Branch2 XXX displays detailed differences for the specified fileCopy the code

Note:

  • If the current branch is empty (that is, no files or folders) and you try to create a branch, the current branch will be deleted!

7.3 Version Conflict

  • Merging branches can cause version conflicts if changes or additions are made in the same file in the same place.

  • The best way to resolve version conflicts is with an IDE, which is simple and efficient.

8.Github

8.1 introduction of making

  • GitHub is a Git project hosting site

8.2GitHub Remote Repository usage (emphasis!)

1. Scenario 1 (Association) : A local warehouse needs to be associated with a remote warehouse (Project start)

  1. Build local library first:
Git add. Git commit -m "first commit"Copy the code

  1. Create a remote repository on GitHub.

  2. Final association:

git remote add origin https://github.com/Front-end-Chen/0909_demo.git (HTTPS)
Copy the code

  • Origin is the alias of the associated address

  • Note: If this step is wrong, the solution is as follows:

    • Violent solution: delete the.git folder and rebuild the local repository.

    • Git remote remove Origin

2. Scenario 2 (Push) : There is content in the local repository and it needs to be pushed to the remote repository

Git push -u origin masterCopy the code

  • Enter the user name and password as prompted

  • Git will not only push the local master branch to the new remote master branch, but also associate the local master branch with the remote master branch. Git push origin master can be simplified in the future push. Note: Now the proof can not write -u effect the same!

  • Note:

    • Under normal circumstances, after a successful push, the computer will remember and account number and password, the next push will not prompt for input.

    • Go to the Control panel for user accounts -> Manage Your Credentials -> Windows Credentials -> Delete github password options!

    • If the computer cannot automatically remember the Github account and password, run the following command:

git config --global credential.helper store
Copy the code

3. Scenario 3 (pull) : The local repository has content, and the new content of the remote repository is obtained

  1. The first way of pulling:
git pull origin master
Copy the code

  • Copy/merge code versions from the master branch of the remote repository to the local master branch

  • Note:

    • This method merges code with a conflict that needs to be resolved!

    • Only stand on the same branch to pull the corresponding code, that is, on the master branch git pull origin master

    • Use git pull to pull all branches from other branches, including new branches that are not locally available!

2) (Extension) The second way of pulling:

git fetch origin master:tmp
Copy the code
  • Create a TMP branch and copy the code version from the master branch of the remote repository to the TMP branch.

Scenario 4 (Clone) : If there is no local repository, you need to obtain a complete remote repository

git clone https://github.com/xxx.git  (HTTPS)
Copy the code

  • Clone a repository that contains all branches that are invisible to the git branch command, but can be seen by the command when you switch branches.

  • Note:

    • Cloning is only required when the remote library is acquired for the first time (first time at work)

8.3GitHub website: new warehouse, new organization, fork/pull Request for open source projects, and collaboration for company projects

  • Github repository wiki to replace Redme. md with a richer introduction page

  • Issues is a place to ask questions

  • Fork is copying someone else’s repository into your own account, so you can borrow their code, and then use the pull Request to remind people that I’ve changed the good code

9.. gitignore Ignores the configuration file of the file

  • The file type can be ignored, such as.idea,.vscode

  • This document should also be submitted (usually by the team leader!)

10. Use development tools to control Git version (practice)

  • Webstorm has icon action in the upper right corner.

  • Vscode switches to the git option on the left.

11. Specification of submission code

1. Before each submission: Update first and then submit.

2. Update files timely at sensitive time points.

3. Commit frequently to avoid the “write code, not commit” phenomenon.

4. Each submission must be written with clear submission instructions.

5. Don’t submit code that doesn’t compile.

6. Don’t submit code you don’t understand.

7. Use the lock function with caution (try to avoid using the lock, do not easily unlock locked files).

8. Do not submit files or folders automatically generated locally.

Note:

  • You can undo and revert to the original state when you clone someone else’s code.