Git full stack developer’s Guide

Time:2021-1-18

1、 Git Foundation

Git full stack developer's Guide

1. About Git

Git is a distributed version control system developed by Linus, the father of Linux.

The so-called distributed version management system is to have a complete warehouse on each machine.

Git full stack developer's Guide

2. Git website

Git website:git

Git full stack developer's Guide

Git installation software is available on the official website.

In addition, you can download progit, the best git learning material available in Chinese.

3. Git installation

from https://git-scm.com/downloadsDownload the corresponding operating system version from the official download address and install it step by step.

Git full stack developer's Guide

4. Git basic configuration

After installation, right-click in any directoryGit Bash Here

Git full stack developer's Guide

Global configuration mailbox and user name(–globalIndicates global configuration, or not, each warehouse is configured separately.)

$ git config --global user.name "test"
$ git config --global user.email [email protected]

5. Git basic concepts

5.1 git work area

Git has four working areas:

  • work area

    In short, the workspace is the directory of our project.

    Git full stack developer's Guide

  • Warehouse area / local warehouse

    There is one in the workspace.gitIn fact, this is not a workspace, but a git version library, which stores all the version information of GIT warehouse

    Git full stack developer's Guide

    Git full stack developer's Guide

  • Temporary storage area

    The staging area is a file that stores the list information of files to be submitted next time, usually in the GIT warehouse directory. Sometimes it’s called an index,

    But generally speaking, it is still called temporary storage area.

  • Remote warehouse

    For distributed version management system, remote warehouse is not necessary, but usually the project will have remote warehouse. for exampleGithubWe are very familiar with the remote warehouse.

    Git full stack developer's Guide

    The basic git workflow is as follows:

    • Modify the file in the working directory
    • Temporary file, put the file snapshot into the temporary storage area
    • Submit the update, find the files in the staging area, and store the snapshot permanently in Git warehouse (local)
    • Push changes from local warehouse to remote warehouse

The relationship between the above areas can be shown as follows:

Git full stack developer's Guide

5.2 git branch

Branching is to store the whole process of modifying records separately, so that the separated branches are not affected by other branches, so multiple different modifications can be made in the same database at the same time.

Git full stack developer's Guide

Git is the first branch that we automatically create, also known as the main branch. Generally, other branches are merged into the master after development

Git full stack developer's Guide

5.3 git file status

In git, files have four main states

Git full stack developer's Guide

  • Untracked: not tracked, this file is in the folder, but it is not added to git library and does not participate in version controlgit addThe state changes toStaged.
  • Unmodify(committed): the file has been put into storage and has not been modified, that is, the snapshot content of the file in the version library is exactly the same as that in the folder. There are two places for this type of file. If it is modified, it becomesModified. if usedgit rmIf you move it out of the repository, it becomesUntrackedfile
  • Modified: the file has been modified, only modified, and no other operations have been carried out. This file also has two places to go, through thegit addAccess to temporary storagestagedStatus, usinggit checkoutDiscard the modification and return to theunmodifyState, thisgit checkoutThat is to take out the file from the library and cover the current modification
  • Staged: temporary state. Executiongit commitThen the changes will be synchronized to the library. At this time, the files in the library and the local files will be the same, and the files will be the sameUnmodifyStatus. Executiongit reset HEAD filenameCancel temporary storage, file status isModified

2、 Git application practice

After reading the above git foundation, you may be confused. Next, let’s deepen our understanding of GIT by using the process developed in the actual work.

1. Clone project

You can use thegit initTo initialize a git repository, but we usually don’t do this during development, because most of the actual projects have been partially developed and version managed, so the first thing we do is clone the project from the remote repository.

Here I start from gitee (the remote warehouse of general development project is gitlab deployed in intranet)forkWe have developed an open source project as a remote warehouse project

Git full stack developer's Guide

