水下功夫做透,水上才能顺风顺水。

git 命令

 

 

 

1. git撤销命令集

工作目录 <-git restore(放弃修改)修改状态 <- git restore --staged (从暂存区中剔除) 暂存区 <-git reset --soft HEAD^(HEAD指针后退一半,最新的commit解除) 本地仓库 远程仓库

git reset --soft HEAD^ 从本地仓库到暂存区
git reset [--mixed] HEAD^ 从本地仓库到修改状态
git reset --hard HEAD^ 从本地仓库到工作目录,恢复到了上一次的commit状态

git reset --hard HEAD~N 回退N个commit版本
git reset --hard <commit_id> 指定版本回退
git reset --hard origin/master 直接回退到远程最新版本

修改已commit的注释:
git commit --amend
此时会进入默认vim编辑器,修改注释完毕后保存就好了。

已推送,回退到上个版本示例
git reset --hard HEAD^
git push -f #强制推送到远程仓库
warning 警告
在团队合作的共同操作一个仓库的时候, git reset 命令一定要慎重使用,
在使用的时候一定要再三确认其他同学的代码是否会被重置操作而导致代码丢失,
导致一些提交记录的丢失,这些都是不可逆的,一定要慎重。


git reset和git revert比较(https://www.modb.pro/db/137424)
都是属于重新恢复工作区以及远程提交的方式,但这两种操作有着截然不同的结果:
git reset(重置到某一次commit)
是将之前的提交记录全部抹去,将HEAD指向自己重置的提交记录,对应之后的提交记录都不复存在;

warning 警告
在团队合作的共同操作一个仓库的时候, git reset 命令一定要慎重使用,在使用的时候一定要再三确认其他同学的代码是否会被重置操作而导致代码丢失,导致一些提交记录的丢失,这些都是不可逆的,一定要慎重。

 

git revert(重做某一次commit)
操作是将选择的某一次提交记录重做,若之后又有提交,提交记录还存在,只是将指定提交的代码给清除掉。
对于重做的某个 commit 提交的内容都不存在了。

 

git rebase(变基,了解。一般不用,用merge替换) https://blog.csdn.net/weixin_42310154/article/details/119004977

  • feature:待变基分支、当前分支
  • master:基分支、目标分支

       git checkout feature

       git rebase master

 

通俗解释:rebase,变基,可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支,feature的基底是B。而master在B之后有新的提交,就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交先暂存下来,然后删掉原来这些提交,再找到master的最新提交位置,把存下来的提交再接上去(接上去是逐个和新基底处理冲突的过程),如此feature分支的基底就相当于变成了M而不是原来的B了。(注意,如果master上在B以后没有新提交,那么就还是用原来的B作为基,rebase操作相当于无效,此时和git merge就基本没区别了,差异只在于git merge会多一条记录Merge操作的提交记录)

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原文链接:https://blog.csdn.net/weixin_42310154/article/details/119004977

2.git clone
git clone就是将其他仓库克隆到本地,本地无需git init,完成后本地目录下自动会有一个.git的隐藏文件夹。
用法1:git clone <版本库的url>
这样就会在本地生成一个目录,该目录与远程仓库同名。
如果本地目录不想与远程仓库同名,将目录名作为git clone命令的第二个参数:
用法2:git clone <版本库的网址> <本地目录名>


3.git pull

git pull是拉取远程分支更新到本地仓库的操作。事实上,git pull是相当于从远程仓库获取最新版本,然后再与本地分支merge(合并)。
即:git pull = git fetch + git merge
注:git fetch不会进行合并,执行后需要手动执行git merge合并,而git pull拉取远程分之后直接与本地分支进行合并。
用法:git pull origin <远程分支名>:<本地分支名>

举例:将远程主机origin的master分支拉取过来,与本地的branchtest分支合并
git pull origin master:branchtest
如果将冒号和后面的branchtest去掉,则表示将远程origin仓库的master分支拉取下来与本地当前分支合并。
等价于以下两条命令
git fetch origin master:brantest
git merge brantest
相比起来,git fetch更安全也更符合实际要求,因为可以在merge前,我们可以查看更新情况,根据实际情况再决定是否合并


4.git fetch
git fetch 拉取远程分支代码到本地仓库分支
git fetch origin <远程分支名>:<本地分支名>
git fetch更新本地仓库的两种用法
git fetch origin master:temp #从远程的origin仓库的master分支下载到本地并新建一个分支temp
git diff temp #比较master分支和temp分支的不同
git merge temp #合并temp分支到master分支
git branch -d temp #删除temp

git中的HEAD是一个指针,始终指向当前分支的最新commit提交。
HEAD 是当前分支的最新版本,HEAD~ 和 HEAD^ 都是指次新版本,也就是倒数第二个版本,
HEAD~~ 和 HEAD^^ 都是指次次新版本,也就是倒数第三个版本,以此类推。
其实 HEAD~ 和 HEAD^ 的作用是相同的,这两者的区别出现在重复使用或者加数字的情况。

加上参数0之后变成了 HEAD~0 或 HEAD^0,其实他们指向的节点没有改变,还是代表了 HEAD
加上参数1之后变成了 HEAD~1 或 HEAD^1,其实这就是他们本来的面貌,在参数1可以省略,代表HEAD~或HEAD^

HEAD~ 和 HEAD^后面都加大于1的数字
这时就会发现两者的不同了,比如我们把数字都定为2,
那么 HEAD~2 代表后退两步,每一步都后退到第一个父提交上,
而 HEAD^2 代表后退一步,这一步退到第二个父提交上,如果没有第二个父提交就会报出以下错误:

fatal: ambiguous argument ‘HEAD^2’: unknown revision or path not in the working tree.
Use ‘–’ to separate paths from revisions, like this:
‘git […] – […]’

5. git merge
–ff 快速合并,这个是默认的参数。如果合并过程出现冲突,Git会显示出冲突并等待手动解决
–ff-only 只有能快速合并的情况才合并。如果合并过程出现冲突,Git会自动abort此次merge
–squash 压缩合并。将待合并的分支的多次提交内容压缩成一个新的提交合并进来

posted @ 2024-02-03 07:49  北方寒士  阅读(9)  评论(0编辑  收藏  举报