当前位置:网站首页>Explain git in detail

Explain git in detail

2020-11-09 16:10:27 Mr. yunya

version control

Basic concepts

   Version control is a very simple concept , I'll give you an example to illustrate briefly, and you can get a general idea of what it is , When you don't have version control :

  1. Yours BOSS Decided to make a software that is often forced by the gray , Find you to develop

  2. When you're done , The boss thought it would be better to add a new function

  3. When you add new features , The boss thinks the feature may not be very good , Let's get rid of it

  4. When you remove this feature , The boss said iron juice , You'd better add it up , I suddenly thought this function was very good

  5. You think boss, I quit , You can do it yourself , But reality does make you hold up your keyboard and do it

   See the source image

   At this time, smart students may do this , Copy after basic functions , Then make changes to the copy and add new functions , In this way, no matter how wonderful the boss is, you have a way to deal with it :

   image-20201107205553831

   So this is the simplest version control , Is it very simple ?

Historical development

   Version control has gone through four stages , as follows :

  1. Folder copy
  2. Local version control
  3. Centralized version control
  4. Distributed version control

   Folder copy

   There's no need to say more about this , Believe that all fools understand , As mentioned in the example above, copy the original product and add new features .

   This is really a solution for a long time , But it has a very big problem , For example, the code of my original product is 100000 lines , My new feature has 20000 lines , So my original product (V1) Plus my new features (V2) It's going to take 220000 lines of code to store , It's a waste of storage space (V1 100000 lines ,V2 120000 lines ).

   Local version control

   To the back , Gradually, there are some software , It can help us do version control , Instead of copying it manually .

   also , It has the following characteristics :

   1. Only one version can be seen at the same time , If you want to go back to the previous version , It can be rolled back through its command and other operations

   2. It won't be easy to copy , It's an incremental update based on the original code , This means that the total amount of code stored in my two versions is only 140000 lines , Very space saving

   remember , The first feature is very representative , So here's a picture of Git Pictures on the official website , You can see clearly , We can only see one document at a time , But multiple versions are stored in the version Library :

    Local version control diagram

   Centralized version control

   gradual , People are beginning to find that individual combat can't solve all the problems , We need to co produce .

   So when there are multiple developers developing at the same time , There needs to be a common repository for storing code , Now the code will be submitted to a common repository , In this way, the problem of collaborative development is solved , But the corresponding , If the computer in the shared warehouse goes down , Then everyone can't produce , If the situation is worse, such as disk damage in the shared warehouse , Then all your hard work for so long is in vain .

   Here are two features , To elaborate :

   1. It is mainly used for centralized development

   2. All code is submitted to the shared warehouse only , This will bring some security risks

   centralized

   Distributed version control

   In order to solve the disadvantages of centralized version control , Distributed version control came out later , Such as GitMercurialBazaar as well as Darcs etc. , You can choose to push your own code locally , You can also choose to push to a remote warehouse . For the moment , It's a great solution , As shown in the figure :

    Distributed version control diagram

   You can be in the same project , Work with people in different groups . You can set up different collaboration processes according to your needs , Such as hierarchical model workflow , This was not possible in previous centralized systems .

Git Introduce

Basic introduction

   Git It's distributed version control software , Here is its official website :

   Git Official website

   Its documentation is very detailed , And it's easy to use , At present, in most scenarios, we choose Git To do version control .

   So , It's a general trend to study it , It's unavoidable , Face the wind .

Download and install

   The official instructions are very detailed , Check it , It contains Windows/Linux/Mac Installation steps of :

   Git install

   Now let's use Windows For example , When you have finished downloading, just click next , When the installation is complete, right-click the mouse on the desktop. If the following two options appear , The installation is complete .

   image-20201108115648386

Local repository

   because Git It's distributed version control software , So let's first learn how to submit code locally , Then see how to submit to the remote code base .

Version submission

   stay Git in , The first thing we need to do is manage a project .

   Go to the project folder , By executing the initialization command Git Take over version control of the current project .

   Here we have one mysite Project , There's a index.html, The contents are as follows :

   image-20201108120543011

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title> master station </title>
</head>
<body>
    <h1> Welcome to my main station </h1>
    <ul>
        <li> I like </li>
        <li> My collection </li>
        <li> My attention </li>
        <li> Historical record </li>
    </ul>
</body>
</html>

   Now? , We need to open it terminal, Then go to the folder , Give Way Git Take over mysite Folder .

   Or you can right-click under the folder , choice Git Bash Here Then enter the following command in its terminal :

