java基础概述_版本控制基础概述

java基础概述

为什么要使用版本控制？
版本控制是开发过程中的关键，这有几个原因，而缺少版本控制可以很好地描述版本控制：

1. 是否希望看到六个月前重构，删除或以其他方式丢失的大量代码？ 嗯...
2. 如果您在实际环境中使用了产品的多个版本（由客户或您自己使用），如何在不升级到最新版本的情况下提供任何形式的错误修复？
3. 是否想尝试一种新的体系结构，构建系统，单元测试库或通用doomahickey，而不必担心当前的设置？ 强硬。
4. 您的代码中是否充满了注释掉的块，以防万一？ 那是可怜的人的版本！
5. 按下发布按钮后，我可能会记得很多其他原因。

最简单，最幼稚的版本控制形式，如果只是经常复制代码库并将其放置在安全的地方。 这总比没有好，但是要说服奥林匹克所有人说服所有人，这是一种合理的方法。 它散布着错误的惰性状态-预先付出零努力，并持续付出努力以使后端获得最小的收益。

跳过公司认为最好的解决方案的部分是开发内部版本控制系统，我们可以直接使用久经考验的版本控制系统（VCS）。 有许多免费的和商业的存在，无论您决定什么，通常都会使您的生活更轻松。
在此特定示例中，我将使用Subversion（ http://subversion.tigris.org ），又名svn，这是一种流行的，建立良好的VCS系统，该系统享有命令行的支持，并提供各种持续集成服务器和IDE。

Subversion版本控制
作为用户交互的核心，Subversion在签出，提交和更新系统上工作。 快速定义：

• 存储库– svn服务器中的版本控制文件的集合
• 签出–版本化文件以及一些特定于svn的信息从svn服务器复制到工作副本的过程（例如，在本地计算机上或在持续集成服务器上）
• 提交（commit）–一项原子操作，在该操作中，工作副本中所有添加，删除或更新的文件都将传播回svn服务器。
• 更新–将工作副本的文件与svn服务器的文件同步。 这用于将非您自己提交的结果提交到您的工作副本中。 根据定义，您自己的提交已经在您的工作副本中，因为您可以在其中进行更改。

在虚拟世界中，典型的项目生命周期是
1.在Subversion中创建项目
2.创建或导入初始文件 3..n-1。 在您和其他提交者更改存储库时提交和更新文件 。 项目结束

任何曾经接触过n的人 ，打破香槟，休息五分钟-您已经交付了该项目的最终版本（更不用说没有错误），或者您只是缩小了尺寸。 但是，这说明了带有单个分支且没有标签的版本控制。 每个提交都可以追溯到一个特定的提交者，并且为后代和代码审核保留项目的开发历史。


分公司？ 标签？ 如上所述，版本控制可以以线性方式完成-一行，提交只属于该行。 用svn术语，这条线称为主干。

使用版本控制 仅行李箱

但是，具有多个版本的项目需要考虑分支。 顾名思义，分支表示主干的主要分支。 实际上，它是分支发生时主干的精确副本。 实际上，我们现在有两条平行的发展线，它们完全独立，但是有着共同的根基。

该分支可以表示例如1.1版的发布点。 该干线将被分支到MyApp-1.1中，并进行构建，测试和运输。 大约与此同时，坐在您对面的人刚刚进行了一项重大更改，直到1.2版才可用–这种提交不会影响1.1代码，因此，主干中正在进行的开发不会破坏错误修复在1.1分支中努力。

一个更现实的发展周期将是

trunk.1 –在Subversion中创建项目

trunk.n..trunk.n-1 –在您和其他提交者对存储库进行更改时提交和更新文件

trunk.n –随着新客户的加入，分支机构代码发出各种请求

trunk.n + 1 –继续开发新功能，需求等，分支不会感觉到任何影响。 发现在分支中也存在的任何错误都可以将其修复程序移植到分支中。

branch.n.1 –修正了错误，树干感觉不到任何影响。 发现在主干中也存在的任何错误都可以将其修复程序移植到主干中。

具有分支和标签的存储库

当达到某些点时（例如，当满足所有要求时），标签就起作用了。 标记是给定点处分支的快照，对于在给定点处调用项目的状态很有用。 每个发行版至少应使用标签； 它们也可以用于例如内部跟踪。

所以你只能有一个分支？
到目前为止，示例集中在主干和单个分支上。 出于说明目的，这很好，但请记住，不仅可以有多个分支，还可以从分支中分支。 实际上，您可以将主干视为分支，唯一的区别是它没有父级。

当二进制文件说出全部真相而仅是真相时，为什么还要版本呢？
归根结底，实用主义和懒惰是任何开发人员都可以拥有的两个最大属性。 它们带来了自动化，高效的流程，并倾向于在最短的时间内使事情变得正确。 考虑到这一点，确定将版本控制添加到您的项目中肯定是不必要的开销吗？ 毕竟，客户持有的二进制文件不仅符合他们的要求，而且还包含需要修复的错误！ 可以从客户请求二进制文件，将其反编译，打补丁，重新编译和重新分发。 像馅饼一样容易，像豌豆一样甜，等等。

如果您要采用这种方法，则每次必须为客户修复错误时，都必须询问客户其二进制文件。 当然，您可能会保留发送给他们的每个二进制文件的副本，以避免这种不专业且令人尴尬的请求……但是，如果要这样做，为什么不在第一版中对源代码进行版本化地点？

参考：来自JCG合作伙伴 的版本控制基础概述   Steve Chaloner在Objectify博客上。

翻译自: https://www.javacodegeeks.com/2012/03/overview-of-basics-of-versioning.html

java基础概述