源码管理--llorch的Visual Studio基本教程（四）

通用的演示样例说明：

• 本系列博客仅仅讨论工具的基础，不讨论不论什么语言。
  • 甚至不讨论快捷键:-)
  • 能够用鼠标就完毕本教程
• IDE默认指代的是Visual Studio 2013 Community Edition。

  本系列文章的结尾，你能够熟练地使用它敲代码。

• 将Visual Studio启动后的默认布局状态称为主窗体,主窗体标题栏中显示的项目名称不必要。

• 在日常口语和Windows资源管理器的基础上定义了几个描写叙述菜单操作的符号：[]、{}、/、>>、=、(,)。
• 检查一个设置项的表示方法为:
  • [窗体名称]/{菜单名称}/{子菜单名称}/{设置项项名称}=设置项的值
• 比如默认的Debug配置:
  • [主窗体]/{解决方式配置管理器}=Debug
• 检查多个设置项时，依照单个设置项的方式，逐一写出
• 检查一个设置项有多个值的时候，用括号包含并用内部的逗号分隔，如:
  • [解决方式资源管理器]/{项目名称}/{引用}=(System,System.Core,System.Data,System.Xml)
• 运行一个左键单击序列，就是将最后的检查项换成”/”。比如退出IDE:
  • [主窗体]/{文件}/{退出}/
• 右键菜单的连接符号为>>。比如刷新Windows桌面:
  • [桌面]>>{刷新}/
