作为一个开发者,如果现在还不知道git
或者还不会使用git
,那么你应该好好的反省。自己去好好看一遍的入门介绍吧。今天只是对自己在日常中使用git
的一些常用命令的介绍与自己认为不错且能提高我们办公效率的命令。内容可能会有点杂乱,但绝对都是经典的命令,在此记下笔记,也希望能帮助来赏脸关顾的你们。
在这之前,来介绍一下git
的三个区域
工作区(working directory)
暂存区(stage index)
本地历史区(history)
通过一张图就能简洁易懂的明白它们之间的转化。
先从clone
命令来介绍,使用过git
的都知道它。git colne
命令拉取远程仓库到本地。但当我们要拉取到指定的文件夹下时,你可能会直接mkdir
,其实无需如此,一条命令就能搞定git clone 远程仓库 文件名
,就是如此简单。
我们在工作中可能会遇到这么一种情况,使用git add .
直接将工作区的所有修改的文件加入到暂存区了,但是后面发现有一个文件先不要加进去,此时我们就可以使用如下命令就可以将该文件退回到工作区中。
git rm --cached <file>
有这么一种情况,当你正在开发中时,有一个线上的紧急bug
需要修复,此时开发中的功能又没有完成你不想提交,此时你可以使用git stash
将工作区的文件都存放起来。这时你就可以放心的去切分支修复bug
,修复完之后执行git stash pop
可以将先前存放的取出,当然也有一些其他的相关命令例如:git stash list
查看存放的记录,git stash drop
丢弃存放的记录。
可能在开发中我们要打标签git tag tagName
,并且要将相应的标签推送到远程仓库中,此时可以使用如下命令进行推送。
git push --tags tagName
当你commit
以后,发现有一个文件没有加进上次的commit
中,或者又修改了一些文件。此时你并不想增加新的commit
信息,只是想将其加入到上次的commit
中。这时你就可以使用
git commit --amend <file>
将暂存区的文件加入其中,并且你也可以修改此时的commit
信息。
reset
也能实现前面的rm
的效果,可以使用如下命令来替代前面的git rm --cached <file>
命令
git reset HEAD <file>
但reset
用途更广,结合soft
参数可以回撤到任意的commit
节点进行操作
git reset --soft index
执行该命令之后,就回到index
处,工作区不变、暂存区回到当时的index
处。另外还有一个hard
参数。
git reset --hard index
与soft
可以说对立,它的效果就在于工作区与暂存区的不同,它会清空这两个区。
对于rebase
是重定向的意思,如果你当前的分支与远程的分支commit
信息存在差异时,会提醒你此时不能进行push
,必须先将远程的commit
信息拉去到本地来,才能进行提交。对于这种情况就可以使用rebase
命令了。如下当前处在develop
分支
此时应该先执行rebase
命令
git fetch git rebase origin/master
执行完之后,最后再push
到远程master
git push origin master
最终各个分支的情况就是上图的效果了。如果觉得命令多难记,这里也可用一条命令来完成上面的效果
git pull --rebase origin master
这是rebase
的简单运用,也是常见的命令了。下面介绍rebase
的一个可选参数--onto
。
使用场景:开发过程中我们都会创建不同的分支进行开发不同的功能,当你在分支A
上创建了新分支B
进行开发功能并且也提交了一些commit
时,此时你发现原来A
分支上有错误的commit
,如果要rebase
到master
上时,不能将这个错误的commit
也附带上。这个时候就该--onto
大显神通了。
当前处在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
。
git rebase -i <commit hash code>
参数后面的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>
目前想到的就这些了,希望能有所帮助
个人博客://m.sbmmt.com/
作为一个开发者,如果现在还不知道git
或者还不会使用git
,那么你应该好好的反省。自己去好好看一遍的入门介绍吧。今天只是对自己在日常中使用git
的一些常用命令的介绍与自己认为不错且能提高我们办公效率的命令。内容可能会有点杂乱,但绝对都是经典的命令,在此记下笔记,也希望能帮助来赏脸关顾的你们。
在这之前,来介绍一下git
的三个区域
工作区(working directory)
暂存区(stage index)
本地历史区(history)
通过一张图就能简洁易懂的明白它们之间的转化。
先从clone
命令来介绍,使用过git
的都知道它。git colne
命令拉取远程仓库到本地。但当我们要拉取到指定的文件夹下时,你可能会直接mkdir
,其实无需如此,一条命令就能搞定git clone 远程仓库 文件名
,就是如此简单。
我们在工作中可能会遇到这么一种情况,使用git add .
直接将工作区的所有修改的文件加入到暂存区了,但是后面发现有一个文件先不要加进去,此时我们就可以使用如下命令就可以将该文件退回到工作区中。
git rm --cached <file>
有这么一种情况,当你正在开发中时,有一个线上的紧急bug
需要修复,此时开发中的功能又没有完成你不想提交,此时你可以使用git stash
将工作区的文件都存放起来。这时你就可以放心的去切分支修复bug
,修复完之后执行git stash pop
可以将先前存放的取出,当然也有一些其他的相关命令例如:git stash list
查看存放的记录,git stash drop
丢弃存放的记录。
可能在开发中我们要打标签git tag tagName
,并且要将相应的标签推送到远程仓库中,此时可以使用如下命令进行推送。
git push --tags tagName
当你commit
以后,发现有一个文件没有加进上次的commit
中,或者又修改了一些文件。此时你并不想增加新的commit
信息,只是想将其加入到上次的commit
中。这时你就可以使用
git commit --amend <file>
将暂存区的文件加入其中,并且你也可以修改此时的commit
信息。
reset
也能实现前面的rm
的效果,可以使用如下命令来替代前面的git rm --cached <file>
命令
git reset HEAD <file>
但reset
用途更广,结合soft
参数可以回撤到任意的commit
节点进行操作
git reset --soft index
执行该命令之后,就回到index
处,工作区不变、暂存区回到当时的index
处。另外还有一个hard
参数。
git reset --hard index
与soft
可以说对立,它的效果就在于工作区与暂存区的不同,它会清空这两个区。
对于rebase
是重定向的意思,如果你当前的分支与远程的分支commit
信息存在差异时,会提醒你此时不能进行push
,必须先将远程的commit
信息拉去到本地来,才能进行提交。对于这种情况就可以使用rebase
命令了。如下当前处在develop
分支
此时应该先执行rebase
命令
git fetch git rebase origin/master
执行完之后,最后再push
到远程master
git push origin master
最终各个分支的情况就是上图的效果了。如果觉得命令多难记,这里也可用一条命令来完成上面的效果
git pull --rebase origin master
这是rebase
的简单运用,也是常见的命令了。下面介绍rebase
的一个可选参数--onto
。
使用场景:开发过程中我们都会创建不同的分支进行开发不同的功能,当你在分支A
上创建了新分支B
进行开发功能并且也提交了一些commit
时,此时你发现原来A
分支上有错误的commit
,如果要rebase
到master
上时,不能将这个错误的commit
也附带上。这个时候就该--onto
大显神通了。
当前处在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
。
git rebase -i <commit hash code>
参数后面的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>
目前想到的就这些了,希望能有所帮助
更多git使用杂记 相关文章请关注PHP中文网!