git init

   When the initialization command takes effect , stay mysite A... Will be generated in the folder .git Hidden folders for .

   image-20201108120914744

   Then we use the following command to detect the status of managed files in the current folder , Enter the following command :

git status

   The newly added files and the modified files belong to unmanaged files , In red , As shown below :

   image-20201108121110025

   Next, let's manage the file , There are two commands for you to choose from :

git add  file name   #  Just manage one file 
git add .   #  Represents all files in the current directory 

   Here we use git add . that will do , After entering the command, check the file status again , It turns green :

   image-20201108121334157

   Next we start to build the first version , Just name it v1 Well . Execute the following command for version generation :

git commit -m " Description information "

   Here it will prompt an exception , Let you configure user information , enter one user name 、 Email and other information ( Just type... Once ):

   image-20201108121618978

   So let's configure personal information , Follow the command it provides :

git config --global user.email " Email address "
git config --global user.name " user name "

   And then type in git commit -m " Description information " Submit version , Successful submission will be displayed .

   Next use git log Command to view the generated version :

git log

   image-20201108121913706

   Okay , Now let's summarize the order :

command describe
git init initialization git, Give Way git Take over the current folder
git status View the current file status , New or modified files are red , And perform add The files after the command are all green
git add [./filename] Submit documents
git commit -m " Description information " Build a version
git log View version submission information

Modify and add

   When you make changes to files in a project , Will also be Git To detect . As shown below , Let's get rid of index.html In addition, we have added backend.html file .

   The contents are as follows :

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title> Background management </title>
</head>
<body>
    <h1> Welcome to backstage management </h1>
</body>
</html>

   image-20201108135539615

   Now? , When we use git status after , You will see backend.html It's red .

   image-20201108135623686

   At this point, we still need to perform the above steps , To generate a second version .

   image-20201108135748049

Version rollback

   If now your Boss Tell you that background functions are not needed for the time being , You need to roll back the version , Roll back the second edition to the first edition .

   The following command is used to roll back :

#  Roll back the higher version to the lower version , Check the version number first , Set the rollback again 
git log 
git reset --hard  Version number 

   image-20201108140013440

   Now? , Check the folder under the project again , You won't see backend.html The file .

   image-20201108140046739

   meanwhile , Use git log The command doesn't see the second version of the record .

   image-20201108140119021

   If at this time Boss Tell you , The backstage function is very good, uses again lets you add back , What should you do ? because git log We can't find the version number of the second edition .

   take it easy , You can use the following command :

#  Roll back low version to high version , Use reflog View version number , Set the rollback again 
git reflog
git reset --hard  Version number 

   image-20201108140424765

   Now? , Look again mysite The contents of the folder , You'll find that backend.html The papers are back .

   image-20201108140457883

command describe
git log View version submission information , It is often used to roll back a higher version to a lower version
git reflog View version submission information , It is often used to roll back from low version to high version
git reset --hard Version number Do version rollback

Partition concept

   In the above operation , It can be found that a current file can have multiple states :

  1. To control the State : Means that the document can be git The state of Management , For now, all of them are located in git init The files under the folder are in control state
  2. In a state of change : When there are new documents , Or after the original document has been modified , Use git status Files in red state
  3. Staging area status : It means to execute git add After the command , Red status file changes to green status file
  4. Version library status : It means to execute git commit After the command , Files submitted to the repository

   These different states , Corresponding to different partitions , Because at this point we are doing local version control , So the version library here is the local version library :

   image-20201108141206328

Use branches

   Branch is Git A very important concept in , It allows you to deal with more emergencies , And make you better for collaborative development .

   Multiple branches don't affect each other , As shown in the figure below :

   image-20201108160245076

   The committed versions seen in different branches are not the same

   When you create a new branch in a branch , The child branch will inherit all the code in the current branch node

   There is one by default master Branch

   Use the following command to view branches , You can see , It has one by default master Branch .

git branch

   image-20201108142840259

   If you want to create a new branch , You can use the following command :

git branch  The name of the new branch 

   In the following example , A new name will be created dev The branch of .

   image-20201108143009713

   In the picture * Which branch are you in now , If you want to switch branches, you can use the following command :

