Git daily operation command

Time:2022-5-5

Git common operations

Configuration operation

Git config -- list # view git configuration information
git config user. Name # view git user name
git config user. Email # view mailbox configuration
git config --global user. Name "nameval" # global configuration user name
git config --global user. email " [email protected] "# global configuration mailbox"

basic operation

Git init # initialization project
Git add filename # adds the specified file
git add .                     # Add all files
Git commit - M "submit comments" # add a version
Git log # view the historical version (excluding the fallback part)
Git reflog # view the historical version (detailed, including the version of the fallback part)
Git reset -- the version number submitted by hard # returns to the specified historical version
After git push - F # fallback version, remote also fallback (forced push)
git check out                 #

git reset --soft
git reset head
git reset --mix

#Gitlab creates its own code hosting (based on Linux)

Branch operation

– base

Git clone - B branch name and warehouse address
Git branch - A // view online branches
Git branch // view local branches

-Create a new branch locally and push it to the remote warehouse

  1. Create local branch
Git checkout - b new branch name

After the instruction is executed, a new branch will be created locally. The branch is checked out from the current branch, so all file contents are exactly the same as the current branch, which is normal. After successful creation, it will automatically switch to the new branch.

Push local branch to remote warehouse

Git push -- set upstream origin branch name

-Pull branch to local

  1. When I want to pull one from the remote warehouseBranches that do not exist locallyWhen:
#Branches that do not exist locally
Git checkout - B local branch name origin / remote branch name

This will automatically create a new local branch and associate it with the specified remote branch.

If successful, a new branch dev2 will be created locally and automatically switched to dev2.

If prompted:

fatal: Cannot update paths and switch to branch 'dev2' at the same time.
Did you intend to checkout 'origin/dev2' which can not be resolved as commit?

Indicates that the pull is unsuccessful. We need to do it first

git fetch

Then execute

Git checkout - B local branch name origin / remote branch name
  1. Locally existing branches
#Current branch
git pull

#Other local branches (existing)
Git pull branch name

If git pull fails, useGit pull origin branch nameJust fine)

Delete remote branch

Git branch - a # view existing local and remote branches
Delete # remote branch --
Git remote prune origin # synchronize remote branches (delete local branches)
Git remote show origin # view remote branches

Git branch - D dev # delete local branch

Push to remote

git remote add origin ....... #  Add git address
Git push origin dev push to online dev branch
Git pull origin dev gets the dev branch on the line

If the submitted code is later than the code of GitHub line, there will be an error prompt asking you to pull the code again
Pulling the code will prompt you to merge the code

git pull origin dev =  git fetch origin dev  
                    +  git merge origin/dev


The code of GIT pull will be forked (there are cases where the code has been committed but forgotten to submit: for example, the code opened in the company has been committed but forgot to submit, go home and continue to develop and submit, and the pull code of Dudu company will be forked the next day)

The following method will not have bifurcation
git fetch origin dev
Git rebase origin / dev #rebase keep the submitted records clean

stash

git stashSave “save message”: when saving, add notes to facilitate searching. Only git stash is OK, but it is not easy to identify when searching.

git stash list: see what storage is stash

git stash show: displays the changes made. The first storage is shown by default. If you want to display other storage, add stash @ {$num}, such as git stash show stash @ {1}

git stash show -p: display the changes of the first storage. If you want to display other storage, command: git stash show stash @ {$num} – P, for example, the second: git stash show stash @ {1} – P

git stash apply: applies a storage, but does not delete it from the storage list. The first storage is used by default, that is, stash @ {0}. If you want to use other storage, GIT stash apply stash @ {$num}, such as the second: git stash apply stash @ {1}

git stash pop: the command restores the previously cached working directory, deletes the corresponding stash in the cache stack, and applies the corresponding modification to the current working directory. The default is the first stash, that is, stash @ {0}. If you want to apply and delete other stash, the command: git stash pop stash @ {$num}, for example, apply and delete the second: git stash pop stash @ {1}

git stash dropStash @ {$num}: discard the stash @ {$num} storage and delete it from the list

git stash clear : delete all cached stash

tag

List labels

$ git tag
v1.0
v2.0

1.8.5 series interested, can run:

$ git tag -l "v1.8.5*"

create label

  • Note label

Creating annotation labels in Git is simple. The easiest way is when you’re runningtagSpecify at command time-aOptions:

$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4
  • Lightweight label

Another way to label submissions is to use lightweight labels. Lightweight tags essentially store the submitted checksum in a file — without saving any other information. Create lightweight labels that do not need to be used-a-sor-mOption, you only need to provide the tag name:

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
  • Post labeling

You can also label past submissions. Suppose the submission history is as follows:

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

Now, suppose in V1 At 2:00, you forgot to label the project, that is, submit it in “updated rake file”. You can fill in the label later. To label that submission, you need to specify the submitted checksum (or partial checksum) at the end of the command:

$ git tag -a v1.2 9fceb02

You can see that you have labeled that submission:

Shared Tags

By default,git pushThe command does not transfer the tag to the remote warehouse server. After creating the tag, you must explicitly push the tag to the shared server. This process is like sharing a remote branch – you can run itgit push origin

$ git push origin v1.5

If you want to push a lot of tags at one time, you can also use the tag with--tagsOptionalgit pushCommand. This will send all tags that are not on the remote warehouse server there.

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To [email protected]:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw

delete a tap

To remove the tag from your local warehouse, use the commandgit tag -d 。 For example, you can delete a lightweight label using the following command:

$ git tag -d v1.4-lw
Deleted tag 'v1.4-lw' (was e7d5add)

Note that the above command does not remove this tag from any remote warehouse. You must usegit push :refs/tags/To update your remote warehouse:

The first variant isgit push :refs/tags/

$ git push origin :refs/tags/v1.4-lw
To /[email protected]:schacon/simplegit.git
 - [deleted]         v1.4-lw

The meaning of the above operation is to push the null value before the colon to the remote tag name, so as to delete it efficiently.

The second more intuitive way to delete remote tags is:

$ git push origin --delete <tagname>

Check out label

If you want to see the version of the file pointed to by a tag, you can usegit checkoutCommand, although this will put your warehouse in the “detached head” state – this state has some bad side effects:

$ git checkout 2.0.0
Note: checking out '2.0.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch>

HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final

$ git checkout 2.0-beta-0.1
Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
HEAD is now at df3f601... add atlas.json and cover image

In the “split header pointer” state, if you make some changes and submit them, the label will not change, but your new submission will not belong to any branch and will not be accessible unless it is accessed through the exact submission hash. Therefore, if you need to make changes, such as fixing errors in the old version, you usually need to create a new branch:

$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'

If another submission is made after that,version2The branch will move forward because of this change, and it will interact withv2.0.0The label is slightly different, so be careful.

other

1. Modify the notes submitted

git commit –amend