Git之后我们要去哪里？

让我们开始这场派对

前言

Git重新定义了我们编写软件的方式。 这是一项独创的技术，其社区和生态系统异常活跃。 它变得无处不在，很难想象会有什么跟随它。 但是，现在这种思路听起来应该是可疑的：人们对马和马车，煤气灯和座机电话说的都是同样的话。 从根本上说，人类是一个不停创新的物种，技术并没有停滞不前。 因此，尽管Git可能仍感觉新鲜（也许是由于周围蓬勃发展的原因），但值得记住的是，第一个版本比原始iPhone早两年发布。 至少可以说，此后发生了很多变化。

需要明确的是，这与Git即将消亡无关。 我喜欢Git，我认为它还没有达到极限，而且我认为它不会很快消失。 在可预见的将来，它可能会继续增长，并且可能永远不会完全消失。 也许有一天，在停顿之后，甚至会有Git Renaissance，让人想起黑胶唱片的回归 。 但是Git之后会发生一些事情，并且似乎该开始猜测可能是什么了。

让我们先回到过去。 Git对分布式工作流的拥护反映了总体上正在进行的分散计算。 电源不再仅仅依靠中央服务器，而客户端仅扮演从属，从属角色。 端点可以发挥自己的重量，结果是一个新的移动，新的自由世界。 这是真正的解放！

但是，出现了新问题：最痛苦的是，跨设备的数据不同步或完全不可用。 如果很难记住确切的样子，请考虑Git是在微软购买FolderShare的同一年发布的，从而进入了“文件同步和远程访问技术的新兴空间，可帮助客户跨多个设备访问信息” 。 Google Docs诞生了一年，而Dropbox诞生了两年。 这就是Git诞生的世界。

不用说，这不再是我们生活的世界。 技术领域继续发生变化，所有这些计算设备相互连接的方式发生了特别大的变化。 随着数字通信变得更快，更丰富，更可靠，不仅每个设备都可以处理自己的位问题，而且所有设备都可以实时有效地协同工作。 一台计算机上的信息不同于另一台计算机上的信息的想法开始了它缓慢而不可避免的消亡。 这为我们提供了第一个暗示，即版本控制在Git之后进行。

预测

由于Git的发展反映了十年前的计算运动，我们可能会怀疑其继任者会反映我们今天所经历的变革。 因此，我们可能希望看到其中一些：

默认连接

Git使将计算机上的分支与远程设备上的分支相关联变得轻而易举。 但是默认情况下，这些关联只是指针，而不是连接。 除非您手动获取更新，或者使用定期为您执行更新的Git客户端，否则即使所有设备都已联网，计算机上的数据也会陈旧。 对于任何现代技术用户来说，这应该已经过时了。 如果有人在做我同样的事情，我希望被告知而不必问。

一直在移动

Git的轻量级分支模型使您可以轻松地快速撤离并尝试一些更改，而不必担心将事情弄糟。 您可以在自己的分支中提交更改，以确保它们不会丢失，并且只有在情况良好时才将其合并。 但是仍然有很多失去工作的机会：如果力量因未保存的更改而消失，或者如果您决定需要在两次提交之间恢复到某种状态，那么您很可能会走运。 这些天来，我相信软件永远不会丢失我的工作，无论我是否想保存，无论何时。 我的工作一直在进行中，我希望我的软件能与时俱进。

社会存在

Git的提交模型使我知道谁在何时何地进行了工作，但仅是回想起来。 当我们在各自的计算机上进行工作时，即使我们在同一个文件中工作，我们也不知道彼此在做什么。 如今，如果我要与其他人同时编辑文件，则希望编辑器告诉我-并准确告诉我另一个人在文件中的位置。 GitHub的巨大成功证明了在源代码控制之上分层社交工作流的好处，但这是我们开始融入这种社交性的时候了。

派对

这些方面描述的东西与Git完全不同。 不仅仅是源代码管理管理系统，它还具有连接，运动和社交的功能，就像……一个聚会。 因此，让我们开始这个聚会。 接下来是对软件源控制的未来的假设。

$ party start myhouse @friend1 @friend2

要得到的东西去，我们start一个party叫myhouse并邀请两位朋友。 这将在我的机器和默认的中央服务器上设置等效的Git存储库，并将通知发送到friend1和friend2 。

$ party talk app.js

我们开始互相talk以研究一些核心逻辑。 在编辑时，我们都可以实时查看彼此的击键和插入点。 通常，这是我们要保存，提交，拉入和推入Git的地方-但这里什么都没有发生。 每个人都在一起聚会。

$ party punchline "Basic logic works"

最终，我们达到了一个稳定点。 即使我们到目前为止已采取的每项行动都已自动记住，但时间轴中的某些点肯定比其他地方值得记住。 为此，我们呼出一个punchline ，它代表一个感兴趣的时间点。 这些是将来方便使用的参考，类似于Git中的标签。

$ party clique refactoring @friend1

最终，我和friend1决定我们需要对逻辑进行一些冒险的更改，并且我们宁愿不打扰friend2的工作。 我创建了一个名为“ refactoring的clique并邀请friend1。 尽管friend2可以实时查看重构派系中发生的所有事件，但仅邀请friend1进行编辑。 因为集团用来隔离工作集，所以它们类似于Git中的主题分支。

$ party listen center

Friend2仍在聚会的center工作，相当于Git中的master分支。 默认情况下，当我创建重构集团时，friend1和我停止看到friend2正在做的任何工作，这使我们可以专注于自己的工作。 但是，在进行了最重要的更改之后，我们希望跟上friend2所做的一切，以便我们解决所有冲突的更改。 我们listen了聚会的中心，并立即跟上了friend2的工作。 这类似于获取远程提交并在Git中本地合并它们。

$ party join center

一旦解决了一些合并冲突，并使一切都处于良好状态，我们就再次join了聚会的中心，这时friend2看到了我们的工作。 这对应于将工作推回到Git中的远程主服务器，除了friend2然后不采取手动步骤来获取那些更改。

$ party rewind 2min

至此，friend2完成了几件事，然后浏览了我们的工作。 我们所做的大多数事情都还不错，但事实证明，我们删除了他们计划使用的内容。 因此，friend2决定将聚会rewind几分钟，以查找我们删除的代码。

$ party bring app.js:112–114

他们识别出他们想要112至114号线， bring这些线带回到聚会中的当前位置。

$ party punchline "Full logic implemented"

处理完之后，我们再标记另一个打孔线以指示我们已达到的状态。

$ party replay start

在结束之前，我们从头开始replay我们的工作-当然可以加快速度。 由于聚会存储了我们采取的所有行动，因此自开始以来它就可以回放我们的活动。

$ party end

一切看起来都很不错，因此我们end了编辑会话并将其称为“夜晚”。

后记

Git的继任者可能很快就会来临，也可能不会来临。 它可能看起来也可能不像我在这里描述的那样。 它可能会或可能不会像Git一样最终席卷整个世界。 但是为什么要等待找出答案？ 必须有人实现它-会是你吗？ 如果是这样，请务必邀请我参加聚会。

From: https://hackernoon.com/where-do-we-go-after-git-d4d40d8303ce