git checkout  Branch name 

   The following example , We switch the current branch into dev

   image-20201108143158161

   Usually , A project requires at least two branches ,dev And master( Default ).

   master Branches only hold stable versions . and dev The branch stores the development version .

   Now? , I want to write a statistical function , stay dev After the development has been completed and submitted , Switch to master Branch to merge ( You merge under that branch , Just merge the code into that branch ).

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title> Data statistics </title>
</head>
<body>
    <h1> Data statistics home page </h1>
</body>
</html>

   image-20201108143810578

   If there is no problem with the test , Use the following command to merge branches ( Switch branches first ):

git merge  Branches to merge 

   image-20201108144030940

   Use git log View the submitted version information , You'll see a hint of branch merging :

   image-20201108144248241

   For some branches ( Such as test bug), If you don't want it , It can be deleted :

git branch -d  Branch name 

   The following is a summary of the commands for this section :

command describe
git branch View all branches of the current project
git branch Branch name Create a new branch
git checkout Branch name Switch branches
git merge Branches to merge Merging branches , Merge under that branch
git branch -d Branch name Delete the branch

Merger conflict

   Due to multi branch development , Multiple branches may modify the same code , At this time, there will be merger conflicts .

   As shown below , We are master About China index.html It's like this :

    <h1> Welcome to my main station </h1>
    <ul>
        <li> I like </li>
        <li> My collection </li>
        <li> My attention </li>
        <li> Historical record </li>
    </ul>

   If I'm in master In the branch , by index.html Add a new content , As shown below :

    <h1> Welcome to my main station </h1>
    <ul>
        <li> I like </li>
        <li> My collection </li>
        <li> My attention </li>
        <li> Historical record </li>
        <li> New content (master)</li>
    </ul>

   And in master Submit it to the version Library under the branch .

   image-20201108154441919

   Now I'm going to switch to dev In the branch , Also for the index.html Making a change , The contents are as follows :

    <h1> Welcome to my main station </h1>
    <ul>
        <li> I like </li>
        <li> My collection </li>
        <li> My attention </li>
        <li> Historical record </li>
        <li> New content (dev)</li>
    </ul>

   And in dev Commit to the repository in the branch .

   image-20201108154915858

   Now switch back to master To merge , It will prompt me to merge conflicts :

   image-20201108155006963

   If you are in the vscode Wait for the editor to open index.html, You can see the following picture :

   image-20201108155113851

   The reason for merge conflicts is that multiple branches modify the same code , When merging Git I don't know who to listen to . So just keep it all , It's up to you to make changes manually .

   So I delete it all and solve the merge conflict :

   image-20201108155236694

   Of course , Finally, generate the final version .

   image-20201108155400869

   OK, So the introduction of local warehouse is almost the same at present . Take a look at how many versions we've finally produced :

   image-20201108155614184

Handle bug

   When you master Branches, or stable versions, appear after online deployment bug, What should the processing flow look like ?

   As shown in the figure below :

   image-20201108155951659

   If the online version has bug, A new branch should be created immediately bug Repair , Then submit and merge .

   At the same time, it won't delay the progress of your other lines of business , When other lines of business are developed , If there is no conflict in the merger, good luck , If there is a conflict, resolve it .

Remote push

GitHub

   Git It is a distributed version control software , Basic local version control has been described above .

   Next, we need to introduce how to push the code from the local version library to the remote version library , Of course, there are a lot of remote repositories you can choose from , Here is the introduction GitHub, Because it is currently the most used remote code hosting Repository .

   First you need to register a GitHub, There's no more demonstration here , You can register yourself .

   image-20201108160951748

Create repository

   When we log in GitHub after , The first thing to do is create a remote repository .

   Open the warehouse page first :

   image-20201108161406270

   And then click New Ready to build a new warehouse :

   image-20201108161332424

   Here are some settings :

   image-20201108161853871

   Next you'll see this page :

   image-20201108162455308

   OK, So far, our warehouse has been created .

Push code

   Now? , Try to mysite Push the code in to GitHub Well .

   Enter the following two commands :

git remote add origin https://github.com/Yunya-Github/mysite.git
git push -u origin master

   image-20201108162714284

   Because this is the first time we use GitHub, So it pops up a page like this :

   image-20201108162831892

   We click on the middle button , Open this page

   image-20201108162901829

   Then click on the green button

   image-20201108162921325

   You will receive an email , Open the email and click on the first link , And it's done .

   image-20201108163029064

   Now open your warehouse , You can see that the files have been uploaded .

   image-20201108163141669

   It is worth mentioning that , It just uploaded master Branch , If we want to upload dev Branch , You still need to input push command :

