软件设计师常会利用版本控制来追踪、维护源码、文件以及设定档等等的改动，并且提供控制这些改动控制权的程序。在最简单的情况下，软件设计师可以自己保留一个程式的许多不同版本，并且为它们做适当的编号。这种简单的方法已被用在很多大型的软件项目中。该方法虽然可行，但不够有效率。除了必须同时维护很多几乎一样的源码备份外；而且极度依赖软件设计师的自我修养与开发纪律，但这却常是导致错误发生的原因。
有时候，一个程式同时存有两个以上的版本也有其必要性，例如：在一个为了部署的版本中程式错误已经被修正、但没有加入新功能；在另一个开发版本则有新的功能正在开发、也有新的错误待解决，这使得同时间需要不同的版本并修改。
此外，为了找出只存在于某一特定版本中（为了修正了某些问题、或新加功能所导致）的程式错误、或找出程式错误出现的版本，软件除错者也必须借由比对不同版本的程式码以找出问题的位置。
软件项目版本控制需要注意的几点如下:
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，验证想法...
-
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载,整理或搜集自网络.欢迎任何形式的转载，转载请注明出处.
转载请注明：文章转载自:[169IT-IT技术资讯]
本文标题:软件项目版本控制需要注意的几点
