Git commands and methods

The translation of several specific nouns is as follows:

-Jenny: Well, I’m working in a Workspace.
Index/Stage: temporary storage area
A Repository is a Repository.
Remote: Remote repository

Git branch -- set-uppage-to =origin Git config --system --unset credential.helper storeCopy the code

Create a new code base

$Git init [url] $Git clone $Git init [url]Copy the code

Second, the configuration

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

$Git config [--global] $Git config [--global] $Git config [--global  "[name]" $ git config [--global] user.email "[email address]"Copy the code

Add/delete files

$git add [file1] [file2]... $git add [dir] $git add. $git add. $git add -p $git rm [file1] [file2] $git mv [file-original] [file-renamed]Copy the code

4. Code submission

$git commit [file1] [file2] $git commit [file1] [file2] $git commit -v $git commit -v $git commit -v $git commit -- amend-m [message] # amend the last commit, $git commit --amend [file1] [file2]...Copy the code

Five, the branch

$git branch -r $git branch -r $git branch [branch-name] $git branch [branch] [commit] # create a new branch $git branch --track [branch] [remote-branch] $git checkout [branch-name] $git checkout - $git branch --set-upstream [branch] [remote-branch] $git merge [branch] $git cherry-pick [commit] $git branch -d [branch-name] # $git push origin --delete [branch-name] $ git branch -dr [remote/branch]Copy the code

Six, labels,

$git tag [tag] $git tag [commit] # Delete local tag $git tag $git show [tag] # $git push [remote] [tag] $git checkout -b [branch] [tag]Copy the code

7. Check information

$git log -- $git log -- $git log -- $git log -- $git log $git log -s [keyword] # $git log [tag] HEAD --pretty=format:%s # $git log [tag] HEAD --grep feature # --follow [file] $git whatchanged [file] # diff $git log -p [file --pretty --oneline # display all submitted users $git diff $git diff $git diff $git diff $git diff $git diff [first-branch] $git diff [first-branch] $git diff [first-branch] $git diff --shortstat "@{0 day ago}" $git show [commit] # $git show --name-only [commit] $git show [commit]:[filename] # $git reflogCopy the code

8. Remote synchronization

$git remote show [remote] $git remote show [remote] $git remote add [shortname] [url] $git pull [remote] [branch] $git push [remote] [branch] $git push [remote] --all $git push [remote] --allCopy the code

Nine, cancellation

$git checkout [commit] [file] $git checkout [file $git reset [file] $git reset [commit] # reset the HEAD of the current branch to commit. $git reset --hard [commit] # $git reset --keep [commit] # create a new commit to undo the specified commit $git Revert [commit] # Remove the uncommitted changes temporarily and move on to $git Stash $git Stash pop laterCopy the code

10 and other

$git archive = $git archiveCopy the code

Git branch management policy

A, Master branch

First, the code base should have one and only one main branch. All official releases for user use are published on this main branch.

The name of the Master Git branch, which is called Master by default. It is built automatically, and once the repository is initialized, development is done in the main branch by default.

Second, Develop branch

The main branch should only be used to distribute major releases, and daily development should be done on the other branch. We call the development branch, Develop.

This branch can be used to generate the latest overnight version of the code (NIGHTLY). If you want to formally publish, merge the Develop branch on the Master branch.

Git creates the Develop branch

git checkout -b develop masterCopy the code

Publish the Develop branch to Master:

Git merge --no-ff DevelopCopy the code

Here’s a little explanation of what the –no-ff argument to the previous command means. By default, Git performs a “fast-farward merge” that points the Master branch directly to the Develop branch.

With the –no-ff parameter, a normal merge is performed to create a new node on the Master branch. In order to keep version evolution clear, we want to do this. For more information on merging, see Benjamin Sandofsky’s Understanding the Git Workflow.

Temporary branches

The two main branches of the repository were described earlier: Master and Develop. The former is used for official release and the latter for daily development. In fact, the permanent branch only needs these two and nothing else.

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

Feature branching
The pre-release branch
The fixbug branch

All three branches are temporary and should be removed once you’re done with them so that the permanent branches of the code base are always just Master and Develop.

4. Functional branches

Next, look at each of the three “temporary branches.”

The first is a function branch, which is developed from the Develop branch to Develop a specific function. Once the development is complete, it is incorporated into Develop.

The name of a feature branch can be named as feature-*.

Create a functional branch:

git checkout -b feature-x developCopy the code

After development is complete, merge the functional branches into the Develop branch:

Git checkout develop git merge --no-ff feature-xCopy the code

Delete feature branch:

git branch -d feature-xCopy the code

Fifth, the pre-release branch

The second is the pre-release branch, which means we may need to have a pre-release version to test before we release the official version (i.e. before merging into the Master branch).

The pre-release branch is separated from the Develop branch and must be merged into the Develop and Master branches after pre-release. It can be named release- star.

Create a pre-published branch:

Git checkout -b release-1.2 developCopy the code

If there is no problem, merge into the master branch:

Git checkout master git merge --no-ff release-1.2Copy the code

Merge into the Develop branch:

Git Checkout develop Git merge --no-ff release-1.2Copy the code

Finally, delete the pre-published branch:

Git branch - d release 1.2Copy the code

Fix bug branch

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

The branch is separated from the Master branch. After the patch is complete, merge into the Master and Develop branches. It can be named in the form fixbug-*.

Create a bug fixing branch:

Git checkout -b fixbug-0.1 masterCopy the code

After the patch is complete, merge to the master branch:

Git checkout master git merge --no-ff fixbug-0.1 git tag -a 0.1.1Copy the code

Merge into the Develop branch:

Git Checkout develop Git merge --no-ff fixbug-0.1Copy the code

Finally, delete the “fixbug branch” : git branch -d fixbug-0.1

Version rollback – Undoes file modifications

{Restore for file modification}

After modifying a file in your workspace, you want to go back to the previous modification (before git add)

Of course, you can modify the file back in the workspace manually
After the modification, run the git status command to view it

$ 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")
Copy the code

Git will tell you that Git checkout — file can discard workspace changes:

$ git checkout -- readme.txt
Copy the code

Note:

Git checkout — file git checkout — file git checkout — file git checkout — file
Git checkout — readme. TXT git checkout — readme. TXT git checkout — readme. TXT git checkout — readme. TXT git checkout — readme. TXT git checkout — readme. TXT

One is that the readme. TXT file has not been placed in the staging area since the modification. Now, undoing the modification will return it to the same state as the version library. One is that readme.txt has been added to the staging area and then changed, and now undoing the changes will return to the state after it was added to the staging area. Return the file to the state it was at the last Git commit or git add.

If you don’t know the concept of workspace or staging area, see Git Local Repository in this article

Git add to staging if you modify files in your workspace (but before committing)

Git status is only added to the staging area, not committed yet:

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

Git reset HEAD file unstage the changes in the staging area and put them back into the workspace:

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

The git reset command can roll back both the version and the changes made in the staging area to the workspace. When we use HEAD, we mean the latest version.

Git status: Now the staging area is clean and the workspace has changed.

The workspace changes are then discarded

$ git checkout -- readme.txt
 
$ git status
Copy the code

On branch master

nothing to commit (working directory clean)

Not only did the file change, but also commit from staging to repository – version rollback

Version rollback You can roll back to the previous version. This is conditional, however, on the fact that you haven’t pushed your local repository to remote locations. Git is a distributed version control system.

Make several changes to a file (such as readme.txt) at work and commit.

You can tell the commit history by using the version control system command. In Git, you can view the commit history with the Git log command:

$ git log
commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <[email protected]>
Date:   Tue Aug 20 15:11:49 2013 +0800
 
    append GPL
 
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <[email protected]>
Date:   Tue Aug 20 14:53:12 2013 +0800
 
    add distributed
 
commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <[email protected]>
Date:   Mon Aug 19 17:51:55 2013 +0800
 
    wrote a readme file
Copy the code

Note:

The git log command displays the latest and most recent commit logs. You can see three commits: append GPL, Add Distributed, and Wrote a Readme file.
Pretty =oneline: pretty=oneline:

$ git log --pretty=oneline
3628164fb26d48395383f8f31179f24e0882e1e0 append GPL
ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed
cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file
Copy the code

You see a bunch of things like 3628164… 882e1e0 has a commit id (version number). Unlike SVN, Git has a commit id that is not 1,2,3… Instead, it’s a very large number calculated by SHA1 in hexadecimal notation, and the COMMIT ID you see is definitely different from mine, whichever is yours. Why is the COMMIT ID represented by such a large string of numbers? Because Git is a distributed version control system, we will have to study how many people work in the same version library. If everyone uses 1,2,3… As a version number, that’s definitely a conflict.
Every time you commit a new version, Git actually strings them together into an automatic timeline. If you look at Git history using visual tools such as GitX, github’s client, and PyCharm, you can see the timeline of the commit history more clearly.

Now we want to roll back readme.txt to the previous version

For example, what about the Add Distributed version? First, Git must know what the current version is. In Git, the current version is represented by HEAD, which is the latest commit 3628164… 882e1e0 (note that my submission ID is not the same as yours), the previous version is HEAD^, and the previous version is HEAD^^. Of course, it is easier to write 100 ^ in the previous 100 versions, so I write HEAD~100.

To rewind the current version of append GPL to the previous version of Add Distributed, use git reset:

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

The readme.txt content is now version Add Distributed

Git log:

$ git log
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <[email protected]>
Date:   Tue Aug 20 14:53:12 2013 +0800
 
    add distributed
 
commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <[email protected]>
Date:   Mon Aug 19 17:51:55 2013 +0800
 
    wrote a readme file
Copy the code

The latest version of the Append GPL is no longer available!

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

Git reset –hard

As long as the command line window above is not closed, you can find the commit ID of the append GPL is 3628164… , so you can specify a future version:

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

It is not necessary to write the full version number, just the first few digits will do, Git will automatically find it.

Git version rollback is very fast because Git has an internal HEAD pointer to the current version. When you roll back Git, you just change the HEAD from point to append GPL:

Point to Add Distributed instead:

I also updated the files in the workspace. So whatever version number you want HEAD to point to, that’s where you place the current version.

After restoring the file, what if we want to go back to the modified file? (The command line window is already closed.)

Git reset –hard

What if you want to restore to the new version? What if the new version of the COMMIT ID cannot be found? If you want to restore to the Append GPL with $git reset –hard HEAD^, you must find the COMMIT ID of the Append GPL.

Git reflog: Git reflog: Git reflog: Git reflog: 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
Copy the code

The second line shows that the COMMIT ID of the Append GPL is 3628164, and you can now travel back to the future in a time machine.

Git commands and methods

Git commands and methods

Create a new code base

Second, the configuration

Add/delete files

4. Code submission

Five, the branch

Six, labels,

7. Check information

8. Remote synchronization

Nine, cancellation

10 and other

Git branch management policy

A, Master branch

Second, Develop branch

Temporary branches

4. Functional branches

Fifth, the pre-release branch

Fix bug branch

Version rollback – Undoes file modifications

After modifying a file in your workspace, you want to go back to the previous modification (before git add)

Note:

Git add to staging if you modify files in your workspace (but before committing)

On branch master

Not only did the file change, but also commit from staging to repository – version rollback

Note:

Now we want to roll back readme.txt to the previous version

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

After restoring the file, what if we want to go back to the modified file? (The command line window is already closed.)

Related Posts

Inline functions

How much do you need to understand the memory reclamation mechanism

OkHttp network framework source code analysis