clickClone DownloadYou can see the path of the project,

  • HTTPSIt is a path of credential type. Using this path, credentials (account and password) are required when pushing code to the remote warehouse;

    This way to submit to the remote warehouse, will require the account password, after input, win10 operating system can choose to remember the credentials, so that you do not have to input every time, win10 operating system management credentialsControl panel → user account → credential manager → windows credentials

    Git full stack developer's Guide

  • SSHIt is a secret key path. When pushing code to the remote warehouse, the local private key should correspond to the public key of the remote warehouse.

    SSH configuration can refer toWindows configures git environment in which GitHub and gitee coexistWe will not explain it in detail here.

I have configured the public and private keys, so I choose SSH here.

Git full stack developer's Guide

usegit cloneCommand clone project

Git full stack developer's Guide

2. Code management

The project has been cloned successfully, and we are going to develop it.

2.1. Creating branches

Usually, the development is not in progressMasterOn the branch, but on the development branch, usegit branch developCreate a new branch:

Git full stack developer's Guide

Can passgit branchCommand to list all branches:

Git full stack developer's Guide

You can see our new branch.

2.2 switching branches

usegit checkout developCommand to switch to the new development branch:

Git full stack developer's Guide

2.3. Add files to the temporary storage area

Next, we’ll do some development operations on the development branch. I’ve made some modifications to redeme, which need to be added to the staging area.

  • First of allgit statusCommand to view workspace file status

    Git full stack developer's Guide

  • Next, usegit add README.mdCommand (you can usegit add .Add all modifications) to add changes to the staging area

Git full stack developer's Guide

You can see that the file has been added.

2.4 submit modification to warehouse

Next, useGit commit - M "redeme modified", submit the changes to the warehouse

Git full stack developer's Guide

It is worth mentioning here that our submitted information should follow certain specifications as far as possible. For example, the type of this submission should be reflected in the submitted information:

  • feat: new features
  • fix: bug fix
  • docs: document change
  • style: all style related changes
  • refactor: a code change that is neither a bug fix nor a feature addition
  • test: all changes related to testing
  • chore: changed build task, package manager configuration, etc

Standard and accurate submission information can not only help our colleagues quickly understand our submission, but also help our own development and refactoring. I like to use the expression package to mark the submission type, which makes the submission records look better from the remote warehouse

Git full stack developer's Guide

Can passgit logCommand to view submission history:

Git full stack developer's Guide

2.5 push modification to remote warehouse

have access togit push origin developThe command pushes the changes to the remote warehouse, usually through thegit pull origin develop(in this example, there is no development branch in the remote warehouse, so you can directly push) command to pull the remote warehouse. This is to avoid the backwardness of the local version. Of course, if there is a conflict, you can also force it to be submitted. It’s just that your colleagues will do something drastic and dare not guarantee it.

Git full stack developer's Guide

You can see this submission in our remote warehouse:

Git full stack developer's Guide

2.6. Merging branches

In the end, our submission is to be merged intomasterBranch, first switch tomasterBranch, and then by command,git merge developOrder, willdevelopBranch merge tomaster

Git full stack developer's Guide

There is no conflict in our branch. There may be conflicts in the process of merging. You cangit statusView the conflicting files and resolve the conflict manually. Of course, we can use some development tools to complete this work, which will be discussed later.

2.7 version rollback

If we find that this submission is not what we want, it can be approvedgit reset --hard HEAD^Go back to last commit

Git full stack developer's Guide

2.8 labeling

If we want to release a version, we usually label this submissiongit tag publish/0.0.1

Git full stack developer's Guide

Can passgit tagCommand to see the tags we typed.

3、 Git common commands

There is such a picture above. Basically, it’s OK to remember these six commands for daily use. But if you want to use them skillfully, you may need to remember more commands. Here are some common commands.

Git full stack developer's Guide

1. Initialize warehouse

#Create a new git Library in the current directory
    $ git init

    #Create a new directory and initialize it as git code base
    $ git init [project-name]

    #Download a project and its entire code history
    $ git clone [url]

2. Configuration

Git’s setting file is. Gitconfig, which can be in the user’s home directory (global configuration) or in the project directory (project configuration).

