许多年前,我在国防部的一个项目中工作,该项目必须符合软件开发标准DoD-Std 2167和软件质量保证标准Mil-Std 2168。当时,国防部正努力应对大量涌入的软件系统和编程语言。这些标准试图将一些工程规程引入系统编程这个半科学半魔术的世界。在项目完成时,我在想应该给所有团队成员发一件写着“我幸存了2167”的t恤。从那以后,这些标准被取代了,甚至连“语言到所有语言的最后阶段”(Ada)也基本上被国防部抛弃了。
就像大多数其他事情一样,软件标准的一个常量是变化。
最近分配给我的一个项目涉及将几个应用程序迁移到一个新环境。该任务中最困难和最令人沮丧的部分之一是确定什么应用程序在什么机器上运行,以及源代码的适当版本在哪里。修订控制只不过是在应用程序脚本中放入一条语句,将版本号(程序员生成的日期/时间戳)记录到运行时日志文件中。确定运行时版本需要连接到计算机,通过日志文件搜索应用程序最后一次启动的时间,并记录日期-时间戳信息。然后,我进入集成开发环境,打开应用程序,查看该信息是否与源代码中的条目匹配。即使它们确实匹配,也不能保证运行时是从这个源生成的,或者这个源与用于生成运行时的源不同,日期/时间戳除外。当然可以。
鉴于这种并不罕见的情况,我被要求对修订控制工具做一些研究。我决定Git-分布式版本控制系统,这意味着客户端可以获得存储库的完整副本,包括所有文件、历史记录、分支和存储库中的任何其他内容。我将项目主存储库保存在我们的服务器上,在那里它是安全的,并定期备份。在开始工作或访问客户站点之前,我将存储库克隆到我的笔记本电脑上并随身携带。我可以在客户站点进行更改,如果喜欢的话提交更改,然后在回到办公室时将更改推到服务器上。然后,如果我愿意,我可以删除存储库的本地副本。
虽然我对Git的使用被认为是可行的,但它并没有被采纳为标准。然而,我被允许在我的项目中使用它,如果这样做会而不是破坏的过程。
Git的所有功能都很好,但它付出了什么呢?以下是部分列表:
* Git在VB上生成代码差异文件。在项目完成18个月后,客户联系了我,想知道在两个独立的发行版中合并了哪些更改。结果,这是一个简单的剪切和粘贴的工作,git为我列出了不同之处。
* Git允许我提供关于更改内容和原因的详细日志条目。我曾多次尝试在存档文件夹中保存一个Readme.txt文件,但通常都没有这个原则。Git很容易做到这一点,它向我显示已经更改的文件;如果它们是文本文件,git甚至会显示已经更改的行。
* Git可以创建一个分支,允许我尝试代码更改。当这些更改不起作用时,我只需删除分支并恢复到原始代码。
无论您选择Git还是更传统的集中式版本控制系统,这都是一门对您和您的公司都有好处的学科。
David K. Anderson是公司的高级项目经理洛曼控制系统公司.,的认证成员控制系统集成商协会.了解更多关于洛曼控制系统工业自动化交易所。