Distributed version control tool--Git

Introduction to version control

Centralized version control

A centralized version control system has a central server. Everyone needs to get the latest version from the central server when working. After modification, they submit it to the central server. Others then get the latest code to make changes. The disadvantage of this method is that we must have a central server. When we cannot connect to the server or the server is down due to network and other reasons, we cannot obtain and submit data; and since it is an Internet operation, the network environment will also affect it. Submission and download speed. Commonly used centralized version systems include CVS and SVN, as shown below.
Insert image description here

Distributed version control

Distributed version control (DVCS) is a method of managing file versions that does not require a central server, but there is usually a computer that acts as a "central server", but this server is only used to facilitate the exchange of our modifications. Without it, we It's the same job, but it's not very convenient when swapping and modifying. The distributed design concept helps reduce dependence on the central warehouse, thereby effectively reducing the load on the central warehouse and improving the flexibility of code submission. The commonly used distributed version control is Git, as shown below.
Insert image description here
Another benefit brought by Git's distributed design concept is support for offline work. For C/S tools such as CVS and SVN that rely heavily on the network, code check-in and check-out operations cannot proceed normally without the network or VPN. With Git, even on a plane or train without WiFi, we can still submit code frequently. We just submit it to the local warehouse first, wait for the network to connect, and then upload it to the remote mirror warehouse.
The Git distributed version control system has no central server. Each site has a complete version library, but each site is just a computer we use for development. We can modify and submit locally. When we need to merge code, we only need to push our own version library to our partners, so that the other parties can see the changes. Similarly, the other party can also push its own version library to us, so that we can see the other party's modifications. Since everyone's computer has a complete version library, if you accidentally lose data, you only need to make a copy from another place.

Git installation

The installation under Debian and Ubuntu systems is as follows:

$apt-get install git

The installation under CentOS and Fedora systems is as follows:

$yum update
$yum install git

Common Git commands

The main areas of Git are as follows

  • Workspace: The directory visible on your computer that holds the actual files.
  • Cache area: temporarily saves our changes.
  • Repository: There is a hidden directory .git in the workspace, which is the Git repository.
  • Remote warehouse: A project version library hosted on the Internet or other networks, which can be used for distributed development by multiple people.
    Insert image description here

Git configuration items

Show current Git configuration

$ git config --list

Edit Git configuration file

$ git config -e [--global]

Set user information

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

Git's settings file is .gitconfig, which can be configured globally or only for the project.

Create a new warehouse

Create a new Git repository in the current directory

$ git init

Create a new directory and initialize it as a Git repository

$ git init [project-name]

Clone a repository

$ git clone [url]

Add and delete files

Add specified files to the staging area

$ 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 cache

$ git add .

Delete the workspace file and put the deletion into the cache

$ git rm [file1] [file2] ...

Rename the file and put this rename into the cache

$ git mv [file-original] [file-renamed]

Submit documents

Submit cache area to warehouse area

$ git commit -m [message]

Submit the specified file in the cache area to the warehouse area

$ git commit [file1] [file2] ...  -m [message]

Submit the changes in the workspace since the last commit and submit them directly to the warehouse area.

$ git commit -a

Display all diff information when submitting

$ git commit -v

Use a new commit to replace the previous commit.
If there are no new changes to the code, use it to rewrite the commit information of the previous commit.

$ git commit --amend -m [message]

Git branch

List all local branches

$ git branch

List all remote branches

$ git branch -r

List all local and remote branches

$ git branch -a

Create a new branch but stay on the current branch

$ git branch [branch-name]

Create a new branch and switch to it

$ git checkout -b [branch]

Create a new branch and establish a tracking relationship with the specified remote branch

$ git branch --track [branch] [remoe-branch]

Switch to the specified branch and update the workspace

$ git checkout [branch-name]

switch to previous branch

$ git checkout -

Establish a tracking relationship between an existing branch and a specified remote branch

$ git branch --set-upstream [branch] [remote-branch]

Merge the specified branch into the current branch

$ git merge [branch]

Select a commit and merge it into the current branch

$ git cherry-pick [commit]

delete branch

$ git branch -d [branch-name]

Delete remote branch

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

Git tags

List all tags

$ git tag

Create a new tag on the current commit

$ git tag [ tag ]

Create a new tag on 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 specified tag

$ git push [ remote ] [ tag ]

Submit all tags

$ git push [ remote ] --tags

Create a new branch pointing to a certain tag

$ git checkout -b [ branch ] [ tag ]

View information

Show changed files

$ git status

Show the version history of the current branch

$ git log

Search submission history based on keywords

$ git log -S [keyword]

Display who modified the specified file and when

$ git blame [file]

Show differences between staging area and work area

$ git diff

Show the difference between the staging area and the previous commit

$ git diff --cached [file]

Shows the differences between the workspace and the latest commit of the current branch

$ git diff HEAD

Show metadata and content changes between two commits

$ git diff [first-branch] ... [second-branch]

Display files that have changed in a commit

$ git show --name-only [commit]

remote sync

Download all changes in the remote repository

$ git fetch [ remote ]

Show all remote repositories

$ git remote -v

Display information about a remote warehouse

$ git remote show [ remote ]

Add a new remote repository and name it

$ git remote add [ shortname ] [ url ]

Retrieve changes from remote repository and merge with local branch

$ git pull [ remote ] [ branch ]

Upload the local specified branch to the remote warehouse

$ git push [ remote ] [ branch]

Force push the current branch to the remote repository even if there are conflicts

$ git push [ remote ] --force

Push all branches to the remote repository

$ git push [ remote ] -all

Cancel

Restore the specified files in the staging area to the workspace

$ git checkout [ file ]

Restore the specified files of a commit to the staging area and work area

$ git checkout [ commit ] [ file ]

Restore all files in the staging area to the workspace

$ git checkout .

Reset the specified file in the staging 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 HEAD of the current branch to the specified commit and reset the staging area, but the workspace remains unchanged.

$ git reset [ commit ]

Reset the HEAD of the current branch to the specified commit, and reset the staging area and work area to be consistent with the specified commit.

$ git reset --hard [ commit ]

Reset the current HEAD to the specified commit, but keep the staging area and work area 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 ]

Temporarily remove uncommitted changes and move them in later

$ git stash

Guess you like

Origin blog.csdn.net/yiyu20180729/article/details/129951429