#Displays the current git configuration
    $ git config --list

    #Displays a configuration of GIT
    $ git config <key>

    #Edit git profile
    $ git config -e [--global]

    #Set the user information when submitting the code, and select global, that is, global configuration
    $ git config [--global] user.name "[name]"
    $ git config [--global] user.email "[email address]"

3. Add / delete files

Adding / deleting files here refers to adding / deleting files to the staging area.

#View the file status, and view the files added, changed, or deleted in the current workspace
    $ git status
     
    #Add the specified file to the temporary storage area. You can add multiple files separated by spaces
    $ git add [file1] [file2] ...

    #Add the specified directory to the staging area, including subdirectories
    $ git add [dir]

    #Add all files in the current directory to the staging area
    $ git add .

    #Confirmation is required before each change is added
    #For multiple changes of the same file, it can be submitted in batches
    $ git add -p

    #Delete the workspace file and put this deletion into the staging area
    $ git rm [file1] [file2] ...

    #Stops tracking the specified file, but it remains in the workspace
    $ git rm --cached [file]

    #Rename the file, and put the rename into the temporary storage
    $ git mv [file-original] [file-renamed]
    
    #Save the modification temporarily and Cross branches
    #Save is optional
    $ git stash [save message]
    #List of all saved records
    $ git stash list
    #Restore the work progress to the workspace. The stash @ {num} of this command is optional. You can choose to restore among multiple work progress. Without this item, the latest progress will be restored by default, which is equivalent to git stash pop stash @ {0}
    $ git stash pop [[email protected]{num}]
    #Restore the work progress to the workspace, and the work progress can be restored repeatedly. The stash @ {num} of this command is optional. You can choose to restore among multiple work progress. Without this item, the latest progress will be restored by default, which is equivalent to git stash apply stash @ {0}
    $ git stash apply [[email protected]{num}]
    #Delete a saved work progress. The stash @ {num} of this command is optional. You can choose to delete among multiple work progress. Without this item, the latest progress will be deleted by default, which is equivalent to git stash drop stash @ {0}
    $ git stash drop [email protected]{num} 
    #Delete all saved
    $ git stash clear

4. Code submission

#Submit the staging area to the warehouse area. If you do not add - m, you will enter the VIM editor
    $ git commit -m [message]

    #Submit the specified file of temporary storage area to warehouse area
    $ git commit [file1] [file2] ... -m [message]

    #Submit the changes of the workspace since the last commit, directly to the warehouse area
    $ git commit -a

    #Show all diff information on submit
    $ git commit -v

    #Replace the previous commit with a new commit
    #If there are no new changes in the code, it is used to rewrite the commit information of the last commit
    $ git commit --amend -m [message]

    #Redo the last commit, including new changes to the specified file
    $ git commit --amend [file1] [file2] ...

5. Branches

#List all local branches
    $ git branch

    #List all remote branches
    $ git branch -r

    #List all local branches和远程分支
    $ git branch -a

    #Create a new branch, but stay in the current branch
    $ git branch [branch-name]

    #Create a new branch and switch to it
    $ git checkout -b [branch]

    #Create a new branch and point to the specified commit
    $ git branch [branch] [commit]

    #Create a new branch to establish a tracking relationship with the specified remote branch
    $ git branch --track [branch] [remote-branch]

    #Switch to the specified branch and update the workspace
    $ git checkout [branch-name]

    #Switch to the previous branch
    $ git checkout -

    #Establish a tracing relationship between an existing branch and a specified remote branch
    $ git branch --set-upstream [branch] [remote-branch]

    #Merge the specified branch to the current branch
    $ git merge [branch]
   
    #View branch merge status
    $  git rerere status
   
    #Displays the current state of the merge conflict resolution - before and after resolution
    $  git rerere diff

    #Select a commit and merge it into the current branch
    $ git cherry-pick [commit]
    
    #Branch rename
    $ git git branch -m [oldName]  [newName]
    #Delete branch
    $ git branch -d [branch-name]

    #Delete remote branch
    $ git push origin --delete [branch-name]
    $ git branch -dr [remote/branch]