git push -u origin dev

   image-20201108163400961

   Now? , Whether it's master still dev, Have been successfully uploaded to GitHub It's in .

   image-20201108163346454

   The following is a summary of the contents of this summary :

command describe
git remote add Alias Warehouse address Give the warehouse address an alias
git push -u origin Branch name Push branch to remote warehouse

   matters needing attention :

   When pushing code , Push one branch at a time

Pull the code

   When you're on a different machine , If you want to continue with unfinished work , You can pull the code from the remote version library and write it .

   As shown below , I'm in Beijing now , But the code is in Nanjing , So I want to pass GitHub Continue to edit my unfinished code .

   First step , Create folder :

X:\>mkdir beijing

X:\>cd beijing

X:\beijing>

   The second step , Use git Pull the code :

git clone  Remote warehouse address   #  Automatic alias , The name is origin   Clone the entire code ( All branches )

   image-20201108180739371

   Now we can develop , Enter dev Branch to update .

    <h1> Welcome to my main station </h1>
    <ul>
        <li> I like </li>
        <li> My collection </li>
        <li> My attention </li>
        <li> Historical record </li>
        <li> New content (master)</li>
        <li> New content (dev)</li>
        <li> Content updated at home </li>
    </ul>

   After the update is completed, first in dev For local submission , Then submit to GitHub You can go up. .

git push origin -u dev

   image-20201108181616280

   at present ,GitHub The code on dev The branch is also updated :

   image-20201108181740966

   If I come back to Nanjing , To the original office environment , You can use the following command to the original dev Incremental update :

git checkout dev
git pull origin dev  #  Incremental updating 

   image-20201108182121447

   Just go back and forth , I'll draw a picture and feel :

   image-20201108183354996

   This chapter commands a summary of :

command describe
git clone Remote warehouse address Clone all the code from the remote repository ( Use only for the first time )
git pull origin Branch name Incrementally update the code in a branch

Partition concept

   Because of the remote warehouse involved , So there's another partition :

   image-20201108183636617

   There are several points in this picture , I hope you can pay attention to .

   Using incremental updates pull It can actually be split into two commands :

git fetch origin  Branch   #  Pull the branch of the remote version library into the local version library 
git marge origin/ Branch   #  Merge the local version of the aerial code into the local branch 

Collaborative development

gitflow

   gitflow It's a workflow , Here are some processes that should be followed in the development process .

   gitflow Common branches

  • Production Branch

   Which is what we often use Master Branch , Code that this branch recently released to the production environment , Recently released Release, This branch can only be merged from other branches , Cannot be modified directly in this branch

  • Develop Branch

   This branch is our main development branch , Include all to publish to next Release Code for , This major merger with other branches , such as Feature Branch

  • Feature Branch

   This branch is mainly used to develop a new function , Once development is complete , We merge back Develop Branch to next Release

  • Release Branch

   When you need a new release Release When , We are based on Develop Branch create a Release Branch , complete Release after , We merged into Master and Develop Branch

  • Hotfix Branch

   When we're in Production Discover new Bug When , We need to create one Hotfix, complete Hotfix after , We merge back Master and Develop Branch , therefore Hotfix Changes to go to the next Release

   The initial Branch

   All in Master On the branch Commit should Tag:( tagging , It will be introduced later )

   img

   Feature Branch

   Feature After the branch is completed , Must merge back Develop Branch , This is usually deleted after merging branches Feature Branch , But we can keep it

   img

   Release Branch

   Release Branching is based on Develop Branch creation , It's over Release Points after , We can do it here Release Test on branch , modify Bug etc. . meanwhile , Other developers can develop new Feature( remember : Once hit Release Don't go from Develop Merge new changes on branch to Release Branch )

   Release Release When branching , Merge Release To Master and Develop, At the same time Master On the branch Tag remember Release Version number , You can then delete Release The branch .

   img

   Maintenance branch Hotfix

   hotfix Branching is based on Master Branch creation , Need to merge back after development Master and Develop Branch , At the same time Master Play one. tag

   img

   Other matters

   Of course, there are many branches that you haven't touched , It doesn't matter , It's just a workflow , Maybe your company is using another process .

Individual projects

   When it comes to collaborative development , All members need to be able to operate on the same project , At this point, you need to invite members and give them permission , Otherwise, the member will not be able to develop ,GitHub Support two ways to create projects for collaborative development .

   my GitHub Now I have a mysite Open projects for , Now I want to invite a developer to co develop

   image-20201108213927188

   That's it , When he agreed , You can work with me on Collaborative Development .

