[1597] Git

Title Text:If that doesn’t fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of ‘It’s really pretty simple, just think of branches as…’ and eventually you’ll learn the commands that will fix everything.<

Origin:https://xkcd.com/1597/

https://www.explainxkcd.com/wiki/index.php/1597:_Git

GIT

如果沒用的話,打開 git.txt ,裡面那支電話可以找到我一個朋友他會用 GIT。他會先跟你講幾分鐘的「這很簡單,你就把 branch 想成是….」,之後他就會告訴你一段指令,那段指令能把東西修好。

https://xkcd.tw/1597

这是Git [编辑]

Git是一个版本控制系统,用于管理数百万个软件项目中的代码。它非常强大,是使用分布式版本控制模型(“漂亮的图形理论树模型”)的第一批广泛采用的工具之一,这意味着没有单一的中央代码库。相反,用户来回共享代码以同步其存储库,每个项目都需要定义用于管理变更流程到稳定软件产品的流程和过程。

我们如何使用它?[编辑]

虽然非常强大,但Git的命令行很难学习和掌握。已经编写了数十篇博客文章和网站(参见[1],[2]),甚至书籍([3],[4]),以帮助用户了解这种复杂性。

在常见情况下使用Git的难度与在教程式情境中使用它的明显简单性相矛盾。例如,提交和共享更改是相当简单的,但是如果没有对相当大且复杂的概念模型的充分理解,从诸如意外提交,推送或不良合并等情况中恢复是很困难的。例如,Stack Overflow上排名前五的最高投票问题中有三个是关于如何执行相对简单的任务的问题:撤消上次提交,更改最后一次提交消息以及删除远程分支。

因此,这部漫画探讨了Git架构的理想化观点与其实际典型用法之间的区别。 Git的教程倾向于在他们的示例中使用简单的系统,并且只处理最基本的命令才能开始,这可能会产生误导性的印象,即Git可以在没有广泛研究的情况下有效使用。

由于这个问题,Git的命令与其他版本控制系统中的类似命令的命名不同,许多用户(包括Cueball)无法在基本命令之外使用它,并且可能会尝试通过将代码保存在外部来避免问题Git,下载更新的副本,然后将他们的更改重新应用到新副本,而不是尝试理解和使用Git中存在的功能来完成此任务。

记住这些shell命令[编辑]

Cueball建议“只记住这些shell命令并输入它们以进行同步”。他可能指的是一系列命令,例如:

   git pull

   现在已收到#远程更改,因此请处理您的文件

   git add file.txt

   git commit -m“添加了一些文字”

   git push

如果你收到错误… [编辑]

只要项目的每个贡献者都遵循这些原则,这可能需要一段时间。但许多情况可能会导致“错误”:

 合并冲突(两个人编辑同一文件的同一部分)

 未更改的更改(另一个人在您之前提交了更改,因此您需要首先合并其更改)

 试图从意外合并等情况中恢复,并使情况变得更糟。

在合并冲突等情况下,Git会显示错误消息,例如:

   CONFLICT(修改/删除):在HEAD中删除README.md并在branch-b中修改。 README.md的版本branch-b留在树中。

   #自动合并失败;修复冲突,然后提交结果。

将你的工作保存在其他地方……

虽然Git专家当然可以处理这种情况,但Cueball提出的补救措施是“将您的工作保存在其他地方,删除项目并下载新的副本”。也就是说,要将文件复制到其本地存储库的工作目录中,请删除整个结构,然后再次克隆远程存储库(并隐式地,再次复制已保存的工作):

#在别处复制文件

mkdir /tmp /myproject

cp * /tmp /myproject

cd ..

#删除项目

rm -rf myproject

#下载一份新的副本

git clone https://github.com/myorg/myproject

cd myproject

#复制已保存的工作

cp /tmp /myproject /*。

放弃旧项目可能意味着失去一些工作,但可能比试图挽救局势更快,并提供更可预测的结果。将此方法应用于单纯的合并冲突问题可能会延长问题,因为合并冲突可能仍然存在。

标题文字[编辑]

标题文本提出了一种解决Git复杂性的另一种方法,它反映了常见的做法:了解一位可以在任何情况下提供帮助的“Git专家”。这些专家因为抒情地嘲笑Git的优势而臭名昭着,所以可能有必要首先让他们热情地絮絮叨叨地赢得他们的青睐。他们希望最终能够提供所需的确切命令。实际上,问答应用网站Stack Overflow经常用于此目的。

它甚至可能是对臭名昭着的推文的一个参考“一旦你得到基本的想法,即分支是同胚的endofunctors映射希尔伯特空间的子流形,Git变得更容易”,这里已经讨论过,但是否存在有意义的解释是不确定的。将“理解Git”的人的电话号码放入这样的文件中是幽默的,因为:

软件团队通常会使用电子通信手段

不需要通过电话向团队成员解释Git,因为在线提供了大量的帮助,并且

在许多团队成员需要电话支持以避免或解决基本Git问题的情况下,这对于在文件中给出电话号码的人来说会非常分散注意力。

TL; DR [编辑]

简而言之:程序员使用版本控制系统来跟踪代码的变化。如果你已经知道另一个,那么这些版本控制系统中的大多数都非常相似且易于学习。 Git是一个基于完全不同原则的版本控制系统,大多数程序员发现很难围绕它进行思考(尽管Git还提供了许多与标准版本控制系统相比的非常重要的好处,这就是使用它的原因)。 Cueball是那些程序员之一。

Leave a Reply

Your email address will not be published. Required fields are marked *

Categories