feat(ch5): translate 365-589

ch5/ENG_ch5.srt

@@ -1456,7 +1456,7 @@ could imagine this bug fix breaking this
 
 365
 00:13:31,190 --> 00:13:32,840
-feature or something like that oh that's
+feature or something like that, oh that's
 
 366
 00:13:32,840 --> 00:13:34,790
@@ -1592,7 +1592,7 @@ exactly is this represented as a as a
 
 399
 00:15:07,770 --> 00:15:09,750
-data structure inside get and so I'm
+data structure inside Git and so I'm
 
 400
 00:15:09,750 --> 00:15:10,980
@@ -1628,7 +1628,7 @@ folders they're mappings from the
 
 408
 00:15:39,180 --> 00:15:41,970
-filename or directoryname to the actual
+filename or directory name to the actual
 
 409
 00:15:41,970 --> 00:15:44,760
@@ -1716,7 +1716,7 @@ this is basically all there is to how
 
 430
 00:17:00,769 --> 00:17:04,130
-get models history any questions about
+Git models history any questions about
 
 431
 00:17:04,130 --> 00:17:10,160
@@ -1792,11 +1792,11 @@ might say that to store a particular
 
 449
 00:18:16,640 --> 00:18:19,580
-object o what I do is I compute its ID
+object O what I do is I compute its ID
 
 450
 00:18:19,580 --> 00:18:25,960
-by taking the sha-1 hash of o and then I
+by taking the SHA-1 hash of O and then I
 
 451
 00:18:27,280 --> 00:18:30,799
@@ -1828,7 +1828,7 @@ big piece of data and turns it into a
 
 458
 00:18:47,600 --> 00:18:51,140
-short string at a high level these are
+short string, at a high level these are
 
 459
 00:18:51,140 --> 00:18:54,860
@@ -1932,7 +1932,7 @@ clear enough or do I need to explain any
 
 484
 00:19:59,239 --> 00:20:06,470
-aspects of it great okay so blobs trees
+aspects of it. great okay so blobs, trees
 
 485
 00:20:06,470 --> 00:20:09,289
@@ -2008,7 +2008,7 @@ different objects are just by their ID
 
 503
 00:20:50,570 --> 00:20:53,899
-by their sha-1 hash does that make sense
+by their SHA-1 hash does that make sense
 
 504
 00:20:53,899 --> 00:20:55,580
@@ -2084,11 +2084,11 @@ have a way of identifying objects by
 
 522
 00:21:51,710 --> 00:21:54,139
-their sha-1 hash what do these actual
+their SHA-1 hash what do these actual
 
 523
 00:21:54,139 --> 00:21:56,359
-sha-1 hashes look like well they're
+SHA-1 hashes look like well they're
 
 524
 00:21:56,359 --> 00:21:58,129
@@ -2100,11 +2100,11 @@ characters long
 
 526
 00:21:59,059 --> 00:22:02,839
-like sha-1 is a 160-bit hash and so one
+like SHA-1 is a 160-bit hash and so one
 
 527
 00:22:02,839 --> 00:22:05,539
-of the actual IDs returned by that sha-1
+of the actual IDs returned by that SHA-1
 
 528
 00:22:05,539 --> 00:22:07,489
@@ -2184,7 +2184,7 @@ so this is another piece of data that
 
 547
 00:23:06,000 --> 00:23:08,970
-get maintains internally references is a
+Git maintains internally references is a
 
 548
 00:23:08,970 --> 00:23:16,679
@@ -2908,7 +2908,7 @@ contents hello world and then this has
 
 728
 00:30:41,399 --> 00:30:46,279
-the sha-1 hash for 2fb
+the SHA-1 hash for 2fb
 
 729
 00:30:46,279 --> 00:30:48,059

ch5/[365-589]CHN.txt