Organize projects

   Companies often use the form of organization for collaborative development , There can be multiple projects under an organization , So let's create an organization now .

   image-20201108214241156

   image-20201108214313463

   image-20201108214514739

   image-20201108214550033

   image-20201108214711786

   image-20201108214741859

   image-20201108214844520

   image-20201108214909066

   Now? , You can submit your first version to the repository .

tag application

   The version number we can see above , It's all a bunch of hashes .

   It's obviously very unfriendly , So it's better to give each version an alias when developing , Or label .

   Now we've created a new local project called NBSite, And wrote the first edition . We need to put a label on it when we submit it .

git tag -a v1.0 -m " describe "  	#  Create locally tag Information 
git tag -d v1.0  			 #  Delete tag
git push origin --tags       #  Will local tag Information is pushed to the remote warehouse 
git pull origin --tags       #  Update local tag Version information 

git checkout v.10  			 #  Switch tag
git clone -b v-.1   Address   		#  Appoint tag Download code 

   image-20201108220137252

   Now? , On our remote warehouse , We've got an initial version of tag 了 , Update later , Remember to label it .

   image-20201108220225795

Invite development

   First of all, invite our good friends to the stage :

   image-20201108221452278

   image-20201108221537081

   Now? , Our dear KAEJKING After confirmation by email, I have entered the organization , Click on NBSite This project , give KAEJKING jurisdiction .

   image-20201109112915256

start-up

   Now? KAEJKING This member already has write permission . We try to make it right to NBSite Project updates .

git clone https://github.com/KAKOFS/NBSite.git
cd NBSite
git checkout dev  #  Switch to dev
git bransh KAEJKING #  Create a new branch , It can be named after function , It can also be a person's name . Must be in dev Create 

#  Write code 

git add .
git commit -m "KAEJKING New features developed "
git push origin KAEJKING  #  Push the development branch to the organizational Repository 

   image-20201109114457019

Code review

   review It's a new one based on dev The branch of , because KAEJKING Is based on dev The functional branch of . So we need to do code testing before merging , That is to say review Only after finishing can we put KAEJKING Development content merged into dev Branch .

   image-20201109115932562

   image-20201109120025433

   Now? , The administrator has received a merge request . After the review, the code can be merged directly into dev The branch .

   image-20201109120526525

   image-20201109120632796

   image-20201109120724150

   review When it's done ,KAEJKING The new features of writing will be merged into dev In the branch .

   image-20201109120813886

Code release

   Now? dev The branch has been updated , If you want to update master In the branch , It also needs code release, This is a very rigorous test , So it should be done by a testing team .

  1. be based on dev Branch creation release Branch

    git checkout dev
    git checkout -b relase
    
  1. To test

  2. Testing is completed , take relase The code is merged into master Branch

    git merge relase # master Branch to do 
    
  1. stay master Branch fight tag, Upload code .

    git tag -a v2 -m " The second version of the official version goes online "
    git push origin --tags
    
  2. The operation and maintenance personnel can download the code and go online

    git clone -b v2  Address 
    

Other operating

rebase command

   When you submit code every day , Then your submission record will become very cumbersome . As shown below :

print(" The initial release ")
print(" I wrote so much code the first day ")  #  Generate version   The first day 
print(" I wrote so much code the next day ")  #  Generate version   the second day 
print(" I wrote so much code the third day ")  #  Generate version   On the third day 
print(" Finally, the development is finished ")  #  Generate version   The final version 

   image-20201108203958900

   Actually , Yours Boss It doesn't matter how many days you developed , It only cares about the final version .

   So we need to merge the middle three days , Make it look simpler .( This could lead to merger conflicts )

   Use the following command to merge :

git rebase -i HEAD~4  #  Merge four from the top version 

   image-20201108204401773

   Now it will pop up a vim, Let you edit the description .

   image-20201108204440859

   I made a few changes to him .

   image-20201108204611568

   Reuse git log To view the , It's much simpler :

   image-20201108204654404

   Be careful , It is actually the fusion of multiple versions in the current branch into one version ,

   So it may lead to merger conflicts .

