写代码啦
Git高级命令详解与实战(上)
回复数(0) 浏览数(194)
{{topic.upvote_count || 0}} 编辑 回复

Git高级命令详解与实战(上)

仓库/提交/分支的本质

  • 仓库的本质
    • 一个所有的历史都可以追溯的文件夹
    • 历史的最小单位是仓库在某个时刻的状态(快照)
    • 这个状态通常用commit-id表示也就是SHA-1 (16进制字符串)
    • 哪些东⻄可以标识仓库的某个状态?
    • commit对象的SHA-1(⽆需写全)
    • 分⽀(branch)
    • HEAD
    • 标签(tag)
  • 提交的本质(commit)
    • 仓库从一个主干上转移到另一个状态时发生的变化
    • commit对象
    • id
    • parent-id 父提交对象的id,可以有多个
    • commitor 提交者(name/email) 把代码提交到仓库的人,通过email唯一标识是谁提交的
    • author 编写代码的人
    • git的提交可以有多个父节点:合并、多路合并(octopus merge 章鱼合并)
    • commit对象是不可变的
    • 问 git commit --amend是什么?
    • 答 是修改提交信息,但是本质是创建(复制)了一个新的提交对象并且丢弃了之前要修改的提交对象
    • 持续的⼯作和提交,在仓库中建⽴了⼀棵树
    • 多分支多人协作
  • 分支的本质

    • ⼀个可以移动的指针,指向某个提交对象
    • 新建⼀个分⽀,就是新建⼀个指针
    • git checkout -b new-branch {仓库的某个状态} 新建一个分支
    • 比如需要基于 v1.5.3版本修一个bug,就可以用"git checkout -b new-branch v1.5.3"从v1.5.3这个tag上开启一个新的分支
    • git reset orgin/master --hard 把当前分支重置为远程的状态
    • 特殊的指针HEAD
    • 是活动的,在任何分支上都是指向这个分支的头
    • HEAD~1 master~1 a2dde3~3   
      • ~表示祖先commit  ~1 第一个祖先 ~3第三个祖先
    • HEAD^
      • 表示父级commit ^第一个父级 ^^父级的父级,如果有多个父级,那分支从左往右数区分,第一级第二个父级:^2
    • image.png image.png

      ### 远程仓库/本地仓库/fork 
  • Git是分布式版本控制系统

  • 远程仓库/本地仓库/fork本质上就是复制了整个文件夹

  • git clone 不仅仅可以发生在网络,还能发生在局域网和本地磁盘上

    • 本地克隆:把gogredle 克隆到了gogredle2文件夹里  image.png image.png
  • pull/push/push --force

    • git pull = git fetch + git merge
    • git pull --rebase = git fetch + git rebase
    • 只有远程分⽀和本地分⽀历史相同时,才能push成功
    • push --force 慎用,只能是该分支自己单人使用时才能用,不然会导致其他人的仓库紊乱

git merge与冲突解决

  • 合并的本质
    • 将两个或者多个状态(代码快照/代码副本)合并
    • git会逐行检查冲突,并且尝试自动解决
    • 解决失败,报错,需要人工去判断处理
  • 解决冲突
    • 人类判断,修改冲突为正确的版本
    • 要严格按照命令中的提示去进行冲突解决
    • 比如解决冲突后查看状态返回的命令行内容:
    • 您的分支和“ origin / new-branch”已经分岔,分别具有1和1个不同的提交。(使用“ git pull”将远程分支合并到您的分支中)所有的冲突已解决,但您仍在合并状态中。(使用“ git commit”结束合并)
    • image.png image.png
    • 如何放弃合并,分支回到想回的版本
    • 放弃当前合并 git merge --abort
    • 切换版本 image.png image.png