@@ -0,0 +1,194 @@
+[365]
+是的，这是个很好的关注点
+这里有一个东西叫合并冲突
+当你合并你的平行开发的分支时
+Git 将尝试以某种方式自动合并变化
+以保留所有重要的修改
+但如果它感到困惑
+就会报告一个合并冲突
+然后把问题留给你这个程序员来解决
+好比如何合并相同文件或类似的东西（在不同分支）同时发生变化的问题
+然后，然后有一些工具来解决他
+还有什么问题吗
+我们有一个文件和文件夹的模型
+然后我们有一个历史模型
+我们的代码的不同快照是如何相互关联的
+[384]
+这里有一个小细节
+每个圆圈都对应着一个快照
+就像一棵有文件和文件夹的树
+但它们也有一些元数据
+比如在这里，我们可能有这个提交的作者(Author)是我，
+我们可能有其他的元数据
+比如与这个提交相关的一些消息
+我可能描述我做了什么样的改动
+这些改动存在于这个快照中
+而不是前一个快照
+所以接下来我们要讨论的是比这更低一级的数据结构
+比如这个数据结构在 Git 里面到底是怎么表示的
+所以我实际上要写下伪代码
+因为我觉得这样最容易理解
+所以首先我们要有文件
+所以日志只是一堆字节
+[404]
+所以我说这是一个字节数组
+好的，那么什么是树（tree）呢？
+* 为了便于理解，括号内将标注术语对应词汇
+记住，这只是一个文件夹
+它们是文件名或目录名到实际内容的映射
+而内容是另一棵树（tree）
+比如子树（tree）或文件（blob）
+最后我们还有最后一个东西
+到目前为止，我一直称之为快照
+按术语，这些被称为提交（commit）
+那么什么是提交？
+一个提交是一堆东西
+提交有父亲（parent）
+描述了它们之前的内容
+所以在大多数正常提交的情况下
+它们有一个父亲
+比如它们来自什么地方
+合并提交可以有多个父亲
+所以父本是一个提交的数组
+然后有一些元数据
+比如作者和可能的消息
+最后是实际内容
+快照是一棵树，是一个特定提交的顶层树
+这是一个非常简洁的历史模型
+这就是 Git 的历史模型的全部内容
+有什么问题吗？
+现在我们有了更深入的了解
+让我们谈谈它是如何实际存储和处理这些数据的
+[441]
+因此，在磁盘上维护的东西
+实际上我们在后面要看到
+是一组作为内容地址存储的对象
+所以如果你有这些对象中的任何一个
+你把它放进这个存储的方式是它的键是对象的哈希值
+所以在伪代码中，我可能会说
+为了存储一个特定的对象 O
+我所做的是通过获取 O 的 SHA-1 哈希值来计算它的 ID
+然后我把它放到我的对象映射中
+把它存储到磁盘上
+快举手，这里有谁知道什么是哈希函数
+好吧，我快速总结一下
+基本上哈希函数就是你可以把它想象成一个魔法函数
+把一个长的数据变成一个短的
+在高层次上，这些都是用来
+我觉得说这么多足够了 # REVIEW: Need discussion 18:45
+我不会在这里说得太详细
+但你可以事后问我
+如果你很好奇
+所以基本上他们给你一种方法
+以一种确定性的方式来命名一个基于常数的东西
+它把东西作为输入
+返回给你一个简短的名字
+然后，与存储的方式相反
+我们可以从存储中加载东西
+你可能已经猜到了
+你可以通过他们的 ID 来查找他们
+我们通过 ID 从对象存储中检索它
+然后返回给我们内容
+有什么问题吗？
+这个问题问得好
+这都是用什么语言写的？
+它是用我刚编出来的语言写的
+所以它是伪代码
+它的实现本身是C语言的混合体
+主要是C语言，然后是一些 bash 和 Perl 脚本
+我想还有其他的问题
+这个编造的语言是否足够清晰
+或者我是否需要解释它的任何方面。
+[484]
+好吧，那么 blob、tree 和 commit 都是统一的
+它们都是对象
+而且正如你可能认为的那样
+鉴于我在这里的描述
+看起来提交包含一大堆其他的提交
+包含快照之类的东西
+实际上并不是这样的
+而是所有这些都是指针
+所以一个提交将能够通过 ID 引用一堆父亲
+所以这实际上不是一个提交本身的数组
+而是ID的数组
+同样，提交中的快照也不是实际的树对象
+而是树的ID
+所以所有这些对象都是独立存储在这个对象存储中
+然后所有对不同对象的引用都是通过它们的ID
+也就是它们的SHA-1哈希值
+这有意义吗？
+你几乎可以在你的头脑中
+把它映射成像 Java 这样的编程语言中的对象
+然后这是一个对树的引用，所以它就像一个指针
+然后这就是你的领域了
+也许这很顽皮，也许没有帮助
+[511]
+是的，所以我再重复一遍
+让大家在麦克风上听到
+这是磁盘上的数据存储
+是一个内容地址存储
+对象是通过它们的哈希值来寻址的
+好的，到目前为止有什么问题吗？
+好了，现在我们有了一种识别方法
+我们已经将所有不同类型的对象统一为一种类型
+我们称之为 object
+我们有了一种通过 SHA-1 哈希值来识别对象的方法
+这些实际的 SHA-1 哈希值是什么样子的呢？
+它们是长达40个字符的十六进制字符串
+比如 SHA-1 是一个160位的哈希值
+所以由 SHA-1 函数返回的实际ID将是一个非常长的字符串
+所以考虑到我们会有方法来识别这些不同的东西
+比如我们会有一个对应的ID
+比如一个4af32b等等之类的东西
+所以现在我们有一种方法来命名这个提交图中的所有东西
+但这些名字真的很不方便
+因为它们超长
+而且就像文本字符串一样
+对人类没有任何意义
+这个问题的解决方案是
+它维护了一组对象
+然后维护了一组引用
+我们的引用在这里
+我会把左边的这部分擦掉
+这部分很有逻辑性
+引用就在这里
+这是 Git 内部维护的另一块数据
+引用是一个从字符串到字符串的映射
+你可以把它看作是人类可读的名字的映射
+比如我可能有一个名字是「fix encoding bug」
+一个人类可读的名字
+这将被映射到像那个长的十六进制字符串
+所以有了这些引用
+你可以想象
+我们有何办法做创建新的引用和更新引用之类的事
+[559]
+有了这个
+我现在可以用名字来指代我的提交图中的东西
+所以我可能会有另一个名字，比如「fix bug」
+指代同样的对象
+或者我可能会有一个名字来指代这里的东西
+诸如此类，所以有了这个
+我可以用人类可读的名字来指代历史中的特定快照
+而不是这些长长的十六进制字符串
+还有一点需要注意的是
+鉴于 Git 对历史的设计
+整个图实际上是不可变的
+* 事实上有一个专门的术语称呼这种数据结构：可持久化
+你可以向它添加新的东西
+但实际上你不能在这里操作任何东西
+我不会去研究具体的方法或原因
+但只是假设这是事实
+但是引用是不可变的
+所以当你更新历史的时候
+比如说你一直在开发这个软件
+你创建了一个新的提交
+所以我用这个圆圈来表示
+这个圆圈指向之前的提交
+实际上我可以说我的「fix bug」引用指向这里
+我可以更新这个引用，现在指向这里
+但是我不能比如说把这个指向这里
+这甚至不是一个有意义的事情
+因为这只是这个对象的哈希值
+要改变这个哈希值
+我需要改变这个对象的内容
+这没意义