The configuration file

   git The configuration file in has three parts .

  1. Warehouse level configuration files : In the warehouse .git/.gitconfig, This configuration file is only valid for the warehouse .
  2. Global profile :Mac The system is in ~/.gitconfig,Windows The system is in C:\Users\< user name >\.gitconfig.
  3. System level configuration files : stay Git Installation directory (Mac The installation directory under the system is /usr/local/git) Of etc In folder gitconfig.
  1. Profile of the current project

    git config --local user.name "xxx"
    git config --local user.email "xxx@xx.com"
    
  1. Global profile

    git config --global user.name "xxx"
    git config --global user.email "xxx@xx.com"
    
  2. System profile

    git config --system user.name "xxx"
    git config --system user.email "xxx@xx.com"
    
    #  Need to have root jurisdiction 
    

SSH

   Use SSH You can also push and pull code .

   ~ Represents the current directory .

  1. Generate public key and private key ( Default on ~/.ssh Under the table of contents ,id_rsa.pub For public key ,id_rsa For private key )

    ssh-keygen
    #  Keep going back , Generate the key 
    

       image-20201109122832255

  2. Copy the contents of the public key , Set to GitHub in

       image-20201109123020419

       image-20201109123054432

       image-20201109123124135

       image-20201109123151717

  3. stay Git Local configuration SSH Address

       image-20201109123341973

    git remote add origin git@github.com:KAKOFS/NBSite.git # ssh Address 
    
  4. Use the following command

    git push origin  Branch name 
    

fork Source code

   If you want to contribute to the source code of some frameworks , You can use the following steps to make a merge request to the Framework Developer .

  1. fork Source code , Copy other people's source code to my own remote repository .

       image-20201109124132770

       image-20201109124200913

       image-20201109124217238

       image-20201109124237459

  2. Modify the code in your own warehouse

       image-20201109145637856

       image-20201109145654209

  3. Submit a fix to the source code author bug apply .(pull request)

       image-20201109124413122

   image-20201109145734448

   image-20201109145751620

Ignore files

   Create... In the project .gitignore file , Input matching rules , All matching files in the current project will not be Git Managed by .

   image-20201109150445231

   image-20201109150350306

   image-20201109150458401

   You can also have more matching rules :

*.h 	 	#  Ignore .h The suffix file for 
!a.h  	 	#  But don't ignore a.h This file 
files/   	#  Ignore all files in this folder 
*.py[a|b|c] #  Ignore pya、pyb、pyc A file with a suffix 

issues&wiki

   issues You can ask some questions you find , Developers will give you answers .

   image-20201109150846433

   image-20201109151129671

   Use wiki To describe your project , So that the person who takes over your work after you leave will be familiar with the project more quickly .

   image-20201109151237537

Delete nonexistent branches

   When many people work together to develop , If the remote branch is removed by other development , Execute locally git branch --all The remote branch will still be displayed , You can use the following command to delete :

#  Use  pull  command , add to  -p  Parameters 
$ git pull -p

#  Equivalent to the following command 
$ git fetch -p
$ git fetch --prune origin

The command of

This order

   Here are some of the commands in this article :

command describe
git init initialization
git status Check the status
git add Manage assigned files
git commit -m " describe " Generate version
git log View version history ( Before )
git reflog View version history ( after )
git reset --hard Version number Version rollback
git branch View all branches
git branch Branch name Create a new branch
git checkout Branch name Switch branches
git merge Branch merging
git branch -d Branch name Delete the branch
git remote add Alias Address Remote warehouse takes alias
git push -u Alias Branch Push a branch to remote warehouse
git clone Address Clone remote warehouse code
git pull Alias Branch Pull a branch code from the remote warehouse , Incremental updating
git rebase -i HEAD~ Number of pieces Version merge

config

   Configuration related commands and parameters :

#  View configuration information 
# --local: Warehouse level ,--global: Global level ,--system: The system level 
$ git config <--local | --global | --system> -l

#  View the currently active configuration information 
$ git config -l

#  Edit profile 
# --local: Warehouse level ,--global: Global level ,--system: The system level 
$ git config <--local | --global | --system> -e

#  Add configuration item 
# --local: Warehouse level ,--global: Global level ,--system: The system level 
$ git config <--local | --global | --system> --add <name> <value>

#  Get configuration items 
$ git config <--local | --global | --system> --get <name>

#  Delete configuration items 
$ git config <--local | --global | --system> --unset <name>

#  Configure the user information in the submission record 
$ git config --global user.name < user name >
$ git config --global user.email < Email address >

