As a developer, if you still don’t know git
or can’t use git
, then you should reflect on it. Go read the introductory introduction yourself. Today I just introduce some common commands that I use git
in my daily life and the commands that I think are good and can improve our office efficiency. The content may be a bit messy, but they are definitely classic commands. I jot down notes here, and I hope they can help those of you who come to appreciate me.
Before that, let’s introduce the three areas of git
Workspace (working directory)
Staging area (stage index)
Local history area (history)
Pass a A picture can help you understand the transformation between them concisely and easily.
Let’s start with the clone
command. Everyone who has used git
knows it. git colne
The command pulls the remote repository to the local. But when we want to pull to the specified folder, you may directly mkdir
. In fact, there is no need to do this. One command can do it git clone remote warehouse file name
, that’s it Simple.
We may encounter such a situation at work. Use git add .
to directly add all modified files in the workspace to the staging area. , but later found that there is a file that should not be added first. At this time, we can use the following command to return the file to the workspace.
git rm --cached <file>
There is such a situation. When you are developing, there is an online emergency bug
that needs to be fixed. At this time, the function under development is If you don't want to submit it before it's completed, you can use git stash
to store all the files in the workspace. At this time, you can safely cut the branch and fix the bug
. After the repair is completed, execute git stash pop
to take out the previously stored ones. Of course, there are also some other related commands such as: git stash list
View the stored records,git stash drop
Discard the stored records.
Maybe during development we need to tag git tag tagName
, and push the corresponding tag to the remote warehouse. In this case, you can use the following command push.
git push --tags tagName
After you commit
, you find that a file was not added to the last commit
, or some files were modified. . At this time, you do not want to add new commit
information, you just want to add it to the last commit
. At this time, you can use
git commit --amend <file>
to add the files in the temporary storage area, and you can also modify the commit
information at this time.
reset
can also achieve the effect of the previous rm
. You can use the following command to replace the previous git rm -- cached <file>
Command
git reset HEAD <file>
But reset
is more versatile. Combined with soft
parameters, it can be rolled back to any commit
The node operates
git reset --soft index
After executing this command, it returns to index
. The work area remains unchanged and the temporary storage area returns to the current index
. There is also a hard
parameter.
git reset --hard index
can be said to be opposite to soft
. Its effect lies in the difference between the work area and the temporary storage area. It will clear these two areas.
For rebase
means redirection. If there is a difference in information between your current branch and the remote branch commit
, you will be reminded. You cannot push
at this time. You must first pull the remote commit
information to the local one before you can submit it. In this case, you can use the rebase
command. The following is currently in the develop
branch
At this time, the rebase
command should be executed first
git fetch git rebase origin/master
After execution , and finally push
to the remote master
git push origin master
The final situation of each branch is the effect shown in the picture above. If you find the command difficult to remember, you can also use one command to achieve the above effect.
git pull --rebase origin master
This is a simple application of rebase
, and it is also a common command. The following introduces an optional parameter --onto
of rebase
.
Usage scenarios: During the development process, we will create different branches to develop different functions. When you create a new branch on branch A
B
When developing functions and submitting some commit
, you find that there are wrong commit
on the original A
branch. If you want When rebase
to master
, this wrong commit
cannot be attached. At this time, it’s time to --onto
show off your magical powers.
当前处在B
分支,要得到上面的结果,只需执行如下命令
git rebase --onto master <b的commit hash code> B
这个不仅可以针对不同的分支,也能作用于同一个分支上。所以针对上面的情况可以只对分支B
进行操作,等价命令如下:
git rebase --onto <a的commit hash code> <b的commit hash code> B
当我们要修改commit
信息的名称时,如果要修改的commit
处在第一个时,可以使用
git commit --amend
如果不是第一个时,我们就要使用到rebase
的--interactive
可选参数了,可以简写为-i
。
参数后面的commit hash code
为需要修改的commit
的前一个。执行之后就会出现如下类似的信息:
pick 137cf0a First coommit pick 163dc38 Second commit # Rebase f9aee6e..163dc38 onto f9aee6e (2 command(s)) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out
根据提示我们可以有6
个可选择的操作。相信提示已经说的很明显了,对于我们这种要修改First coommit
的情况,需要使用r
。
r 137cf0a First commit pick 163dc38 Second commit
执行之后会跳到修该First coomit
的界面,进行修改即可。
First commit # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: Thu Jan 26 23:07:10 2017 +0800 # # rebase in progress; onto f9aee6e # You are currently editing a commit while rebasing branch 'master' on 'f9aee6e'. # # Changes to be committed: # new file: file1
至于其他的操作项,有兴趣的可以自己去尝试一下。例如s
操作就可以用来合并commit
。
相信branch
都很熟悉,我这里要说的是他的另一种可能会用到的情况。场景是这样的:如果在你进行创建新的分支时,并不想从当前的commit
信息节点进行创建分支。
要实现如上效果只需在创建分支时在后面再添加额外的参数,该参数就是你所需调到的commit
节点的hash code
git branch new_branch <commit hash code>
这里提一下push
的--set-upstream
,它的效果是设置上游分支,当我们将远程不存在的本地分支推送到远程时,如果不在推送的分支上,我们一般会使用如下命令进行推送。
git checkout push_branch git push origin push_branch
下面是简洁的方法,使用该参数无需切换分支,可以直接使用如下命令进行推送。
git push --set-upstream origin push_branch
这个命令的场景是:当你所在的分支没用,你要删除它,但其中的一个commit
你还是想推送到远程master
上。
将分支切换到master
,执行以下命令:
git cherry-pick <b的 commit hash code>
我们所熟知的是使用merge
来进行分支的合并,每次使用merge
时都会自动将副分支合并成一个commit
进行推送到主分支上,那么如果我不想它自动推送到主分支上时(可能我还需要进行修改),这时就可以使用--squash
操作
git merge --squash dev_branch
执行完以上命令后,我们就可以在暂存区看到一个还未提交的文件状态。
当我们切分支太频繁了之后,可能会忘了一些分支是从哪个分支切过来的,此时可以使用如下命令查看:
git reflog
894a16d HEAD@{0}: commit: commit another todo 6876e5b HEAD@{1}: checkout: moving from solve_world_hunger to kill_the_batman 324336a HEAD@{2}: commit: commit todo 6876e5b HEAD@{3}: checkout: moving from blowup_sun_for_ransom to solve_world_hunger 6876e5b HEAD@{4}: checkout: moving from kill_the_batman to blowup_sun_for_ransom 6876e5b HEAD@{5}: checkout: moving from cure_common_cold to kill_the_batman 6876e5b HEAD@{6}: commit (initial): initial commit
这样我们就可以看到所用的操作历史了。这样如果我们使用git reset
命令不小心删除了需要的东西。可以通过此来查找到删除操作的hash code
,之后就可以通过如下命令进行恢复。
git checkout <hash code>
目前想到的就这些了,希望能有所帮助
个人博客:http://www.php.cn/
作为一个开发者,如果现在还不知道git
或者还不会使用git
,那么你应该好好的反省。自己去好好看一遍的入门介绍吧。今天只是对自己在日常中使用git
的一些常用命令的介绍与自己认为不错且能提高我们办公效率的命令。内容可能会有点杂乱,但绝对都是经典的命令,在此记下笔记,也希望能帮助来赏脸关顾的你们。
在这之前,来介绍一下git
的三个区域
工作区(working directory)
暂存区(stage index)
本地历史区(history)
通过一张图就能简洁易懂的明白它们之间的转化。
Let’s start with the clone
command. Anyone who has used git
knows it. git colne
The command pulls the remote repository to the local. But when we want to pull to the specified folder, you may directly mkdir
. In fact, there is no need to do this. One command can do it git clone remote warehouse file name
, that’s it Simple.
We may encounter such a situation at work. Use git add .
to directly add all modified files in the workspace to the staging area. , but later found that there is a file that should not be added first. At this time, we can use the following command to return the file to the workspace.
git rm --cached <file>
There is such a situation. When you are developing, there is an online emergency bug
that needs to be fixed. At this time, the function under development is If you don't want to submit it before it's completed, you can use git stash
to store all the files in the workspace. At this time, you can safely cut the branch and fix the bug
. After the repair is completed, execute git stash pop
to take out the previously stored ones. Of course, there are also some other related commands such as: git stash list
View the stored records,git stash drop
Discard the stored records.
Maybe during development we need to tag git tag tagName
, and push the corresponding tag to the remote warehouse. In this case, you can use the following command push.
git push --tags tagName
After you commit
, you find that a file was not added to the last commit
, or some files were modified. . At this time, you do not want to add new commit
information, you just want to add it to the last commit
. At this time, you can use
git commit --amend <file>
to add the files in the temporary storage area, and you can also modify the commit
information at this time.
reset
can also achieve the effect of the previous rm
. You can use the following command to replace the previous git rm -- cached <file>
Command
git reset HEAD <file>
But reset
is more versatile. Combined with soft
parameters, it can be rolled back to any commit
The node operates
git reset --soft index
After executing this command, it returns to index
. The work area remains unchanged and the temporary storage area returns to the current index
. There is also a hard
parameter.
git reset --hard index
can be said to be opposite to soft
. Its effect lies in the difference between the work area and the temporary storage area. It will clear these two areas.
For rebase
means redirection. If there is a difference in information between your current branch and the remote branch commit
, you will be reminded. You cannot push
at this time. You must first pull the remote commit
information to the local one before you can submit it. In this case, you can use the rebase
command. The following is currently in the develop
branch
At this time, the rebase
command should be executed first
git fetch git rebase origin/master
After execution , and finally push
to the remote master
git push origin master
The final situation of each branch is the effect shown in the picture above. If you find the command difficult to remember, you can also use one command to achieve the above effect.
git pull --rebase origin master
This is a simple application of rebase
, and it is also a common command. The following introduces an optional parameter --onto
of rebase
.
Usage scenarios: During the development process, we will create different branches to develop different functions. When you create a new branch on branch A
B
When developing functions and submitting some commit
, you find that there are wrong commit
on the original A
branch. If you want When rebase
to master
, this wrong commit
cannot be attached. At this time, it’s time to --onto
show off your magical powers.
is currently in the B
branch. To get the above results, just execute the following command
git rebase --onto master <b的commit hash code> B
This can not only target different Branches can also act on the same branch. Therefore, for the above situation, we can only operate on branch B
. The equivalent command is as follows:
git rebase --onto <a的commit hash code> <b的commit hash code> B
When we want to modify commit
As the name of the information, if the commit
to be modified is at the first time, you can use
git commit --amend
. If it is not the first time, we have to use rebase
’s --interactive
is an optional parameter and can be abbreviated as -i
. The
after the <pre class="brush:php;toolbar:false">git rebase -i <commit hash code></pre>
parameter is the previous commit
that needs to be modified. After execution, a message similar to the following will appear:
pick 137cf0a First coommit pick 163dc38 Second commit # Rebase f9aee6e..163dc38 onto f9aee6e (2 command(s)) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out
根据提示我们可以有6
个可选择的操作。相信提示已经说的很明显了,对于我们这种要修改First coommit
的情况,需要使用r
。
r 137cf0a First commit pick 163dc38 Second commit
执行之后会跳到修该First coomit
的界面,进行修改即可。
First commit # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: Thu Jan 26 23:07:10 2017 +0800 # # rebase in progress; onto f9aee6e # You are currently editing a commit while rebasing branch 'master' on 'f9aee6e'. # # Changes to be committed: # new file: file1
至于其他的操作项,有兴趣的可以自己去尝试一下。例如s
操作就可以用来合并commit
。
相信branch
都很熟悉,我这里要说的是他的另一种可能会用到的情况。场景是这样的:如果在你进行创建新的分支时,并不想从当前的commit
信息节点进行创建分支。
要实现如上效果只需在创建分支时在后面再添加额外的参数,该参数就是你所需调到的commit
节点的hash code
git branch new_branch <commit hash code>
这里提一下push
的--set-upstream
,它的效果是设置上游分支,当我们将远程不存在的本地分支推送到远程时,如果不在推送的分支上,我们一般会使用如下命令进行推送。
git checkout push_branch git push origin push_branch
下面是简洁的方法,使用该参数无需切换分支,可以直接使用如下命令进行推送。
git push --set-upstream origin push_branch
这个命令的场景是:当你所在的分支没用,你要删除它,但其中的一个commit
你还是想推送到远程master
上。
将分支切换到master
,执行以下命令:
git cherry-pick <b的 commit hash code>
我们所熟知的是使用merge
来进行分支的合并,每次使用merge
时都会自动将副分支合并成一个commit
进行推送到主分支上,那么如果我不想它自动推送到主分支上时(可能我还需要进行修改),这时就可以使用--squash
操作
git merge --squash dev_branch
执行完以上命令后,我们就可以在暂存区看到一个还未提交的文件状态。
当我们切分支太频繁了之后,可能会忘了一些分支是从哪个分支切过来的,此时可以使用如下命令查看:
git reflog
894a16d HEAD@{0}: commit: commit another todo 6876e5b HEAD@{1}: checkout: moving from solve_world_hunger to kill_the_batman 324336a HEAD@{2}: commit: commit todo 6876e5b HEAD@{3}: checkout: moving from blowup_sun_for_ransom to solve_world_hunger 6876e5b HEAD@{4}: checkout: moving from kill_the_batman to blowup_sun_for_ransom 6876e5b HEAD@{5}: checkout: moving from cure_common_cold to kill_the_batman 6876e5b HEAD@{6}: commit (initial): initial commit
这样我们就可以看到所用的操作历史了。这样如果我们使用git reset
命令不小心删除了需要的东西。可以通过此来查找到删除操作的hash code
,之后就可以通过如下命令进行恢复。
git checkout <hash code>
目前想到的就这些了,希望能有所帮助
更多git使用杂记 相关文章请关注PHP中文网!