码迷,mamicode.com
首页 > 其他好文 > 详细

源代码管理--llorch的Visual Studio基本教程(四)

时间:2015-07-18 00:38:08      阅读:188      评论:0      收藏:0      [点我收藏+]

标签:

通用的示例说明:

  • 本系列博客只讨论工具的基础,不讨论任何语言。
    • 甚至不讨论快捷键:-)
    • 可以用鼠标就完成本教程
  • 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的功能。稳定的代码则不然。比如求两个集合的差集的情况而言,美丽的代码可能会在一个循环里面写大量的语句,而稳定的代码则可能写成三五个顺序执行的循环。那么,到底是美丽的代码好还是稳定的代码好呢?

实际上我们会发现,我们的确会观望美丽的代码,但我们赖以发挥作用的还是稳定的版本。代码的稳定的版本通常会更加容易调试、更加简约循环的内容。我们最终会在保持稳定的基础上进行性能的调整。

 

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

至少一个版本已经在运行,无论是在测试中还是在原型中。在此之外谈源代码管理就是搞学术研究。

源代码管理的概念应该比项目的层级要高。这是因为,就编程的目的而言,一个项目只是达成方案目的的一个子部分。

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

 

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

在Visual Studio中贯穿着强目的性的源代码管理的设计哲学(即使可以很容易地滥用)。这表现在,在不打开任何解决方案的情况下,[团队资源管理器]仍是可用的。然后在分支的合并上有一些自动的简化。

由于实践所限,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之外的工程。

不建议安装系统全局的Git工具。最好能用专用的Shell工具(Cygwin、Gentoo-prefix-interix等)来进行高级操作。这样不仅可以避免额外的复杂性,而且可以较好地控制每用户环境变量,甚至能够获得更多可爱的特性。

得益于Visual Studio强大的插件社区,可以加装具有完整功能的Git插件。内建用惯了反而喜欢内建的简洁,这实在只是个习惯问题技术分享

 

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

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

版权声明:本文为博主原创文章,未经博主允许不得转载。

源代码管理--llorch的Visual Studio基本教程(四)

标签:

原文地址:http://blog.csdn.net/u010289866/article/details/46934175

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!