网站怎么做动态图,上海公司查询网站,网上国网推广经验,网站系统管理功能我们中的许多人每天都在使用 git#xff0c;但是有多少人知道它的内部是怎么运作的呢#xff1f;例如我们使用 git commit 时发生了什么#xff1f;提交#xff08;commit#xff09;与提交之间保存的是什么#xff1f;两次提交之间难道只是文件的差异#xff08;dif… 我们中的许多人每天都在使用 git但是有多少人知道它的内部是怎么运作的呢例如我们使用 git commit 时发生了什么提交commit与提交之间保存的是什么两次提交之间难道只是文件的差异diff吗如果是这个差异是如何编码的还是说每次提交都会保存一个当前仓库的完整快照snapshot呢我们使用 git init 时到底发生了什么很多 git 的使用者都不知道这几个问题的答案但这又有什么关系呢首先作为专业人员我们应当努力弄清楚手中使用的工具尤其是那些我们一直都在使用的——比如 git。但是我深刻地意识到理解 Git 的工作原理在很多情况下都非常有用——不管是解决合并冲突、进行有趣的变基rebase操作还是在某些东西变得有点不对劲的时候。如果你有足够的 git 经验对 git pull、git push、git add 或 git commit 这些命令得心应手你会从本文中获益。不过为了确保我们在 git 的原理尤其是本文上下所使用的术语上步调一致我们将从概览开始。我也在 YouTube 上传了一个涵盖本文所有内容的系列视频——欢迎在此点击观看。本教程的内容我们将对日常使用的 git 的内部运行原理有一个比较深入的理解。我们会从对象object——blob、树对象tree 和 提交对象commit 开始然后简单讨论一下 分支branch 及其实现方式之后会深入 工作目录working directory、暂存区staging area 和 仓库repository。我们会确保理解了这些术语是与我们用来创建新仓库的那些命令之间是如何关联的。接下来我们会从零开始创建一个仓库——不使用 git init、git add 或 git commit。这会在我们使用 git 的过程中加深我们对其内部正在发生的事情的理解。我们也会创建新的分支、在分支间切换再进行一些提交——全程不使用 git branch 或 git checkout。在本文结束之前你会觉得自己真的 理解了 git。你准备好了吗????译者注建议读者配合 Git 内部原理阅读本文。Git 对象——blob、tree 和 commit译者注译文中的 数据对象、树对象 和 提交对象 指的就是 blob、tree 和 commit 这三者。因为 Git 官网的文档 Git 内部原理 - Git 对象对三者进行了这样的翻译本文是为了与其保持一致。但由于 blob 一词的特殊性译文会直接保留原词而不是将其翻译为“数据对象”。将 git 看成一个文件系统尤其是该系统的实时快照是很有用的。一个文件系统从 根目录root directory 开始在基于 UNIX 的系统中是 /通常也会包含其它的目录例如 /usr 或 /bin。这些目录会包含其它的目录和或文件例如 /usr/1.txt。在 git 中文件的内容存储在一些被称为 blob 二进制大对象的对象中。blob 与文件的不同在于文件还会包含元数据meta-data。例如一个文件会“记住”它的创建时间如果你把它移动到另一个目录它的创建时间是不会改变的。相反blob 只是内容——数据的二进制流。除了内容以外blob 不会记录它的创建时间、名字或任何其它东西。git 中的 blob 通过 SHA-1 哈希值 唯一标识。SHA-1 哈希值由 20 个字节byte组成通常表示成 40 个十六进制形式的字符。在这篇文章中我们有时只会展示这个哈希值的前几个字符。Blob 有对应的 SHA-1 哈希值在 git 中树对象tree 相当于目录。一个 树对象 基本上就是一个目录列表它引用着 blob 和其它的 树对象。树对象 也用 SHA-1 哈希值唯一标识它通过其它对象blob 或 树对象的 SHA-1 哈希值引用它们。树对象是一个目录列表注意 CAFE7 这个 树对象 指向了 blob F92A0pic.png在另一个 树对象 中同一个 blob 可能会有不同的名字。树对象可能包含子树对象和其它 blob上面这张图相当于一个文件系统这个文件系统有一个根目录根目录下有一个位于 /test.js 的文件和一个名为 /docs 的目录/docs 目录下有两个文件/docs/pic.png 和 /docs/1.txt。现在是时候捕获该文件系统的一个快照了把那个时刻存在的所有文件连同它们的内容保存下来。在 git 中一个快照就是一个 提交commit。一个 提交 对象包括一个指向主要 树对象根目录的指针和一些像 提交者、提交信息 和 提交时间 这样的元数据。在大多数情况下一个 提交 还会有一个或多个父 提交——之前的快照。当然提交 对象也通过它们的 SHA-1 哈希值唯一标识。这些哈希值就是我们使用 git log 命令时看到的那些哈希值。提交对象是某个时刻的快照它引用着树的根节点。由于这是第一次提交它没有父节点每个 提交 都持有 完整的快照并不只是与之前 提交 之前的差异。那么它是怎么工作的呢难道它不代表我们每次提交都必须保存很多数据吗让我们来看看改变一个文件的内容会发生什么。我们编辑 1.txt加一个感叹号——也就是把文件的内容由 HELLO WORLD 变为 HELLO WORLD!。这个改变意味着我们会有一个新的 blob它有新的 SHA-1 哈希值。这是有意义的因为 sha1(HELLO WORLD) 与 sha1(HELLO WORLD!) 并不相同。改变 blob 会得到新的 SHA-1 值由于我们得到了一个新的哈希值所以对应 树对象 的目录也会改变。毕竟我们的 树对象 不再指向 blob 73D8A 了而是指向了 blob 62E7A。当我们改变 树对象 的内容时我们也改变了它的哈希值。blob 变了指向它的树对象也需要变现在由于原来那个 树对象 的哈希值已经不同了我们也需要改变它的父树对象——后者不再指向 tree CAFE7 了而是指向了 tree 246001。最终父树对象也会有一个新的哈希值。根节点也变了它的哈希值也变了几乎做好创建一个新提交对象的准备了我们好像会再一次保存很多的数据——整个文件系统。但是真的有必要这么做吗实际上一些对象尤其是 blob 对象相比起之前的提交来说没有任何改变——blob F92A0仍然原封不动blob F00D1 也一样。这就是其中的秘诀——只有对象改变了我们才再次保存它。在这个例子中我们不需要再次保存 blob F92A0 和 blob F00b1。我们只需要通过它们的哈希值引用它们然后我们可以创建 提交 对象。那些没有丝毫变化的 blob 是通过它们的哈希值被引用的由于这次 提交 不是第一次 提交所以它有一个父节点——commit A1337。回顾一下我们介绍了三种 git 对象blob——文件的内容。树对象——一个由 blob 和 树对象 组成的目录列表。提交对象——工作树的一个快照。让我们思考一下这些对象的哈希值吧。如果我写了 git is awesome! 并从它创建了一个 blob。你也在自己的系统上这么做我们会有相同的哈希值吗答案是肯定的。因为这两个 blob 有相同的内容自然也会有相同的 SHA-1 哈希值。如果我创建了一个引用 git is awesome! 这个 blob 的 树对象 赋给它一个特定的名字和元数据你也在自己的系统上重复我的操作。我们会有相同的哈希值吗答案还是肯定的。因为这两个树对象是相同的它们会有同样的哈希值。如果我创建了一个指向那个 树对象的提交对象提交信息为 Hello你也在自己的系统上重复了一遍这个操作结果会怎样呢我们的哈希值还会相同吗这个时候的答案是否定的。即使我们的提交对象指向了相同的树对象它们也会有不同的提交详情——时间、提交者等等。Git 中的分支分支branch只不过是提交对象的命名引用。译者注分支引用的是提交对象为了简单起见下文在谈分支时有时候会将提交对象 简称为提交。我们可以一直用 SHA-1 哈希值引用一个提交但是人们通常喜欢以其他形式命名对象。分支恰好是引用提交的一种方式实际上也只是这样。在大多数仓库中主线开发都是在一个叫做 master 的分支上完成的。master 只是一个名字它是在我们使用 git init 命令的时候被创建的。正因为如此它被广泛使用。然而它并不特别我们可以用任何我们喜欢的名字代替它。通常分支指向的是当前开发线上的最近一次提交。我们通常使用 git branch命令创建一个新分支而我们实际创建的却是另一个指针pointer。假设我们使用 git branch test命令创建了一个名为 test的分支我们实际上是创建了另一个指针它指向当前分支上的同一 提交。使用 git branch 创建另一个指针git 是怎么知道我们当前所在的分支呢答案是它维护了一个名为 HEAD 的特殊指针。通常情况下HEAD 会指向一个分支这个分支指向一个提交。有时候HEAD 也能直接指向一个提交不过这不是我们的重点。HEAD 指向我们当前所在的分支译者注活动分支active branch指的是我们当前所在的分支也就是 HEAD 指向的分支。要将活动分支切换到 test我们可以使用命令 git checkout test。现在我们已经能猜到这条命令真正做的事情了——它只不过是把 HEAD 指向的分支改成了 test。git checkout test 改变 HEAD 指向的分支在创建 test 分支之前我们也可以使用 git checkout -b test这条命令等价于先运行 git branch test 创建分支再运行 git checkout test 使 HEAD 指向新的分支。如果我们做了一些改动并使用 git commit 创建了一个新提交呢这个新提交会被添加到哪个分支上呢答案是 test 分支因为它是当前的活动分支因为 HEAD 指向了它。之后test 指针会移动至新添加的 提交 上。注意 HEAD 仍然指向 test。每次执行 git commit 命令都会让分支的指针移动到新创建的提交上因此如果我们使用 git checkout master 回到 master 分支我们就让 HEAD 的再次指向 master 了。如果我们现在创建一个新的 提交它就会被添加到 master 分支commit B2424 会成为新提交的父节点。如何在 Git 中记录变化通常我们在工作目录working dir 中编写源代码。工作目录或工作树working tree可以是文件系统上的任何一个目录它关联着一个仓库repository。目录内不仅包含工程的文件夹和文件还包含一个名为 .git 的目录。稍后我们会再讨论 git 这个目录。在做了一些改动之后我们想把这些改动记录到我们的仓库中。一个仓库缩写repo就是一系列提交的集合每个提交都是工程工作树的归档。除了我们自己机器上的提交外仓库也会包含他人机器上的提交。仓库 也包含除代码文件以外的其它东西例如 HEAD 指针、分支等等。你可能使用过的其它和 git 类似工具但是 git 并不会像其它工具那样直接将变化从工作树提交到仓库。相反它会先把这些变化注册到一个被称为索引index或暂存区staging area的地方。这两个术语指的都是同一个东西它们也经常被 git 的文档使用我们将会在这篇文章中交替使用它们。当我们 checkout 到一个分支时git 会将上一次检出到工作目录中的所有文件填充到索引它们看起来就像最初被检出时的样子。之后执行 git commit 时提交会在当前 索引 的基础上创建。索引允许我们精心准备每次 提交。举个例子自上一次提交以来我们的工作目录中可能有两个文件发生了变化但是我们可能只想将其中的一个添加到索引使用 git add然后使用 git commit 记录这一个文件的变化。工作目录下文件的状态不外乎有两种已跟踪tracked或未跟踪untracked。已跟踪文件是指那些 git 已经知道的文件。它们要么已经在上一次快照提交中要么已经被 暂存staged换句话说它们已经在 暂存区 中。工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件untracked它们既没有在上次快照提交中也没有在暂存区中。创建仓库的常规方式让我们确认下我们已经理解了“创建仓库”时介绍的相关术语。在我们更加深入这个过程之前这只是一个非常高阶的视角。注意大多数带有 shell 命令的文章展示的都是 UNIX 命令。我将同时给出 Windows 和 UNIX 下的命令。为了换换花样我会给出 Windows 下面的截图。当两种环境下的命令完全一样时我只会给出一次命令。我们用 git init repo_1 初始化一个新的仓库然后用 cd repo_1 切换到仓库所在目录。借助 tree /f .git 命令我们可以看到运行 git init 之后 .git 目录下面出现了很多子目录/f 表示在 tree 的输出中包含文件。让我们在 repo_1 目录中创建一个文件吧Linux 系统这个文件已经在我们的 工作目录 中了。目前我们还没有将它添加到 暂存区所以它是 未跟踪 状态。让我们用 git status 验证一下因为我们没有将新的文件添加到暂存区所以它还是未跟踪状态它也没有在之前的提交中我们现在用 git add new_file.txt 将这个文件添加到 暂存区再用 git status 验证一下它是否已经被暂存了添加新的文件到暂存区我们可现在可以用 git commit 创建一个 提交.git 目录有变化吗我们用 tree /f .git 检查一下git 目录中的很多东西已经变了很明显很多东西都变了。是时候深入 .git 的结构理解执行 git init、git add 或 git commit 之后发生的什么事情了。是时候上干货了目前我们已经讲了一些 Git 的基础知识现在已经做好 Git 上路 的准备了。为了深入理解 git 是如何工作的我们将从零开始创建一个仓库。我们不会使用 git init、git add 或 git commit这会让我们更好地理解这个过程。如何设置 .git先创建一个新目录然后在里面运行 git status好吧因为我们没有 .git 文件夹git 好像不怎么高兴。我们先把这个目录创建出来很明显只创建一个 .git 目录还不够。我们需要往这个目录添加一些东西。一个 git 仓库有两个主要组成部分一组对象——blob、树对象 和 提交对象。一个命名这些对象的方式——称为 引用。译者注引用是 Git 中的一个重要概念读者可以进一步阅读 Git 引用。一个 仓库 可能还包含一些其它的东西比如 git 钩子hooks。不过仓库至少必须要有对象和引用。让我们分别为对象和引用简称refs各创建一个目录Windows 下的两个目录分别为 .git\objects 和 .git\refsUNIX 下的两个目录分别为 .git/objects 和 .git/refs。分支 是引用的一种git 内部将 分支 称为 heads所以我们会为它们创建一个目录 git\refs\heads。然而 git status 的输出还是纹丝不动在寻找 仓库 中的 提交 时git 怎么知道该从何开始呢我之前解释过它会寻找 HEAD而 HEAD 指向着活动分支。所以我们需要创建 HEAD它是一个位于 .git\HEAD 的文件。我们可以这么做Windows echo ref: refs/heads/master .git\HEADUNIX$ echo ref: refs/heads/master .git/HEAD⭐ 所以我们现在知道 HEAD 是如何实现的了——它只是一个文件文件内容描述了它所指向的分支。执行上面的命令以后git status 似乎改变它的主意了HEAD 只不过是一个文件注意虽然我们还没有创建 master 分支但是 git 相信我们就在这个分支上。之前有讲过master只是一个名字。如果我们想的话也可以让 git 认为我们在 banana 分支上????按照惯例我们将在本文的剩余部分中切回 master 分支。我们已经准备好了 git 目录现在继续往下来一次 提交同样地不使用 git add 或 git commit。Git 中的底层命令与上层命令这个时候区分 底层plumbing 和 上层poreclain 两类 git 命令会对你很有帮助。这两个术语的应用奇怪地来自于马桶没错就是????。马桶通常是用陶瓷porcelain做的它的基本结构是管道plumbing上水道和下水道。我们可以说上层命令为底层命令提供了一个用户友好的接口。大多数人只会涉及到上层命令。然而当事情变得非常糟糕时有人可能就会想知道为什么他们会卷起袖子去检查底层命令。注意这些术语并不是我发明的它们在 git 中的使用非常广泛。译者注读者若想更好的理解这两个术语建议阅读 Git 内部原理 - 底层命令与上层命令。git 使用这些术语进行类比从而将用户不常使用的底层命令plumbing和那些更友好的高层porcelain命令区分开。目前我们已经接触过上层命令——git init、git add 和 git commit。接下来我们转到底层命令。如何创建对象让我们从创建对象并将其写入 git 的对象数据库开始吧git 的对象数据库位于 .git\objects 中。第一条底层命令 git hash-object 会让我们将找到 blob 对象 的 SHA-1 哈希值。方式如下Windows echo git is awesome | git hash-object --stdinUNIX$ echo git is awesome | git hash-object --stdin我们使用 --stdin 告知 git hash-object 从标准输入standard input获取输入内容这将给我们提供相应的哈希值。为了真的将该 blob 对象 写入 git 的对象数据库我们可以简单地给 git hash-object 加一个 -w 开关。然后检查 .git 目录中的内容看看它们有没有改变。将一个 blob 对象写入对象数据库我们现在可以看到这个 blob 的哈希值为 54f6...36 .git\objects 下也多出来了一个名为 54 的目录目录内有一个名为 f6..36 的文件。所以git 实际上是使用 SHA-1 哈希值的前两个字符作为目录的名字剩余字符用作 blob 所在文件的文件名。为什么要这样呢考虑一个非常大的仓库仓库的数据库内存有三十万个对象blob 对象、树对象 和 提交对象。从这三十万个哈希值中找出一个值会花些时间因此git 将这个问题划分成了 256 份。为了查找上面的那个哈希值git 会先寻找 .git\objects 目录下名为 54 的目录然后搜索那个目录这进一步缩小了搜索范围。.git\objects 目录下最多可能会有 256 个子目录从 00 到 FF。回到生成 提交对象 的过程中来现在我们已经创建了一个对象它的类型是什么呢我们可以通过另一个底层命令 git cat-file -t -t 代表“type”瞧一瞧不出所料这个对象是一个 blob。我们还可以使用 git cat-file -p -p 代表“pretty-print”查看它的内容创建 blob 这个过程通常发生在我们将一些东西添加到 暂存区 的时候——也就是我们使用 git add 的时候。记住git 是为 整个 暂存的文件创建 blob。即使文件中只有修改或添加了一个字符如同我们在之前的例子红添加 ! 一样该文件也会有一个新的 blob这个 blob 有着新的哈希值。git status 会有任何改变吗显然没有。向 git 的内部数据库中添加一个 blob 对象并不会改变状态因为 git 在这个阶段是不知道任何已跟踪或未跟踪文件的。我们需要跟踪这个文件——把它添加到 暂存区。为此我们可以使用底层命令 git update-index例如git update-index --add --cacheinfo 100644 blob-hash filename。注意cacheinfo 是一个 git 存储的十六位的文件模式这个模式遵循 POSIX 类型和模式 的布局。这超出了本文讨论的范围。运行上述命令会改变 .git 目录的内容你能发现变化吗多了一个名为 index 的新文件。这就是著名的索引或 暂存区它基本上是一个位于 .git\index 中的文件。既然 blob 已经被添加到了 索引我们希望 git status 看起来会有所不同像这样真有趣这里发生了两件事。第一件事我们可以在 changes to be committed 中看到绿色的 new_file.txt。这是因为索引中有了 new_file.txt它正等着被提交。第二件事我们可以看到红色的 new_file.txt——因为 git 相信 my_file.txt 这个 文件 已经被删除了并且它没有被暂存。这发生在我们将内容为 git is awesome 的 blob 添加到对象数据库中的时候我们告诉 索引 那个 blob 的内容在文件 my_file.txt 中但是我们从未创建过那个文件。通过将那个 blob 的内容写入我们文件系统中名为 my_file.txt 的文件我们可以很容易地解决这个问题执行 git status 后它将不再出现在红色内容中现在是时候从我们的暂存区创建一个提交对象了。如上所述一个提交 对象引用着一个树对象所以我们需要创建一个树对象。我们可以用 git write-tree 做这件事它会在一个树对象中记录索引的内容。当然我们可以使用 git cat-file -t 进行确认创建索引的树对象我们还可以用 git cat-file -p 查看它的内容太棒了我们创建了一个树对象现在我们需要创建一个引用这个树对象的提交对象。为此我们可以使用 git commit-tree tree-hash -m commit message你现在应该对查看对象类型和打印对象内容的命令感到得心应手了创建一个提交对象注意这个 提交 并没有 父节点因为它是第一个 提交。当我们添加另一个 提交 时我们就得声明它的 父节点了——我们稍后会做这个。我们刚得到的哈希值80e...8f是一个 提交对象 的哈希值。实际上我们非常习惯使用这些哈希值——我们一直都在看它们。注意这个 提交对象 拥有一个 树对象树对象有自己的哈希值不过我们几乎不会显式地指定这个哈希值。git status 会有所变化吗并没有。????为什么呢git 需要知道最近一次 提交才能知道文件已经被提交。那么 git 是怎么做的呢它会去找 HEAD在 Windows 上查看 HEAD在 UNIX 上查看 HEADHEAD 指向 master但是 master 是什么呢我们还没有创建它呢。如同我们在前面解释的那样分支只是 提交对象 的命名引用。这时我们想要让 master 指向哈希值为 80e8ed4fb0bfc3e7ba88ec417ecf2f6e6324998f 的 提交对象。这实现起来很简单在 \refs\heads\master 创建一个文件文件内容为这个哈希值。像这样⭐ 总而言之分支 只是 .git\refs\heads 中的一个文件文件内容为该分支所指向的 提交对象 的哈希值。现在git status 和 git log 终于欣赏我们的付出了我们已经成功创建出了一个提交全程没有使用上层命令是不是很酷????与 Git 分支一起工作——背后的故事就像我们不借助 git init、git add 或 git commit 创建 仓库 和 提交 一样我们将要创建 分支在不同 分支 间来回切换整个过程也不使用上层命令git branch 或 git checkout。如果你很兴奋这是完全可以理解的。我也很兴奋 ????咱们开始吧目前我们只有一个名为 master 的分支。要创建另一个名为 test 的分支等价于执行 git branch test我需要在 .git\refs\heads 下创建一个名为 test 的文件文件的内容应该和 master 分支指向的那个 提交 的哈希值一致。如果我们使用 git log就可以看到 master 和 test 确实是指向同一个 提交我们也切换到新创建的分支吧等价于执行 git branch test。为此我们需要改变 HEAD 的指向让它指向我们的新分支通过修改 HEAD 切换到 test 分支我们可以看到git status 和 git log 都确认 HEAD 现在指向的是 test 分支活动分支。我们现在可以使用之前的命令去创建另一个文件然后将它添加到索引我们用上面的命令创建了一个名为 test.txt 的文件文件内容为 Testing。我们还创建了相应的 blob将它添加了到 索引。我们还创建了代表这个 索引 的 树对象。现在是时候创建引用这个 树对象 的 提交 了。这一次我们还应该声明这个提交的 父提交也就是之前的那次 提交。我们用 git commit-tree 命令的 -p 开关声明父节点可以看到我们刚刚创建了一个 提交还有它的 树对象 和父节点git log 会展示我们的新 提交 吗可以看到git log 并没有展示任何新的东西。为什么呢???? 还记得 git log 会跟踪 分支 查找要展示的相关提交吗它现在给我们展示了 test 和它指向的那个 提交还展示了指向同一个提交的 master。没错我们需要让 test 指向我们的新 提交。我们只需要稍微改变一下 .git\refs\heads\test 的内容成功了! ????????git log 找到 HEADHEAD 告诉它去 test 分支test 分支指向着 提交 465...5e这个提交又链接到它的父 提交 80e...8f。尽情欣赏美吧we git you。????总结本文向你介绍了 git 的内部原理我们一开始讲了基本对象——blob、树对象 和 提交对象 。我们了解到 blob 持有文件的内容树对象 是一个包含 blob 对象 和 子树对象 的目录列表提交对象 是工作目录的一个快照包含了一些像时间或提交信息这样的元数据。我们接着讨论了 分支它们不过是 提交对象 的命名引用。我们继续描述了 工作目录它是一个目录有着相应的仓库。暂存区索引 为下一个 提交对象 持有对应的 树对象而仓库就是一个 提交对象 的集合。我们阐明了这些术语与 git init、git add 和 git commit 之间的关系我们用这几条著名的命令创建新仓库、提交文件。然后我们大胆地深入 git 内部停止使用上层命令转而使用底层命令。借助 echo 和 git bash-object 这类的底层命令我们创建了 blob把它添加到 索引创建了 索引 的 树对象以及指向这个 树对象 的 提交对象。我们还创建了 分支在 分支 间来回切换。为你们中那些亲身尝试这个过程的人鼓个掌????希望你在跟着本文操作一遍之后对使用 git 过程中背后发生的事情有了更深入的理解。感谢阅读本文 如果你喜欢这篇文章你可以在 swimm.io blog 这个主题的内容。Omer Rosenbaum 是 Swimm 的首席技术官、网络培训专家、Checkpoint 安全学院的创始人和计算机网络希伯来语的作者。欢迎访问我的 YouTube 频道。附加资源git 相关的资源已经有的很多了我发现下面这些参考资料特别有用Git Internals YouTube playlist — by BriefTim Berglund’s lecture — “Git From the Bits Up”Git from the Bottom Up — by John Wiegleyas promised, docs: git for the confusedGit Internals — Git Objects — from Pro Git book, by Scott Chacon and Ben Straub原文链接https://www.freecodecamp.org/news/git-internals-objects-branches-create-repo/作者Omer Rosenbaum译者Nicholas Zhan点击 ???? 加入 freeCodeCamp Chat 中文开发者社区聊天室非营利组织 freeCodeCamp.org 自 2014 年成立以来以“帮助人们免费学习编程”为使命创建了大量免费的编程教程包括交互式课程、视频课程、文章等。我们正在帮助全球数百万人学习编程希望让世界上每个人都有机会获得免费的优质的编程教育资源成为开发者或者运用编程去解决问题。你也想成为freeCodeCamp 社区的贡献者吗欢迎点击以下文章了解✨✨freeCodeCamp 在线翻译工作坊丨学编程练英语成为开源贡献者成为 freeCodeCamp 专栏作者与世界各地的开发者分享技术知识点击“阅读原文”在 freeCodeCamp 专栏推荐阅读若川知乎高赞有哪些必看的 JS库我在阿里招前端我该怎么帮你现在还可以加模拟面试群如何拿下阿里巴巴 P6 的前端 Offer如何准备阿里P6/P7前端面试--项目经历准备篇大厂面试官常问的亮点该如何做出如何从初级到专家(P4-P7)打破成长瓶颈和有效突破若川知乎问答2年前端经验做的项目没什么技术含量怎么办末尾你好我是若川江湖人称菜如若川历时一年只写了一个学习源码整体架构系列~(点击蓝字了解我)关注若川视野回复pdf 领取优质前端书籍pdf回复1可加群长期交流学习我的博客地址https://lxchuan12.gitee.io 欢迎收藏觉得文章不错可以点个在看呀^_^另外欢迎留言交流精选前端好文伴你不断成长若川原创文章精选!可点击小提醒若川视野公众号面试、源码等文章合集在菜单栏中间【源码精选】按钮欢迎点击阅读也可以星标我的公众号便于查找