Merge与Rebase

  • merge:直接将两个状态合并,并产⽣⼀个合并提交
    • 【官⽅⽂档】将两个或多个开发历史交汇在⼀起
    • 优点
    • 简单,易于理解
    • 记录了完整的历史
    • 冲突解决简单
    • 缺点
    • 历史杂乱无章
    • 对bisect不有好(git-bisect 使用二分查找来查找引起bug的提交)
  • rebase:基于另外一个分支来重放当前分支的commit
    • 【官⽅⽂档】在另外⼀个分⽀的基础上重演当前分支上的所有提交
    • 优点
    • 分支的历史是一条直线,清楚直观
    • 对bisect友好(因为历史是一条直线)
    • 缺点
    • 复杂,劝退新手
    • 如果有冲突可能需要重复解决,因为是重演当前分支的提交(或者用 squash 合并提交)
    • 问:会不会干扰别人? 如果不会用那会影响,和别人共享的分支时永远不要用force push 强制提交 将本地rebase后的分支合并到远程分支上。
    • 使用场景
      • 定时讲自己的分支和主干进行同步,为了减少分支开发时间太长和主干相差太大最终导致合并时一堆冲突的风险
  • git merge --squash
    • 优点
    • 把所有变更合在一起,更容易阅读,bisect友好
    • 想要回滚或者revert非常方便
    • 缺点
    • 丢失了所有的历史记录
  • 使⽤merge还是rebase?
    • 充分了解二者,然后看自己的喜好
    • 在任何需要和其他人共享的分支上,不要force push
    • 在自己独占的分支上,尽量使用rebase
  • 区别
    • merge:当前在master分支 git merge feature  左图
    • rebase:当前在feature分支 git rebase master 右图
    • image.png image.png
    • 注意图只是演示执行完对应命令的状态 并不是完整的合并分支的操作 rebase后面还有要将本地分支 git push --force 强推到全程分支上的操作

遗留的问题

1. git-bisect 使用二分查找来查找引起bug的提交

扩展

github logo 八爪猫 octopuss  octopus+pussy 后面改为 octocat
注:git的命令输出要关注 他会告诉我们该怎么做,包含很多重要的信息/.git 里面有个微型数据库,存的是仓库的信息
{{topic.upvote_count || 0}}

Git高级命令详解与实战(上)

仓库/提交/分支的本质

  • 仓库的本质
    • 一个所有的历史都可以追溯的文件夹
    • 历史的最小单位是仓库在某个时刻的状态(快照)
    • 这个状态通常用commit-id表示也就是SHA-1 (16进制字符串)
    • 哪些东⻄可以标识仓库的某个状态?
    • commit对象的SHA-1(⽆需写全)
    • 分⽀(branch)
    • HEAD
    • 标签(tag)
  • 提交的本质(commit)
    • 仓库从一个主干上转移到另一个状态时发生的变化
    • commit对象
    • id
    • parent-id 父提交对象的id,可以有多个
    • commitor 提交者(name/email) 把代码提交到仓库的人,通过email唯一标识是谁提交的
    • author 编写代码的人
    • git的提交可以有多个父节点:合并、多路合并(octopus merge 章鱼合并)
    • commit对象是不可变的
    • 问 git commit --amend是什么?
    • 答 是修改提交信息,但是本质是创建(复制)了一个新的提交对象并且丢弃了之前要修改的提交对象
    • 持续的⼯作和提交,在仓库中建⽴了⼀棵树
    • 多分支多人协作
  • 分支的本质

    • ⼀个可以移动的指针,指向某个提交对象
    • 新建⼀个分⽀,就是新建⼀个指针
    • git checkout -b new-branch {仓库的某个状态} 新建一个分支
    • 比如需要基于 v1.5.3版本修一个bug,就可以用"git checkout -b new-branch v1.5.3"从v1.5.3这个tag上开启一个新的分支
    • git reset orgin/master --hard 把当前分支重置为远程的状态
    • 特殊的指针HEAD
    • 是活动的,在任何分支上都是指向这个分支的头
    • HEAD~1 master~1 a2dde3~3   
      • ~表示祖先commit  ~1 第一个祖先 ~3第三个祖先
    • HEAD^
      • 表示父级commit ^第一个父级 ^^父级的父级,如果有多个父级,那分支从左往右数区分,第一级第二个父级:^2
    • image.png image.png

      ### 远程仓库/本地仓库/fork 
  • Git是分布式版本控制系统

  • 远程仓库/本地仓库/fork本质上就是复制了整个文件夹

  • git clone 不仅仅可以发生在网络,还能发生在局域网和本地磁盘上

    • 本地克隆:把gogredle 克隆到了gogredle2文件夹里  image.png image.png
  • pull/push/push --force

    • git pull = git fetch + git merge
    • git pull --rebase = git fetch + git rebase
    • 只有远程分⽀和本地分⽀历史相同时,才能push成功
    • push --force 慎用,只能是该分支自己单人使用时才能用,不然会导致其他人的仓库紊乱