• 弹出窗体中的设置项的表示与上类似
• MDI子窗体中设置项的表示与上类似，注意到在Visual Studio中，MDI子窗体的名称在它的左上角或者可能自己主动吸附到主窗体的四周
• 标题栏和状态栏作为菜单的推广。适用于上述表示方法
• 缺陷说明
  • 欢迎反馈，mailto:cqwd2010@qq.com
  • 作者的首选语言是C#
  • 作者是软狗
  • 作者的IDE没装中文语言包，所以有的名词翻译得不准确:-(
  • 因为还没有厘清相关的证书问题，版权保留
  • 系列文章没有提出或解决新的问题。目的仅仅是科普

正文

这一篇博客讨论编程工作内在的目的性，也就是源码管理。所谓源码管理只针对能够工作的最稳定的代码进行管理。笨代码和聪明代码是代码片段或编程缓存，而非协作中的源码管理。

源码和代码片段

把自己写过的全部代码保存起来，是非常好的想法。

把自己能用的代码保存起来，以便随时再用。这个想法对开发人员来说，可能会更好一点。由于后者更能让开发人员集中注意力于设计。常见的追踪文件历史记录的方式是版本号控制，也就是通常所说的源码管理。可是通常所说的源码管理听起来更像是“字符历史记录”。

一片代码，只从它与程序总体的关系来说，能够概略地分为两类，一类是立时可用的，还有一类是“我还要修复一下”的。前一种叫做“源码”，而后一种只能叫做“片段(snippets?)”。这个差别对开发者的提示在于。从实践上说，编程就是环绕release的体力劳动工作。

漂亮的代码和稳定的代码

漂亮的代码一般会用一些幽密的手法来实现一个比較bigger的功能。

稳定的代码则不然。比方求两个集合的差集的情况而言。漂亮的代码可能会在一个循环里面写大量的语句，而稳定的代码则可能写成三五个顺序运行的循环。

那么。究竟是漂亮的代码好还是稳定的代码好呢？

实际上我们会发现，我们的确会观望漂亮的代码，但我们赖以发挥作用的还是稳定的版本号。代码的稳定的版本号一般会更加easy调试、更加简约循环的内容。我们终于会在保持稳定的基础上进行性能的调整。

针对更强的目的性实施源码管理

至少一个版本号已经在执行。不管是在測试中还是在原型中。

在此之外谈源码管理就是搞学术研究。

源码管理的概念应该比项目的层级要高。

这是由于。就编程的目的而言。一个项目仅仅是达成方案目的的一个子部分。

一旦将源码管理针对强的目的来进行，那么源码管理所维护的重心也就自然而然地落到了工作的完毕时态。

用IDE内建的Git进行源码管理

在Visual Studio中贯穿着强目的性的源码管理的设计哲学（即使能够非常easy地滥用）。这表如今，在不打开不论什么解决方式的情况下。[团队资源管理器]仍是可用的。

然后在分支的合并上有一些自己主动的简化。

因为实践所限，llorch眼下还没实用过Team Foudation Server。因此本篇的内容就以Visual Studio中的Git支持来演示样例性地说明了。因为Visual Studio 2013内建的Git功能并不完备，有的网友习惯自己组装其它的Git插件。llorch的教程主要想给新手们提供一点參考，所以，这里就如果使用第三方插件的是“高级用户”了。

配置Visual Studio中的Git

[主窗体]/{视图}/{团队资源管理器}/。打开[团队资源管理器]子窗体，这是源码管理的主要操作窗体。

[团队资源管理器]/{下拉列表}=设置/{Git设置}/，对影响Visual Studio全局的身份信息、缓存文件夹进行设置。

克隆网上的Git仓库

[团队资源管理器]/{下拉列表}=项目/{连接到团队项目}/{克隆}/，填入Git仓库地址和本地缓存文件夹就開始克隆了。

内建的Git工具仅仅能和https协议的公布URL良好协作。不支持ssh的版本号，而支持Windows凭据登录的方式。

假设已经克隆过了，这里的菜单会自己主动切换成拉取。拉取的时最好注意一下分支提交的情况，以免覆盖掉实用的工作。llorch试了几次。好像仅仅要有分支没有提交，这里的拉取就会变灰色。

[团队资源管理器]/{下拉列表}=项目/{本地Git存储库}/{库N}//，双击(//)列出的不论什么一个本地存储的库，会跳转到[团队资源管理器-主页]子窗体，在[团队资源管理器-主页]/{解决方式}栏目中能够选择操作分支或打开解决方式。

一旦打开了解决方式。则手动切换到[解决方式资源管理器]開始编码。（这是一个用户体验上的BUG。没有自己主动切换过去，能够通过取消团队资源管理器的停靠来改善。）

提交更改到本地存储库

[解决方式资源管理器]/{解决方式}>>{提交}/，在当中填入提交消息后就能够提交。

提交更改到远程存储库

Visual Studio 2013 Community Edition内建的Git工具仅支持通过https协议向远程存储库提交。

不管怎样，为了提高通用性，应该先克隆，改动之后。再提交。

[团队资源管理器]/{下拉列表}=未同步提交/，假设项目是克隆而来的。那么直接点击{传出提交}/{推送}，能够利用克隆步骤中保存的凭据进行一次提交。假设不是，那么这里须要输入一次凭据。

将全新的方案纳入本地Git存储库

[解决方式资源管理器]/{解决方式}>>{将解决方式加入到源码管理}/，呼出[选择源码管理]窗体，选择当中的{Git}。

[解决方式资源管理器]/{解决方式}>>{提交}/，这里会提交到本地缓存。

提交更改到远程存储库相同是适用的。

分支管理

[团队资源管理器]/{下拉列表}=分支/，在这个界面中Visual Studio把分支的管理简化到了极致。

基本懂得“分支”是什么意思的童鞋都应该会使用，就不赘述了。

总结

追踪字符历史是适用的，而提高目的性更有实际意义。

Visual Studio内建的Git工具只提供了对https协议的支持。并且阉割掉了很多高大上的延展性。然而，假设只就集中精力编写源码而言。仍然是适用的。

源码管理的精髓在于分支与合并。

这可能是Visual Studio之外的project。

不建议安装系统全局的Git工具。最好能用专用的Shell工具（Cygwin、Gentoo-prefix-interix等）来进行高级操作。

这样不仅能够避免额外的复杂性，并且能够较好地控制每用户环境变量，甚至能够获得很多其它可爱的特性。

得益于Visual Studio强大的插件社区。能够加装具有完整功能的Git插件。

内建用惯了反而喜欢内建的简洁。这实在仅仅是个习惯问题

ps：llorch写这一系列博客的目的在于稳固编程技能的基础。今天的讨论是为了明天能专注编码。随着源码管理的讨论陆陆续续写完，也即将进入尾声。llorch会以对程序集的讨论结束这一系列博客。而后专注于“好玩”的内容上去。

感谢大家的关注和支持！！