Git 对技术领域的重要性自不必说，它几乎重新定义了我们开发软件的方式。Git的应用范围甚至延伸到了非技术领域，比如可以用来做博客写作的版本管理。我们公司的UI设计资源都是用Git来管理的。Git的社区和生态如此繁荣，它的身影无处不在，以至于我们很难想象什么工具能替代它。那么，Git 的地位真的不可撼动吗？近日 Alex Gorischek 在 Hacker Noon上发表了他的看法。看完之后顿时觉得脑洞大开，似乎看到了未来代码版本管理和协作开发的影子。
Git 已经很好了，分布式、可离线操作、分支管理非常方便快捷。但开发人员是一个从来不满足于现状的物种，只要有改进的空间和未满足的需求，工具就会不断进化。没有什么是完美的，也没有什么是一成不变的。Git 虽然如日中天，但它的第一版发布到现在也有十几年了，比第一代 iPhone 还早两年。
当然，现在说 Git 被取代还为时尚早，至少在可见的未来它不会消亡。不过现在可以畅想下 Git 的继任者会是什么样子。
我们先来回顾下 Git 的历史。Git 跟以往的版本管理工具不一样，它的工作方式是分布式的，不依赖单独的中心服务器，每个客户端都可独立工作。这简直打开了新世界的窗口，多人协作变得更自由。但这也带来了一个问题：客户端之间的数据不同步。要知道，Git 发布的同一年，微软收购了 FolderShare，从此进入多设备共享数据的文件同步时代。一年后 Google Docs 发布，两年后 Dropbox 也发布了。Git 诞生的环境就是这样。
技术在持续演进，计算设备互联的方式发生了巨大的改变。数字通信变得更快、更丰富，也更可靠。设备不仅能独立工作，也能有效地实时协同工作。计算机之间的信息保持独立，这种想法正在慢慢消亡。至此，后 Git 时代的版本控制技术思想开始浮出水面。
展望
Git 诞生之初解决的是十多年前的问题，那对于它的继任者，我们对其有哪些期待呢？作者认为至少应该包含以下几个特性：
默认同步
Git 认为本地分支和远程分支的关联没那么重要。而且这种关联也只是一种指向关系，并不是真正的互相联通。除非你手动拉取远程更新，否则本地数据永远是旧的——尽管客户端之间在网络上是互通的。这在当今的技术环境下，简直不可接受。如果有人在跟我协作，我希望随时得到最新进展，而不是要我去主动询问。
持续往前
Git 的分支模型非常轻量，在做一些尝试性的改动时非常方便，不用担心把主线搞得一团糟。你可以在自己的分支上提交改动，确保没问题后再合并回主分支。只要提交了，就会保留记录。但有时候还是会丢数据，比如在你还没保存时突然断电。都这个年代了，我希望软件再也不会弄丢数据，不管我有没有保存。我的工作在不停往前推进，软件也应该跟上脚步。
社交元素
Git 提交可以显示谁在什么时间做了什么，但这只局限于历史记录。当我们在自己的机器上各自工作时，没人知道其他人在做什么，即便是我们在编辑同一个文件。现在，如果我跟其他人在编辑同一个文件，我想让编辑器精确地告诉我别人在编辑文件的哪个位置。
Party
大招来了。以上讨论的特性完全不同于 Git。它不只是一个源码控制系统，一个互联的、持续往前的、社交化的系统，有点像什么？作者把它称作 Party。按照这个设想，未来的软件源码控制系统会是这个样子：
$ party start myhouse @friend1 @friend2
这条命令的作用就是启动一个名叫 myhouse的party，并邀请了我的两个朋友。在Git 里就相当于创建一个代码仓库，同时通知用户 friend1 和 friend2。
$ party talk app.js
我们开始互相交谈（talk），也就是开始逻辑功能的开发。在我们输入的时候，我们可以实时地看到其他人的输入内容和插入的位置。在 Git 里我们做的就是保存、提交、拉取、推送，但是这里不用这些操作。每个人都在一起“开party”。
$ party punchline "Basic logic works"
最终，我们的改动稳定了。尽管到目前为止我们的所有操作都会被自动保存，但是有些时间点的工作还是有必要备注一下。为此，我们建立一个 punchline，以标注一个感兴趣的点。相当于 Git 的 tag。
$ party clique refactoring @friend1
最终，用户friend1和我决定对逻辑做一个有风险的改动，但我们不希望干扰到friend2的工作。于是我创建了一个叫 refactoring的clique，并邀请了 friend1。虽然 friend2也可以实时地看到我们在refactoring clique上的所有改动，但只有 friend1有编辑权限。由于clique是用来完成互不干扰的工作的，有点像 Git 里的分支概念。
$ party listen center
friend2依然在 party 的中心（center）工作，相当于 Git 的 master 分支。默认情况下，当我创建refactoring clique后，friend1 和我就不再关注 friend2的工作进展了，因为我们也要专注自己的工作。但是做了这么多重大的改动，我们还是想追上 friend2的进度，好让我们解决可能出现的冲突。执行 listen center后，我们就可以持续跟踪 friend2的工作了。相当于 Git 里的获取远程更新，然后合并到本地分支。
$ party join center
在我们合并和解决冲突、一切正常后，我们再次回到party，从此以后 friend2也能看到我们的改动了。相当于 Git 里的 push到远程master，只不过 friend2无需手动获取远程更新的操作。
$ party rewind 2min
这时候，friend2做了一些操作，也检查了我们的改动。大部分是没问题的，但是发现我们删了某个他要用到的东西。于是 friend2执行了一个操作，回到（rewind）两分钟前的状态，找回我们删除的代码。
$ party bring app.js:112–114
他们找到了，要找回第 112 行到第114行的代码，于是他们把这些代码还原（bring）到当前 party的状态里。
$ party punchline "Full logic implemented"
一切妥当后，我们又建立了一个 punchline，标志着我们到了一个新的状态点。
$ party replay start
在工作收尾之前，我们重播（replay）了一下我们的工作——当然，是快进播放的。因为 party 保存了所有操作，所以可以从头到尾重新播放一遍。
$ party end
大功告成，我们可以执行 end命令了，工作告一段落，洗洗睡。
后记
怎么样，开完这个 party 感觉如何？不得不说，作者很有想象力。这个构想的核心其实就是实时同步，永不掉线。当然，这只是作者的个人想象，至于 Git 的替代者会不会是这个样子，还有待观察。其实已经有类似的协同工具了，曾经参加了一个远程技术面试，面试官让我在线写代码，用的编辑器就是两端实时同步的，可以看到对方的输入。我相信假以时日，这种技术一定会普及。
网友评论