git有什么问题？ 概念设计分析（2016）

git有什么问题？概念设计分析de rossi＆amp;杰克逊向前！ 2013年

我们上周结束了谈论如何在软件设计中找到良好的概念/抽象，以及什么好的模块化看起来像。今天的纸张跳跃40多年来看看现代背景下的一些问题，这个博客的许多读者都会非常熟悉：Git。非常感谢Glyn Normyton的推荐。

最好的软件设计师已经知道发现或发明正确的概念是多么重要，以及这些概念中的粗糙边缘以及它们的关系将导致交付的产品中的粗糙边缘...尽管这几乎没有尝试研究设计概念及其对软件的影响。

作者选择使用Git来探讨设计中概念的作用 - 它广为人知和使用，并且同时知道令人困惑，难以学习。是刚刚在表面上的可用性问题，在命令的表达式中，或者它们更深入？

我们相信Git的可用性问题更深，只能通过更基本的重新加工来解决潜在的概念。这并不是说这种重新加工不能以轻质的方式实现。实际上，我们自己的重新加工隐藏了一个像素后面的Git就像这些其他工具一样。然而，差异是，我们愿意完全重新考虑给用户呈现的核心概念。

重新加工的结果是在一个名为Gittress的工具中提供的，我安装在我的系统上进行几天时间。 （注意：如果使用GIT插件使用OH-MY-ZSH，那么这为您需要unalias需要的gl定义了一个别名）。截至本文（2013年），Gittress才刚刚开始作为一个项目，但它仍然持续到今日，明天我们将看看2016纸张，使故事迄今为止。

作者对该设计至关重要的概念，以了解系统的工作，因此在系统的外部界面以及实施中将显而易见。

在我们看来，概念具有心理内容;它们对应于用户如何考虑应用程序。因此，我们的概念设计是关于用户可见行为的设计，而不是内部软件结构的设计，并且我们使用术语“概念模型”来专注于概念而不是行为细节。

Fred Brooks将概念完整性描述为“系统设计中最重要的考虑”，并提供了三个原则：

所有权 - 产品应该只有对其目的至关重要的功能（概念），也不是

作者添加了第四个：一致性 - 例如，措施以类似的方式行事，而不管他们所呈现的参数或调用它们的州。

此论文然后按如下方式进行：首先，作者为今天的Git构建了一个概念模型，然后他们展示了概念模型如何导致Git用户所经历的许多困难。最后，他们介绍了无缝的，这是基于更简单的概念模型。

理想情况下，概念设计的描述应该独立于实现;它应该很容易理解;它应该精确地支持客观分析;它应该重量轻，向设计空间中的不同小便探来展示一点惯性。

作者的选择工具是一种概念 - 关系图。这是他们为git构建的模型：

解释它是一种复杂的 - 这真的是作者的观点。虽然通过他们的描述阅读确实提醒我一些git中的一些微妙之处。正如我想象很多人所做的那样，我已经进化了自己的基本方式，使用了Git，并尽量不要迷失太远。 Git概念模型的大部分复杂性来自各种状态和角色可以在/播放中的各种状态和角色。可以跟踪文件或未触发文件，标记为“假设不变”，忽略，暂存，粘附等。区分文件的工作版本和文件的暂存版本是混淆的常见原因。例如，如果我遵循序列：

更新：在原始帖子中，最后一行错误地读取“git commit foo.rb”，它将提交foo.rb的工作版本。

然后，所致的foo.rb的版本是as add命令的时间的版本（因为它将foo.rb复制到暂存，并且提交从暂停中的副本工作）。以下是一些关键git命令以及它们如何与暂存和工作副本的概念相关：

git add _f_使文件f的工作版本要复制到暂存，如果文件未经触发，则会跟踪文件。

git重置将文件恢复为先前状态。例如。文件F的Git Reset Head F删除其与暂存版本的关联，如果先前在暂存之前未经触发，则不会触及，并且如果先前是假设的不变文件，则跟踪其跟踪。 （作者不会模拟在历史上工作的重置的变化）。

git checkout _f_通过替换有暂存版本的工作版本来恢复本地更改f如果有一个，或者与提交版本否则。相同的命令也用于切换分支...

git stash拍摄每个文件的工作版本（具有修改），并在新的藏品中使其成为困难的版本......

我们所描述的概念模型的非常复杂性表明，我们在Git设计中是不对的。版本控制系统是否真的需要这么多，并且如此复杂的概念？在我们甚至考虑同步多个存储库之前？

文件的分阶段和工作版本以复杂的方式耦合，并且可能期望仅影响一个人的Git命令也会影响另一个。遇到麻烦的一种方法是添加文件，然后在提交之前继续工作。如果你决定用重置命令撤消提交，那么取决于参数不仅仅是暂存的版本，还要替换WIL的工作版本（自提交以来擦除后续工作）。

为什么会发生这种情况：上演和工作版本的概念不是正交的。许多主要旨在修改两个修改另一个的命令也修改了另一个。更糟糕的是，是否发生这些纹波效果取决于哪些参数呈现给命令。

提交文件在Git中是非微不足道的，大部分是因为暂存概念的侵入。

Git Commit命令从暂存中占用版本，而不是工作版本。 Git Commit -A变型几乎绕过此变体（它在提交之前执行一个隐式添加），但它不会选择未触发的文件，只能用于使用修改的所有跟踪文件。简而言之，它太钝了工具。

一些git爱好者对舞台概念的价值进行了论据，但对于大多数用户提供非必需功能，它的存在使得使用的使用使得大大复杂化。

切换分支......以及存在未提交的变化时可能发生的痛苦冲突。

分支机构旨在支持独立的发展线。开发线包括文件的工作版本和已提交版本。然而，在GIT的概念模型中，只有所承诺的版本由分支组织;虽然有可能的文件的潜在多个忠诚版本（每个分支一个），但只能有一个工作版本。因此缺乏一般性，分支特征仅在一个区域中仅可用，而不是另一个区域。

Gittress是由作者维护的OSS项目，首先清理概念模型，并将用户界面放在上面。

git和gittress之间的关键差异是：（a）消除假定的不变文件的概念，以及未经触发的文件的概念来归存它; （b）消除分阶段版本; （c）消除藏匿件和藏品的概念; （d）分支机构的工作版本索引。在Gittress中切换分支相当于始终在切换到Git中的不同分支之前始终创建存储功能（更精确地执行Git Stash -All），然后在用户切换回原始分支时检索此缺陷。因此，就好像有多个工作目录（每个分支一个）或换句话说，可以将其视为可能通过分支名称B可访问的若干工作版本的文件（注册为工作[b]）图表）。这意味着用户可以自由地从分支切换到分支，而无需删除或提交未完成的更改。我们认为这使得这一生命达到一个分支是一个独立的发展线。

如果不是所有上述内容对你有意义，那么Gitress可能是一个不错的选择！ Gitress的概念模型如下所示：

本文发布了这篇文章，只有非常早期的评估研究已经完成了无巨头的模型，但是“消除分期区域的消除被热情地接受了复杂性的主要减少。”

这是一个有趣的项目，因为它与我们每天使用的工具涉及一次。但除了GIT的细节之外，我的一个外卖器是提醒的是，良好的可用性深深植根于概念设计中，远远距离演示层。

大多数可用性专家似乎都认识到产品概念模型的重要性，以及用户心理模型以及产品偏离的正确概念模型所产生的问题。

最后一点的经典工作当然是唐纳德诺曼的“日常事徒的设计”。