Git general commands and methods

Git general commands and methods

img

The following is a list of commonly used Git commands I have compiled. The translations of several special terms are as follows.

  • Workspace: workspace
  • Index / Stage: staging area
  • Repository: warehouse area (or local warehouse)
  • Remote: remote warehouse

Local branch association remote

git branch --set-upstream-to=origin/Branch name

What if the code base does not push after changing the password?

// Re enter password
git config --system --unset credential.helper
// Password store synchronization
git config --global credential.helper store

1, New code base

# Create a Git code base in the current directory
$ git init

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

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

2, Configuration

The settings file for Git is gitconfig, which can be in the user's home directory (global configuration) or in the project directory (project configuration).

# Show current Git configuration
$ git config --list

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

# Set user information when submitting code
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"

3, Add / delete file

# Add the specified file 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 staging area
$ git add .

# Ask for confirmation before adding each change
# For multiple changes of the same file, multiple submissions can be realized
$ git add -p

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

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

# Rename the file and put the rename in the staging area
$ git mv [file-original] [file-renamed]

4, Code submission

# Submit staging area to warehouse area
$ git commit -m [message]

# Submit the specified files in the staging area to the warehouse area
$ git commit [file1] [file2] ... -m [message]

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

# Show all diff information when submitting
$ git commit -v

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

# Redo the last commit and include the new changes of the specified file
$ git commit --amend [file1] [file2] ...

5, Branching

# 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 still stay in the current branch
$ git branch [branch-name]

# Create a new branch based on the remote branch and switch to it
$ git checkout -b [branch] origin/[remote-branch]

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

# Create a new branch and 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 previous branch
$ git checkout -

# Establish a trace 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]

# Select a commit to merge 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]

6, Label

# List all tag s
$ git tag

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

# Create a new tag and specify a 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 tag s
$ git push [remote] --tags

# Create a new branch to 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 files that change each time a commit occurs
$ git log --stat

# Search submission history by keyword
$ git log -S [keyword]

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

# Display all changes after a commit. The "submission 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]

# Display 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 submission times
$ git shortlog -sn

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

# Show differences between staging and workspace
$ git diff

# Display 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

# Show differences between submissions
$ git diff [first-branch]...[second-branch]

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

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

# Show files that have changed in a submission
$ git show --name-only [commit]

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

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

8, Remote synchronization

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

# Show all remote warehouses
$ git remote -v

# Display information for a remote warehouse
$ git remote show [remote]

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

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

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

# Forcibly push the current branch to the remote warehouse, even if there are conflicts
$ git push [remote] --force

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

9, Revocation

# Restore the specified files in the staging 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 staging area to be consistent with the last commit, but the workspace remains unchanged
$ git reset [file]

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

# Reset the pointer 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 at the same time, which is consistent with the specified commit
$ git reset --hard [commit]

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

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

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

10, Other

# Generate a compressed package for publishing
$ git archive

Git branch management policy

1, Main branch Master

First, the code base should have one and only one main branch. All official versions provided to users are published on this main branch.

img

The name of the Git main branch is called Master by default. It is created automatically. After the version library is initialized, it is developed in the main branch by default.

2, Develop ment Branch

The main branch is only used to distribute major versions, and daily development should be completed on another branch. We call the development branch development.

img

This branch can be used to generate the latest nightly version of the code. If you want to officially publish, you can "merge" the development branch on the Master branch.

Git command to create the Develop branch:

git checkout -b develop master

Command to publish the Develop branch to the Master branch:

#Switch to Master branch   git checkout master

#Merge the Develop branch   git merge --no-ff develop

Here is a little explanation of what the --no-ff parameter of the previous command means. By default, Git performs a fast forward merge, which directly points the Master branch to the Develop branch.

img

After the --no FF parameter is used, the normal merge will be performed and a new node will be generated on the Master branch. In order to ensure the clarity of version evolution, we hope to adopt this approach. For more explanations on consolidation, please refer to Benjamin Sandofsky's <Understanding the Git Workflow>.

