本文来自Anil Dash，他是Fog Creek Software首席执行官，也是@Glitch＆Manuscript的制作人。
最近，微软收购了GitHub，这对于开发人员来说可能是个好消息。但是，基于我们所见的Glitch的大量使用以及我们开发版本控制工具十多年的经验，很明显许多开发人员也认为是时候探索新的方法了。所以，我们希望在源码社区这个里程碑的节点阐明开发新版社交编码系统的愿景。
GitHub + Microsoft = Good
简单地说，微软收购GitHub对开发者来说可能是个好消息。 这在过去似乎不太可信，但没有什么能比这一充满野心的并购更能证明微软在Satya Nadella的领导下正重振雄风了。
老一辈的开发者还能记得微软经常被描述为邪恶帝国的时代，但是微软接受开源和非Windows平台的举措现在看来似乎是真诚且持久的，作为开发者，我们很高兴能看到这样的繁荣发展现状。
同样，GitHub已成为一个不可或缺的开发者平台，其早在10年前就于第一次大规模社交编码浪潮中脱颖而出。而微软强有力的领导对GitHub只会是个好消息，特别是对那些主要使用微软平台的开发者来说。
但如果说我们还有什么顾虑的话，那就是在过去的十年里，社交编码领域并没有出现质的飞跃。
近些年来，我们根本没有看到在编程人员合作的方式上有足够的创新，而且由于每个开发人员现在都会考虑到诸如版本控制这类问题，所以在这里，我们想试图勾画出未来十年社交编码的发展蓝图。
很多人会考虑备份他们的GitHub代码来以防万一，我想你应该利用这个机会来看看Glitch，想想现在是否应该重新全盘考虑版本控制的传统观点。
版本控制的十年风霜
首先，让我们来明确一下背景。许多开发人员可能不知道，在Fog Creek我们拥有开发分布式版本控制系统的深厚背景。
差不多十年前，我们推出了Kiln（现为集成式的版本控制系统Manuscript），为团队合作编码提供了许多开创性的功能。我们的方式是做好项目管理并增加版本控制，这使我们学到了很多关于人们如何一起写好代码的经验。
相关链接：https://www.manuscript.com
我们认识到，典型的提交commit-变更请求和pull request-合并merge的工作流程中一些部分仍然是复杂得令人难以理解的。
根据我们所了解的情况以及我们从开发人员社区获悉的信息，我们开始重新思考在版本控制中，那些每个人都认为是理所当然的有关工作流程和合作的一些假设。
今年早些时候，我们重新构想了版本控制，推出了Glitch的测试版——Glitch Rewind。 Glitch Rewind底层使用了常规的git，但在用户体验上有了一个巨大的飞跃。
相关链接：
https://medium.com/glitch/reinventing-version-control-with-glitch-rewind-914c350da442
Glitch中回滚提交的代码
Glitch Rewind与社交编码重塑！
Glitch做了一些之前没有人做过的东西：
当你在后台运行git repo时，Glitch会自动提交你的修改内容——即使是多人同时编辑同一个文件也是如此。试想如果这个提交过程与在Google Docs中多方同时编辑一样简单，那么即使是非开发人员也可以马上执行提交的操作。
Glitch Rewind允许你只需像往回拉视频的进度条一样移回一个滑块即可撤回已提交的代码更改。如果你想从原来版本开始工作，只需点击播放并继续工作即可。
当你沿着时间轴滑动时，就可以看到改动内容的实时预览。这样，任何会用YouTube看视频的人现在都能够撤回git的提交。即使你知道晦涩难懂的git命令行选项，大多数情况下你都会更喜欢这种方式。
在Glitch的底层，全都使用了git。 这意味着你的工具，进程，工作流程，集成和自动化可以无缝链接到Glitch上的项目中。
我们正在创建Glitch的“混音remix”功能，该功能可以让你克隆现场运行的代码，并且合并“混音”里的代码变更，这个过程跟现在的撤回提交一样简单。
相关链接：
https://www.youtube.com/watch?v=sedZVNakpto
Glitch的项目页面和用户配置文件是Glitch所维护的开源项目。 这意味着如果你希望Glitch上的社区功能和社交网络功能得到发展，你可以自行参与开发，并因此成为充满活力的新社区的一份子。
相关链接：
https://medium.com/glitch/your-own-little-space-on-glitch-865b5cfebb7f
用于代码协作的业务工具，应该能够无缝连接到更大型的网络，在那里更多人可以共同编码。Glitch for Teams为用户提供了Glitch的所有有关协同工作的功能，而且无需经历复杂的企业采购流程。
相关链接：https://glitch.com/forteams
Glitch也正致力于成为一个更好、更具包容性的社区，其中包括友好和平易近人的设计，用以管理行为准则和授权的内置工具，以及我们独特的Glitch帮助功能——如果你在使用Glitch上遇到困难，可以直接举手求助！
相关链接：
https://medium.com/glitch/just-raise-your-hand-how-glitch-helps-aa6564cb1685
我们还将推出其他的新功能，但耳听为虚，眼见为实，你只有切实用到它们，才能真正理解其魅力。
其他工具
你们之间的怀疑者一定在想：“好吧，Glitch虽然很棒，但是我们现在还有GitLab或BitBucket，为什么我们要做出更换呢？”
的确，这些都是很棒的工具！但它们和那些前一代的工具一样，包括我们自己之前设计的工具，都是基于相同的工作流程做出了基本假设。
我们现在认为那些假设还可以更上一层楼。 以下是我们想做的改进：
社交编码的基本模块应该是一个应用程序，而不是一个提交commit指令。项目的默认状态应该是一个功能性的运行程序、网站或机器人，而不是一堆你还得搞清楚该怎么运行的代码。
由于任何更改都可以自动撤销，每个人都可以大胆地对代码进行更改并尝试新事物，这样更能激发人们的创造力。
团队中的每个成员都应该能够提交代码更改，即使他们以前没有写过代码，不知道什么是git，或者甚至没有听说过git。
就连有经验的开发人员也不需要必须记住晦涩的命令行，以完成如像撤回提交commit这样简单的任务。很少有开发人员对自己的git技能十分自信，然而几乎所有人都必须要使用它。
这种不匹配加剧了人们对写代码的紧张感，并使得编程缺少了包容性和乐趣。
我们展现代码的社交网络应该像我们可以找到好看的照片、视频或好听的音乐网站一样令人愉快并且富有创意。
程序员用来分享他们作品的社区平台应该是开源的，这样我们就可以实现对程序的协同改进。源码社区背后的商业模式应该是透明和可持续的，这样才足以赢得我们的信任。更进一步，源码社区背后的公司也应该是可信的，并持有可追溯的记录。
我们还有更多内容——实际上，我们编写了一个关于Glitch背后原理的完整列表提供给感兴趣的读者。
不过我们想要表达的很简单：GitHub在过去的十年中彻底改变了写代码的方式，我们都应该为微软和GitHub庆祝这一里程碑。 这是对一个重要思想的认可：我们不是一个人在写代码。
相关链接：
https://medium.com/glitch/what-is-glitch-90cd75e40277
同时，这也是我们作为程序员和创作者扪心自问的好机会：怎样才能提高我们自己的眼界，真正将社区和编程文化融入我们共同创造的核心，而不是仅仅在写代码的时候进行必须的社交。
这就是关于Glitch的全部内容。我们十分期待你的创造！
