Git各指令的本质,真是通俗易懂啊
共 5920字,需浏览 12分钟
· 2021-05-19
点击“程序员面试吧”,选择“星标🔝”
点击文末“阅读原文”解锁资料!
中央式:所有的代码保存在中央服务器,所以提交必须依赖网络,并且每次提交都会带入到中央仓库,如果是协同开发可能频繁触发代码合并,进而增加提交的成本和代价。最典型的就是SVN。
分布式:可以在本地提交,不需要依赖网络,并且会将每次提交自动备份到本地。每个开发者都可以把远程仓库clone一份到本地,并会把提交历史一并拿过来。代表就是Git。
修改:Git可以感知到工作目录中哪些文件被修改了,然后把修改的文件加入到modified区域
暂存:通过add命令将工作目录中修改的文件提交到暂存区,等候被commit
提交:将暂存区文件commit至Git目录中永久保存
先看左边示意图,假设C2节点既是v1.0版本代码,上线后在C2的基础上新建一个分支ft-1.0
再看右边示意图,在v1.0上线后可在master分支开发v1.1内容,收到QA同学反馈后提交v1.1代码生成节点C3,随后切换到ft-1.0分支做bug修复,修复完成后提交代码生成节点C4,然后再切换到master分支并合并ft-1.0分支,到此我们就解决了上面提出的问题
git add 文件路径
git add .
git checkout -- 文件名
git reset HEAD 文件名
git commit -m "该节点的描述信息"
git branch 分支名
git checkout 分支名
git checkout -b 分支名
git branch -d 分支名
git merge 分支名/节点哈希值
git rebase 分支名/节点哈希值
优点:每个节点都是严格按照时间排列。当合并发生冲突时,只需要解决两个分支所指向的节点的冲突即可
缺点:合并两个分支时大概率会生成新的节点并分叉,久而久之提交历史会变成一团乱麻
优点:会使提交历史看起来更加线性、干净
缺点:虽然提交看起来像是线性的,但并不是真正的按时间排序,比如图3-3中,不管C4早于或者晚于C3提交它最终都会放在C3后面。并且当合并发生冲突时,理论上来讲有几个节点rebase到目标分支就可能处理几次冲突
git cherry-pick 节点哈希值
git checkout 节点哈希值
//也可以直接脱离分支指向当前节点
git checkout --detach
//HEAD分离并指向前一个节点
git checkout 分支名/HEAD^
//HEAD分离并指向前N个节点
git checkout 分支名~N
git commit --amend
//回退N个提交
git reset HEAD~N
git clone 仓库地址
git fetch 远程仓库地址/分支名
git pull 远程分支名
git pull --rebase 远程分支名
git push 远程分支名
不管是HEAD还是分支,它们都只是引用而已,引用+节点是 Git 构成分布式的关键
merge相比于rebase有更明确的时间历史,而rebase会使提交更加线性应当优先使用
通过移动HEAD可以查看每个提交对应的代码
clone或fetch都会将远程仓库的所有提交、引用保存在本地一份
pull的本质其实就是fetch+merge,也可以加入--rebase通过rebase方式合并