img

3, Temporary branch

We talked about the two main branches of the version Library: Master and Develop. The former is used for official release, while the latter is used for daily development. As a matter of fact, the permanent branches only need these two articles, and there is no need for others.

However, in addition to the permanent branches, there are also some temporary branches to deal with version development for some specific purposes. There are three main types of temporary branches:

*feature branch

*Pre release branch

*Fix bug (fixbug) branch

These three branches are temporary and should be deleted after use, so that only Master and Develop are permanent branches of the code base.

4, Functional branch

Next, let's look at the three "temporary branches" one by one.

The first is the function branch, which is separated from the Develop branch to Develop a specific function. After the development is completed, it should be incorporated into development.

img

The name of the function branch can be named in the form of feature-*.

Create a functional branch:

git checkout -b feature-x develop

After development, merge the functional branch into the development branch:

git checkout develop

git merge --no-ff feature-x

Delete feature branch:

git branch -d feature-x

5, Pre release branch

The second is the pre release branch, which means that we may need to have a pre release version for testing before releasing the official version (that is, before merging into the Master branch).

The pre release branch is separated from the development branch. After the pre release, it must be merged into the development and Master branches. Its name can be in the form of release-*.

Create a pre release branch:

git checkout -b release-1.2 develop

After confirming that there is no problem, merge to the master branch:

git checkout master

git merge --no-ff release-1.2

#Make a label for the new node generated by merging   git tag -a 1.2

Merge to the develop ment branch:

git checkout develop

git merge --no-ff release-1.2

Finally, delete the pre publishing branch:

git branch -d release-1.2

6, Fix bug branch

The last one is to fix the bug branch. After the software is officially released, it is inevitable that there will be bugs. At this point, you need to create a branch to fix the bug.

The bug repair branch is separated from the Master branch. After the repair, merge into the Master and Develop branches. Its name can be in the form of fixbug-*.

img

Create a bug fix branch:

git checkout -b fixbug-0.1 master

After the repair, merge to the master branch:

git checkout master

git merge --no-ff fixbug-0.1

git tag -a 0.1.1

Merge to the develop ment branch:

git checkout develop

git merge --no-ff fixbug-0.1

Finally, delete the "bug fix branch":

git branch -d fixbug-0.1

Version fallback - undo file modification

{modify recovery for file}

After a file is modified in the workspace, you want to go back to before the modification (before git add)

  1. Of course, you can manually modify the file back in the workspace

  2. After modification, use the command git status to view

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

At this time, Git will tell you that git checkout -- file can discard the changes in the workspace:

$ git checkout -- readme.txt

Note:

  1. git checkout -- one of the file commands -- is very important. Without --, it becomes the "switch to another branch" command. We will encounter the git checkout command again in the later branch management.

  2. Command git checkout -- readme Txt means that readme The modification of txt files in the workspace is completely canceled. There are two cases:

One is readme Txt has not been put into the staging area since the modification. Now, if you undo the modification, you will return to the same state as the version library; One is readme Txt has been added to the staging area and modified. Now, undo the modification and return to the status after adding to the staging area. In short, this file is returned to the state of the last git commit or git add.

  1. The concepts of work area and staging area are not clearly visible in the Git Version Control Tutorial - git local repository

If the file is modified in the workspace, git add to the staging area (but before commit)

Use git status to check that the modification has only been added to the staging area but has not been submitted:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   readme.txt
#

Git also tells us that the command git reset HEAD file can undo the modification of the staging area and put it back in the workspace:

$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt

The git reset command can either rollback the version or the modification of the staging area to the workspace. When we use HEAD, it means the latest version.

Check git status again. Now the staging area is clean and the workspace has been modified.

Then discard the workspace changes

$ git checkout -- readme.txt

$ git status
# On branch master
nothing to commit (working directory clean)

Not only the file is modified, but also the commit is submitted from the staging area to the version Library - version fallback

