当前位置:  编程语言>其它

软件项目版本控制需要注意的几点

 
分享到:
    发布时间:2014-1-15  


     软件设计师常会利用版本控制来追踪、维护源码、文件以及设定档等等的改动,并且提供控制这些改动控制权的程序。在最简单的情况下,软件设计师可以自己保留一个程式的许多不同版本,并且为它们做适当的...

     软件设计师常会利用版本控制来追踪、维护源码、文件以及设定档等等的改动,并且提供控制这些改动控制权的程序。在最简单的情况下,软件设计师可以自己保留一个程式的许多不同版本,并且为它们做适当的编号。这种简单的方法已被用在很多大型的软件项目中。该方法虽然可行,但不够有效率。除了必须同时维护很多几乎一样的源码备份外;而且极度依赖软件设计师的自我修养与开发纪律,但这却常是导致错误发生的原因。

有时候,一个程式同时存有两个以上的版本也有其必要性,例如:在一个为了部署的版本中程式错误已经被修正、但没有加入新功能;在另一个开发版本则有新的功能正在开发、也有新的错误待解决,这使得同时间需要不同的版本并修改。

     此外,为了找出只存在于某一特定版本中(为了修正了某些问题、或新加功能所导致)的程式错误、或找出程式错误出现的版本,软件除错者也必须借由比对不同版本的程式码以找出问题的位置。

     软件项目版本控制需要注意的几点如下:

     1. 提交相互关联的变化(Commit Related Changes)

        每次提交的应该是一系列有关联的变化。例如,修复了两个不同的bug应该分别提交两次。提交的变化少,

其他开发者更容易理解变化的内容,出现问题更容易回滚到原来的状态。       

    2.经常提交(Commit Often)  

        经常提交可以保证提交的变化少而且相互关联。而且,可以更快地使其他开发者看到最新的代码。这样更容易让所有人快速

合并变化,避免发生冲突。若偶尔提交一次且代码变化较大,将使冲突很难解决。

    3.不要提交半成品(Don’t Commit Half-done Work)

       不要提交未完成的代码。这并不是要求你完成某个全面、大型的功能的代码后再提交,而是:按逻辑将其分解成多个部分并尽早提交。

       不要为了将代码存储到服务器上而在下班前匆忙提交,如果仅仅是为了提交今天的工作内容,尝试使用“git stash”代替”git commit”。               4.提交之前先测试(Test Code Before You Commit)

        不要提交你”认为”已经完成的内容。先对改变的代码作详尽的测试并确保所做的改变没有副作用。虽然提交半成品仅仅需要的

是原谅自己,然而向服务器提交测试过的代码再让其他开发者使用更重要。

    5.写有用的提交记录(Write Good Commit Message)

        先简短地总结对文件所做的改变,插入空行,再写详细内容。详细内容应该提供了以下几个问题的答案:— 改变的目的? — 改变后与上次实现的区别?

    6.版本控制不是文件备份(Version Control Is Not A Backup System)

        将文件备份到服务器上是版本控制工具带来的副产品,但是你不应该把版本控制系统用来备份文件。使用版本控制时,应力求

每次提交的都是相关联的变化(见第一条)——而不是提交一堆文件。

        译者注:版本控制的目的是易于追踪文件变化,方便多人协作,实现开发中的工作流(branch, merge, tag...)

   7.使用分支(Use Branches)

         分支是Git最强大的特性之一——这并非偶然:Git最初的核心目标就是快速简单地建立分支。分支是帮助划分多个开发路线的完美

工具。你应该在开发工作流中广泛应用分支:如增加新功能,修复bug,验证想法...


   



本类别最新文章推荐:


站内导航:


特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除!

©2012-2017,169IT.COM,E-mail:www_169it_com#163.com(请将#改为@)

浙ICP备11055608号