git merge与冲突解决

  • 合并的本质
    • 将两个或者多个状态(代码快照/代码副本)合并
    • git会逐行检查冲突,并且尝试自动解决
    • 解决失败,报错,需要人工去判断处理
  • 解决冲突
    • 人类判断,修改冲突为正确的版本
    • 要严格按照命令中的提示去进行冲突解决
    • 比如解决冲突后查看状态返回的命令行内容:
    • 您的分支和“ origin / new-branch”已经分岔,分别具有1和1个不同的提交。(使用“ git pull”将远程分支合并到您的分支中)所有的冲突已解决,但您仍在合并状态中。(使用“ git commit”结束合并)
    • image.png image.png
    • 如何放弃合并,分支回到想回的版本
    • 放弃当前合并 git merge --abort
    • 切换版本 image.png image.png

Merge与Rebase

  • merge:直接将两个状态合并,并产⽣⼀个合并提交
    • 【官⽅⽂档】将两个或多个开发历史交汇在⼀起
    • 优点
    • 简单,易于理解
    • 记录了完整的历史
    • 冲突解决简单
    • 缺点
    • 历史杂乱无章
    • 对bisect不有好(git-bisect 使用二分查找来查找引起bug的提交)
  • rebase:基于另外一个分支来重放当前分支的commit
    • 【官⽅⽂档】在另外⼀个分⽀的基础上重演当前分支上的所有提交
    • 优点
    • 分支的历史是一条直线,清楚直观
    • 对bisect友好(因为历史是一条直线)
    • 缺点
    • 复杂,劝退新手
    • 如果有冲突可能需要重复解决,因为是重演当前分支的提交(或者用 squash 合并提交)
    • 问:会不会干扰别人? 如果不会用那会影响,和别人共享的分支时永远不要用force push 强制提交 将本地rebase后的分支合并到远程分支上。
    • 使用场景
      • 定时讲自己的分支和主干进行同步,为了减少分支开发时间太长和主干相差太大最终导致合并时一堆冲突的风险
  • git merge --squash
    • 优点
    • 把所有变更合在一起,更容易阅读,bisect友好
    • 想要回滚或者revert非常方便
    • 缺点
    • 丢失了所有的历史记录
  • 使⽤merge还是rebase?
    • 充分了解二者,然后看自己的喜好
    • 在任何需要和其他人共享的分支上,不要force push
    • 在自己独占的分支上,尽量使用rebase
  • 区别
    • merge:当前在master分支 git merge feature  左图
    • rebase:当前在feature分支 git rebase master 右图
    • image.png image.png
    • 注意图只是演示执行完对应命令的状态 并不是完整的合并分支的操作 rebase后面还有要将本地分支 git push --force 强推到全程分支上的操作

遗留的问题

1. git-bisect 使用二分查找来查找引起bug的提交

扩展

github logo 八爪猫 octopuss  octopus+pussy 后面改为 octocat
注:git的命令输出要关注 他会告诉我们该怎么做,包含很多重要的信息/.git 里面有个微型数据库,存的是仓库的信息
194
回复 编辑