Version fallback allows you to fallback to the previous version. However, this is conditional, that is, you have not pushed your local version library to the remote. Git is a distributed version control system.

Modify a file (such as readme.txt) several times during work and submit it to commit.

You can tell us the submitted history through the version control system command. In Git, we use the git log command to view:

$ git log
commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 15:11:49 2013 +0800

    append GPL

commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 14:53:12 2013 +0800

    add distributed

commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Mon Aug 19 17:51:55 2013 +0800

    wrote a readme file

Note:

  1. The git log command displays the latest to farthest submission logs. We can see three submissions. The latest one was append GPL, the last one was add distributed, and the earliest one was write a readme file.

  2. If you feel dazzled by too much output information, you can try adding the --pretty=online parameter:

$ git log --pretty=oneline
3628164fb26d48395383f8f31179f24e0882e1e0 append GPL
ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed
cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file
  1. You see a large string similar to 3628164 882e1e0 is a commit id (version number), which is different from SVN. Git's commit id is not an incremented number of 1, 2, 3... But a very large number calculated by SHA1, which is expressed in hexadecimal. Moreover, the commit id you see is certainly different from mine. Your own one shall prevail. Why should a commit id be represented by such a large number? Because Git is a distributed version control system, we will study how many people work in the same version library later. If everyone uses 1, 2, 3... As the version number, it will definitely conflict.

  2. Each time a new version is submitted, Git will actually automatically string them into a timeline. If you use visualization tools (such as GitX, github client, pycharm) to view Git history, you can see the timeline of submission history more clearly.

Now we want to put readme Txt back to the previous version

For example, what should be done in the "add distributed" version? First, Git must know which version the current version is. In Git, HEAD is used to represent the current version, that is, the latest submission 3628164 882e1e0 (note that my submission ID is certainly different from yours). The previous version was HEAD^, and the previous version was HEAD^^. Of course, it is easier to write 100 ^ in the previous 100 versions, so it is written as HEAD~100.

Now, to rollback the current version of "append GPL" to the previous version of "add distributed", you can use the git reset command:

$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed

At this time, readme Txt becomes the version add distributed

Let's use git log to check the status of the current version Library:

$ git log
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 14:53:12 2013 +0800

    add distributed

commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Mon Aug 19 17:51:55 2013 +0800

    wrote a readme file

The latest version of the append GPL can no longer be seen!

After restoring the file, what if we want to go back to the modified file? (the command line window has not been closed)

{this is git reset --hard. After that, he went back on his word and wanted to return to the modified state}

As long as the command line window above has not been closed, you can look up and find that the commit id of the append GPL is 3628164, Then you can specify to return to a future version:

$ git reset --hard 3628164
HEAD is now at 3628164 append GPL

There is no need to write the version number completely. The first few digits are OK. Git will automatically find them.

Git version rollback is very fast, because git has a HEAD pointer to the current version internally. When you rollback the version, GIT only points the HEAD from to the append GPL:

git-head

Change to point to add distributed:

git-head-move

Then I updated the files in the workspace by the way. Therefore, you can locate the current version according to the version number you want the HEAD to point to.

After restoring the file, what if we want to go back to the modified file? (the command line window has long been closed)

{this is git reset --hard. After that, he went back on his word and wanted to return to the modified state}

What if you want to restore to the new version? What if the commit id of the new version cannot be found? When you use $git reset --hard HEAD^ to rollback to the add distributed version, and then want to restore to the append GPL, you must find the commit id of the append GPL.

Git provides a command git reflog to record every command:[ Git advanced tutorial : git log and git reflog]

$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed
cb926e7 HEAD@{3}: commit (initial): wrote a readme file

The second line shows that the commit id of the append GPL is 3628164. Now, you can take the time machine to go back to the future.

This article uses mdnice Typesetting

Posted by mfos on Tue, 31 May 2022 10:41:14 +0530