#  change Git The size of the cache 
#  If the content submitted is large , The default cache is smaller , Submission will fail 
#  Cache size units :B, for example :524288000(500MB)
$ git config --global http.postBuffer < Cache size >

#  call  git status/git diff  The status of the change is displayed in highlight or color during the command 
$ git config --global color.ui true

#  Configuration can cache passwords , Default cache time 15 minute 
$ git config --global credential.helper cache

#  Configure password cache time 
#  Cache time units : second 
$ git config --global credential.helper 'cache --timeout=< Cache time >'

#  Configure long-term storage password 
$ git config --global credential.helper store

git clone

   Clone a version library from the remote repository to the local .

#  By default, a folder with the same name as the version library is created in the current directory and the version is downloaded to the folder 
$ git clone < Web address of remote warehouse >

#  Specify the directory of the local warehouse 
$ git clone < Web address of remote warehouse > < Local directory >

# -b  Specify the branch to clone , The default is master Branch 
$ git clone < Web address of remote warehouse > -b < Branch name > < Local directory >

git init

   Initialize the directory where the project is located , After initialization, a file named .git The catalog of .

#  Initialize local warehouse , Generate... In the current directory  .git  Folder 
$ git init

git status

   Check the status of the local warehouse .

#  Check the status of the local warehouse 
$ git status

#  View the status of the local warehouse in short mode 
#  Two columns will be displayed , The first column is the status of the file , The second column is the corresponding file 
#  File status :A  newly added ,M  modify ,D  Delete ,??  Not added to Git in 
$ git status -s

git remote

   Operate remote library .

#  List existing remote warehouses 
$ git remote

#  List the details of the remote warehouse , List... After the alias URL Address 
$ git remote -v
$ git remote --verbose

#  Add remote repository 
$ git remote add < Remote warehouse alias > < Remote warehouse URL Address >

#  Change the alias of the remote warehouse 
$ git remote rename < The alias of the original remote warehouse > < New alias >

#  Delete the remote warehouse with the specified name 
$ git remote remove < Remote warehouse alias >

#  Modify the remote warehouse  URL  Address 
$ git remote set-url < Remote warehouse alias > < New remote warehouse URL Address >

git branch

   operation Git The branch order of .

#  List all local branches , The current branch is  "*"  Mark out 
$ git branch

#  List all local branches and show last commit , The current branch is  "*"  Mark out 
$ git branch -v

#  Create a new branch , The new branch is based on the last commit 
$ git branch < Branch name >

#  Change branch name 
#  If the original branch name is not specified, it is the current branch 
$ git branch -m [< Original branch name >] < New branch name >
#  Force changes to branch name 
$ git branch -M [< Original branch name >] < New branch name >

#  Delete the specified local branch 
$ git branch -d < Branch name >

#  Force deletion of the specified local branch 
$ git branch -D < Branch name >

git checkout

   Detection command , Used to create 、 Switch branches, etc .

#  Switch to the specified branch that already exists 
$ git checkout < Branch name >

#  Create and switch to the specified branch , Keep all submission records 
#  Equate to  "git branch"  and  "git checkout"  Two orders merge 
$ git checkout -b < Branch name >

#  Create and switch to the specified branch , Delete all submission records 
$ git checkout --orphan < Branch name >

#  Replace the local changes , New files and content that has been added to the staging area are not affected 
$ git checkout < File path >

git cherry-pick

   Merge the submitted records into the current branch .

#  Merge the submitted records into the current branch 
$ git cherry-pick <commit ID>

git add

   Add the information of the file to be submitted to the staging area . When using git commit when , The document will be submitted according to the contents in the temporary storage area .

#  Add the specified file to the staging area 
$ git add < File path >

#  Add all changes 、 Deleted files to staging area 
$ git add -u [< File path >]
$ git add --update [< File path >]

#  Add all changes 、 deleted 、 New files to staging area , Omit  < File path >  This is the current directory 
$ git add -A [< File path >]
$ git add --all [< File path >]

#  View all changes 、 Documents deleted but not submitted , Enter a subcommand system 
$ git add -i [< File path >]
$ git add --interactive [< File path >]

git commit

   Submit the files in the staging area to the local warehouse .

#  Submit files in staging area to local warehouse , Call the text editor to input the description information of this submission 
$ git commit

#  Submit the files in the staging area to the local warehouse and add the description information 
$ git commit -m "< Description information submitted >"