6. Label

#List all tags
    $ git tag

    #Create a new tag in the current commit
    $ git tag [tag]

    #Create a new tag in the specified commit
    $ git tag [tag] [commit]

    #Delete local tag
    $ git tag -d [tag]

    #Delete remote Tag
    $ git push origin :refs/tags/[tagName]

    #View tag information
    $ git show [tag]

    #Submit the specified tag
    $ git push [remote] [tag]

    #Submit all tags
    $ git push [remote] --tags

    #Create a new branch and point to a tag
    $ git checkout -b [branch] [tag]

7. View information

#Show changed documents
$ git status

#Displays the version history of the current branch
$ git log

#Displays the commit history and the file that changes each commit
$ git log --stat

#Search submission history based on keywords
$ git log -S [keyword]

#Show all changes after a commit, each commit occupies one line
$ git log [tag] HEAD --pretty=format:%s

#To display all changes after a commit, its "submit description" must meet the search criteria
$ git log [tag] HEAD --grep feature

#Displays the version history of a file, including file renaming
$ git log --follow [file]
$ git whatchanged [file]

#Displays each diff related to the specified file
$ git log -p [file]

#Show last 5 submissions
$ git log -5 --pretty --oneline

#Display all submitted users, sorted by the number of submitted users
$ git shortlog -sn

#Displays who the specified file was and when it was modified
$ git blame [file]

#Displays the difference between the staging area and the workspace
$ git diff

#Shows the difference between the staging area and the previous commit
$ git diff --cached [file]

#Displays the difference between the workspace and the latest commit of the current branch
$ git diff HEAD

#Shows the difference between the two submissions
$ git diff [first-branch]...[second-branch]

#Shows how many lines of code you wrote today
$ git diff --shortstat "@{0 day ago}"

#Displays the metadata and content changes of a submission
$ git show [commit]

#Displays the files that have changed during a commit
$ git show --name-only [commit]

#Displays the contents of a file at the time of a submission
$ git show [commit]:[filename]

#Displays the most recent commits of the current branch
$ git reflog

8. Remote synchronization

#Clone remote warehouse
$ git clone [url]

#Download all changes of remote warehouse
$ git fetch [remote]

#Show all remote warehouses
$ git remote -v

#Displays information about a remote warehouse
$ git remote show [remote]

#Add a new remote warehouse and name it
$ git remote add [shortname] [url]

#Retrieve the changes of the remote warehouse and merge with the local branch
$ git pull [remote] [branch]

#Pull the remote branch and create the local branch at the same time
$git fetch [remote] remote branch name x: local branch name x
#Pull the remote branch and create the local branch at the same time,且切换到该分支
$git checkout - B [branch] [origin / remote branch name]

#Git pull is equivalent to the following two steps
#1. Pull the remote branch
$ git fetch [remote] [branch]
#2. Merge to current branch
git merge [remote/branch]

#Upload local specified branch to remote warehouse
$ git push [remote] [branch]

#Forcibly push the current branch to the remote warehouse, even if there is a conflict
$ git push [remote] --force

#Push all branches to remote warehouse
$ git push [remote] --all

#Update remote branch list
$ git remote update [remote] --prune
$ git remote update [remote] -p

#Delete association with remote warehouse
$ git remote rm [remote]

9. Revocation

#Restore the specified file from the scratch area to the workspace
$ git checkout [file]

#Restore the specified file of a commit to the staging area and workspace
$ git checkout [commit] [file]

#Restore all files in the staging area to the workspace
$ git checkout .

#Reset the specified file in the temporary storage area to be consistent with the last commit, but the workspace remains unchanged
$ git reset [file]

#Reset the staging area and workspace to be consistent with the last commit
$ git reset --hard

#Reset the pointer of the current branch to the specified commit, and reset the buffer, but the workspace remains unchanged
$ git reset [commit]

#Go back to last commit
$ git reset --hard HEAD^
#Reset the head of the current branch to the specified commit, and reset the buffer and workspace at the same time, consistent with the specified commit
$ git reset --hard [commit]

