标签:
今天编程的目的是为了明天不编程。
这一篇博客讨论编程工作内在的目的性,也就是源代码管理。所谓源代码管理仅仅针对可以工作的最稳定的代码进行管理。笨代码和聪明代码是代码片段或编程缓存,而非协作中的源代码管理。
把自己写过的所有代码保存起来,是很好的想法。把自己能用的代码保存起来,以便随时再用,这个想法对开发者来说,可能会更好一点。因为后者更能让开发者集中注意力于设计。常见的追踪文件历史记录的方式是版本控制,也就是通常所说的源代码管理。但是通常所说的源代码管理听起来更像是“字符历史记录”。
一片代码,仅仅从它与程序整体的关系来说,可以概略地分为两类,一类是立时可用的,另一类是“我还要修复一下”的。前一种叫做“源代码”,而后一种只能叫做“片段(snippets?)”。这个区别对开发人员的提示在于,从实践上说,编程就是围绕release的体力劳动工作。
美丽的代码通常会用一些幽密的手法来实现一个比较bigger的功能。稳定的代码则不然。比如求两个集合的差集的情况而言,美丽的代码可能会在一个循环里面写大量的语句,而稳定的代码则可能写成三五个顺序执行的循环。那么,到底是美丽的代码好还是稳定的代码好呢?
实际上我们会发现,我们的确会观望美丽的代码,但我们赖以发挥作用的还是稳定的版本。代码的稳定的版本通常会更加容易调试、更加简约循环的内容。我们最终会在保持稳定的基础上进行性能的调整。
至少一个版本已经在运行,无论是在测试中还是在原型中。在此之外谈源代码管理就是搞学术研究。
源代码管理的概念应该比项目的层级要高。这是因为,就编程的目的而言,一个项目只是达成方案目的的一个子部分。
一旦将源代码管理针对强的目的来进行,那么源代码管理所维护的重心也就自然而然地落到了工作的完成时态。
在Visual Studio中贯穿着强目的性的源代码管理的设计哲学(即使可以很容易地滥用)。这表现在,在不打开任何解决方案的情况下,[团队资源管理器]仍是可用的。然后在分支的合并上有一些自动的简化。
由于实践所限,llorch目前还没有用过Team Foudation Server,因此本篇的内容就以Visual Studio中的Git支持来示例性地说明了。由于Visual Studio 2013内建的Git功能并不完备,有的网友习惯自己组装其他的Git插件。llorch的教程主要想给新手们提供一点参考,所以,这里就假设使用第三方插件的是“高级用户”了。
[主窗口]/{视图}/{团队资源管理器}/,打开[团队资源管理器]子窗口,这是源代码管理的主要操作窗口。
[团队资源管理器]/{下拉列表}=设置/{Git设置}/,对影响Visual Studio全局的身份信息、缓存目录进行设置。
[团队资源管理器]/{下拉列表}=项目/{连接到团队项目}/{克隆}/,填入Git仓库地址和本地缓存目录就开始克隆了。内建的Git工具只能和https协议的发布URL良好协作,不支持ssh的版本,而支持Windows凭据登录的方式。
如果已经克隆过了,这里的菜单会自动切换成拉取。拉取的时最好注意一下分支提交的情况,以免覆盖掉有用的工作。llorch试了几次,好像只要有分支没有提交,这里的拉取就会变灰色。
[团队资源管理器]/{下拉列表}=项目/{本地Git存储库}/{库N}//,双击(//)列出的任何一个本地存储的库,会跳转到[团队资源管理器-主页]子窗口,在[团队资源管理器-主页]/{解决方案}栏目中可以选择操作分支或打开解决方案。
一旦打开了解决方案,则手动切换到[解决方案资源管理器]开始编码。(这是一个用户体验上的BUG,没有自动切换过去,可以通过取消团队资源管理器的停靠来改善。)
[解决方案资源管理器]/{解决方案}>>{提交}/,在其中填入提交消息后就可以提交。
Visual Studio 2013 Community Edition内建的Git工具仅支持通过https协议向远程存储库提交。无论如何,为了提高通用性,应该先克隆,修改之后,再提交。
[团队资源管理器]/{下拉列表}=未同步提交/,如果项目是克隆而来的,那么直接点击{传出提交}/{推送},可以利用克隆步骤中保存的凭据进行一次提交。如果不是,那么这里需要输入一次凭据。
[解决方案资源管理器]/{解决方案}>>{将解决方案添加到源代码管理}/,呼出[选择源代码管理]窗口,选择其中的{Git}。
[解决方案资源管理器]/{解决方案}>>{提交}/,这里会提交到本地缓存。
提交更改到远程存储库同样是适用的。
[团队资源管理器]/{下拉列表}=分支/,在这个界面中Visual Studio把分支的管理简化到了极致。基本懂得“分支”是什么意思的童鞋都应该会使用,就不赘述了。
追踪字符历史是适用的,而提高目的性更有实际意义。
Visual Studio内建的Git工具只提供了对https协议的支持,而且阉割掉了许多高大上的延展性。然而,如果仅仅就集中精力编写源代码而言,仍然是适用的。
源代码管理的精髓在于分支与合并。这可能是Visual Studio之外的工程。
不建议安装系统全局的Git工具。最好能用专用的Shell工具(Cygwin、Gentoo-prefix-interix等)来进行高级操作。这样不仅可以避免额外的复杂性,而且可以较好地控制每用户环境变量,甚至能够获得更多可爱的特性。
得益于Visual Studio强大的插件社区,可以加装具有完整功能的Git插件。内建用惯了反而喜欢内建的简洁,这实在只是个习惯问题
ps:llorch写这一系列博客的目的在于稳固编程技能的基础,今天的讨论是为了明天的不讨论~。随着源代码管理的讨论陆陆续续写完,也即将进入尾声。llorch会以对程序集的讨论结束这一系列博客,而后专注于“好玩”的内容上去。
感谢大家的关注和支持!!
版权声明:本文为博主原创文章,未经博主允许不得转载。
源代码管理--llorch的Visual Studio基本教程(四)
标签:
原文地址:http://blog.csdn.net/u010289866/article/details/46934175