#  Put all the changes 、 Deleted files are submitted to the local warehouse 
#  Does not include files that are not tracked by the version Library , It's the same as calling  "git add -u"
$ git commit -a -m "< Description information submitted >"

#  Modify last submitted description 
$ git commit --amend

git fetch

   Get the latest version from the remote warehouse to the local tmp On the branch .

#  Get all the latest versions of all branches of the remote warehouse back to the local 
$ git fetch < Remote warehouse alias >

#  Retrieve the latest version of the specified branch of the remote warehouse to the local 
$ git fetch < Remote host name > < Branch name >

git merge

   Merging branches .

#  Merge the specified branch under the current branch 
$ git merge < Branch name >

git diff

   Compare the differences between versions .

#  Compare the differences between the current file and the files in the staging area , Show changes that are not staged 
$ git diff

#  Compare the difference between the files in the staging area and the last commit 
$ git diff --cached
$ git diff --staged

#  Compare the difference between the current file and the last submission 
$ git diff HEAD

#  View changes since the specified version 
$ git diff <commit ID>

#  Compare the differences between the two branches 
$ git diff < Branch name > < Branch name >

#  Check the changes of the two branches after they are separated 
$ git diff < Branch name >...< Branch name >

git pull

   Get the latest version from the remote repository and merge it locally .

   First of all, it will execute git fetch, And then execute git merge, Get the branch of HEAD Merge into current branch .

#  Get latest version from remote warehouse .
$ git pull

git push

   Push the submission of the local warehouse to the remote warehouse .

#  Push the branch of the local warehouse to the specified branch of the remote warehouse 
$ git push < Remote warehouse alias > < Local branch name >:< Remote branch name >

#  Delete the branch of the specified remote warehouse 
$ git push < Remote warehouse alias > :< Remote branch name >
$ git push < Remote warehouse alias > --delete < Remote branch name >

git log

   Show submitted records .

#  Print all submission records 
$ git log

#  Print records from the first submission to the specified submission 
$ git log <commit ID>

#  Print a specified number of newly submitted records 
$ git log -< The specified quantity >

git reset

   Restore submission records .

#  Reset staging area , But the documents are not affected 
#  It's equivalent to using  "git add"  Command to update the contents of the staging area to withdraw from the staging area , You can specify a file 
#  Is not specified  commit ID  Default to current  HEAD
$ git reset [< File path >]
$ git reset --mixed [< File path >]

#  take  HEAD  Change of direction of , Withdraw to the specified submission record , File not modified 
$ git reset <commit ID>
$ git reset --mixed <commit ID>

#  take  HEAD  Change of direction of , Withdraw to the specified submission record , File not modified 
#  Equivalent to calling  "git reset --mixed"  I did it again after the order  "git add"
$ git reset --soft <commit ID>

#  take  HEAD  Change of direction of , Withdraw to the specified submission record , The document has also been revised 
$ git reset --hard <commit ID>

git revert

   Generate a new submission to undo a submission , All submissions prior to this submission will be retained .

#  Generate a new submission to undo a submission 
$ git revert <commit ID>

git tag

   Commands for manipulating tags .

#  Print all the labels 
$ git tag

#  Add lightweight labels , Reference to submitted object , You can specify the previous submission record 
$ git tag < Tag name > [<commit ID>]

#  Add a note label with descriptive information , You can specify the previous submission record 
$ git tag -a < Tag name > -m < Tag description information > [<commit ID>]

#  Switch to the specified label 
$ git checkout < Tag name >

#  Check the tag information 
$ git show < Tag name >

#  Delete the specified label 
$ git tag -d < Tag name >

#  Submit the specified tags to the remote warehouse 
$ git push < Remote warehouse alias > < Tag name >

#  Submit all local tags to remote warehouse 
$ git push < Remote warehouse alias > –tags

git mv

   Rename a file or folder .

#  Rename the specified file or folder 
$ git mv < Source file / Folder > < Target file / Folder >

git rm

   Delete files or folders .

#  Remove trace specified file , And delete... From the folder in the local warehouse 
$ git rm < File path >

#  Remove tracking specified folder , And delete... From the folder in the local warehouse 
$ git rm -r < Folder path >

#  Remove trace specified file , Keep the file in the folder of the local warehouse 
$ git rm --cached

reference

  1. git Practical courses
  1. Git Best practices in the team -- How to use it correctly Git Flow
  1. Git The command of

版权声明
本文为[Mr. yunya]所创,转载请带上原文链接,感谢