#Reset the current head to the specified commit, but leave the scratch area and workspace unchanged
$ git reset --keep [commit]

#Create a new commit to undo the specified commit
#All changes in the latter will be offset by the former and applied to the current branch
$ git revert [commit]

#Remove the uncommitted changes temporarily and move them in later
$ git stash
$ git stash pop

4、 Using git in development tools

In git, some operations such asConflict resolutionBranch comparisonAnd so on, using graphical operation may be more convenient.

Tortoise Git is a good graphical git tool, which is a good choicehttps://tortoisegit.org/downl…

Git full stack developer's Guide

Of course, using development tools to integrate Git is also a good choice.

1. Using git in idea

Idea is the best java development ide at present. By default, idea integrates git support. You only need to configure the executable program.

1.1. Configure Git

  • File –> Settings–> Version Control –> Git, modify the GIT execution path to the GIT path you installed.

Git full stack developer's Guide

  • Click test, and git version information will be prompted if the configuration is successful

Git full stack developer's Guide

1.2 remote operation

Idea can be very convenient for remote warehouse related operations.

1.2.1 pull code

Through idea, you can directly pull the code of remote warehouse

  • File –> New —> Project From Version Controller –> Git

Git full stack developer's Guide

  • Fill in the remote warehouse address and selectClone

Git full stack developer's Guide

In this way, the code of the remote warehouse is cloned locally.

1.2.2 pull remote branch

We can also pull the remote branch code. In the lower right corner, click to open the branch.

Git full stack developer's Guide

You can see thatRemote BranchsHere is the branch of the remote warehouse. Click remote branch,Checkout As, you can pull the remote branch to the local.

Git full stack developer's Guide

1.2.3 update code

We’d better update the code of the remote warehouse to the local warehouse before submitting the code, so as to reduce unnecessary conflicts. Update can be done directly through the shortcut keyCtrl + T It can also be realized by pressing buttons on the toolbar

Git full stack developer's Guide

1.2.4. Submit / push code

How to submit your code to the remote warehouse after developing it in idea?Right click item–>Git

Git full stack developer's Guide

  • 1.Commit Directory: commit code (submit the temporary files in the stage area to the local warehouse of the current branch and empty the stage area), or push code (synchronize the files in the local warehouse to the remote warehouse).

Git full stack developer's Guide

    • Commit corresponds to git’s commit command. Commit to the local warehouse
    • Commit and push means commit and push. We can commit to the local warehouse and then push to the remote warehouse.

In idea, we can see that the files are marked with different colors: red, green and blue. What do they mean?

  • Red: files that are not under version control, that is, files that are not added to version control, such as files that we add toignoreFile in.
  • Green: the newly added version of the file, that is, our newly created file, has not been submitted to the remote warehouse.
  • Blue: the modified file, that is, the file already exists in the remote warehouse. We have modified it this time, but it has not yet been submitted.

Here, let’s look at the functions of several buttons:

Git full stack developer's Guide

2.Add: add the local file from the working directory to the stage area of the local warehouse, corresponding to git’s add command.

3.Compare with Branch…: compared with remote branches. Before submitting, we can use this function to compare the code in our working directory and the remote branch code.

4.Show History: view historical modification version records.

5.Revert: rollback will roll back your local changes.

6.Repository: various warehouse commands.

Git full stack developer's Guide

1.3 branch management

1.3.1 new branch

Click new branch to create a new branch

Git full stack developer's Guide

1.3.2 branch switch / compare / merge / rename / delete

In idea, the use of these functions is often simple. Click the branch and the branch to be operated to see these options

Git full stack developer's Guide

1.4. View submission history

againVersion ControllerinlogYou can view the submission history

Git full stack developer's Guide

1.5 merger (dealing with conflicts)

We mentioned branch merging above, which can be merged from local branches or from remote warehouses. Generally, there are conflicts in the merging of two parallel development branches. It is very convenient to merge conflicts in idea.

  • If there is a conflict in the merging process, idea will prompt the conflict and selectMerge

Git full stack developer's Guide

  • Idea provides three columns. We can click the arrow to handle conflicts easily

Git full stack developer's Guide

  • If it is not processed during merging, it can also be processed inVersion ControllerMedium treatment

Git full stack developer's Guide

2. Using git in vs Code

Vs code is the most popular front-end development tool. The support of vs Code for Git is not so powerful, but the function of GIT can be enhanced through plug-ins.

2.1 basic use

2.1.1 basic interface

My vs code is configured with Chinese package.

Click the GIT logo on the left to see a lot of operations.

Git full stack developer's Guide

2.1.2 file status

When a file is modified, there are three states

Git full stack developer's Guide

  • M is the abbreviation of modify, that is, the file is modified
  • D is the abbreviation of delete, that is, the file has been deleted
  • U is short for update, which means the file is newly added

2.1.3 submission code

Git full stack developer's Guide

The meaning of the file button.

  • If it is a newly added file, abandoning the modification will prompt to delete the file completely.
  • If it is a deleted file, if you choose to abandon the modification, the file will be recovered from the warehouse (no need to worry about missing the deleted file)
  • Click the + sign to confirm the modification of the file and it will be mentioned in stash changes(corresponding to git add command)

Git full stack developer's Guide

After confirming the file, enter the content of this update in the input box, and then click tick to save this update(corresponding to git commit command)
If you want to commit all the current changes, you can input the uploaded information directly and check it to commit quickly.

2.1.4 push code

After submitting, the number of the up arrow is 1 in the lower left corner of vscode (the up arrow is the update of push, and the down arrow is the update of pull)
Of course, if there is no push code before, there may be no digital display.
At this time, you can push the code to the remote warehouse(corresponding to git push command)

Git full stack developer's Guide

OK, the remote warehouse can see our submission.

Git full stack developer's Guide

2.1.5 pull code

You can also see whether the warehouse can be pulled through the down arrow in the lower left corner of vscode, and then click git pull in the menu to update the warehouse (corresponding togit pull(command)

Git full stack developer's Guide

2.1.5 branch switching

Vscode can create branches directly in the lower left corner or switch branches.

Git full stack developer's Guide

The above functions meet the basic requirements, if necessaryCode comparisonConflict resolution, you can choose plug-ins, and gitlens is generally recognized as the best plug-in.

2.2. Using git plug-in

2.2.1. Install gitlens

Open the plug-in store and searchGitLensIt can be installed.

Git full stack developer's Guide

2.2.2 basic use of gitlens

After the installation is completed, a git branch icon will appear on the sidebar. Click to view more detailed information.

Git full stack developer's Guide

  • The first panel collapses to see all submissions
  • The second fold panel looks at the history of the currently open file
  • The third panel collapses to see the branches
  • Fourth fold panel to view remote
  • The fifth fold panel looks at stash’s files
  • The sixth fold panel looks at the label
  • The seventh fold panel can compare the file differences of different branch labels

Git full stack developer's Guide

At the same time, it is found that each line of code will display the submitted person and submitted information

Git full stack developer's Guide

2.2.3 view changes

After modifying the file, there will be a color block on the side of gitlens to tell you how the code is updated

  • The red arrow indicates deletion
  • The blue block indicates the modification
  • A green block indicates an increase

Git full stack developer's Guide

Click in the upper right cornerView changesTo view changes to the current file.

Git full stack developer's Guide

Git full stack developer's Guide

2.2.4 handling conflicts

The built-in git of vscode will tell you the conflicting files, and then gitlens can quickly adjust the conflicts.

Git full stack developer's Guide

Git full stack developer's Guide

< big > reference

【1】:Git can’t let go

【2】:Sorting out common git commands

【3】:Git branch management strategy

【4】:vue-blog

【5】:《progit》

【6】:Windows configures git environment in which GitHub and gitee coexist

【7】:Full use process of vscode combined with git (Part one)

【8】:Full use process of vscode combined with git (Part 2)