一律使用版本控制
即使存在一个开发人员，也要使用版本控制/源代码控制。 此问题使应用程序不断进行更改跟踪和版本控制。 对于多开发人员而言，它带来了更多好处，例如共同处理相同文件和快速更新代码库。
不要做半成品
每个提交都应包含一个完整的任务（问题，错误修正等）。 部分提交可能会导致无法运行，应用程序崩溃甚至编译错误。
完整更新->构建->运行->完全提交规则
为了没有问题，应该应用稳定的版本控制过程。 根据此过程，您应该完全更新代码，然后构建并运行您的应用程序。 如果应用程序正确运行，则应提交所有更新的文件。 提交时，检查所有更改的文件和更改。 如果所有团队成员都应用了此过程，则应用程序将始终继续运行，并且没有人会阻止其他人的工作。
提交原子性/粒度
不要使用版本控制系统分别备份每个文件，并且在开发几天或几周后不要提交数百个文件。 提交应该是原子的，并且作为最佳实践，应该包括仅与一项任务相关的文件。 延迟提交还会带来更多冲突。
使用描述性提交消息
提交消息对于跟踪更改很重要。 描述性提交消息可帮助开发人员在功能上下文中控制代码的旧版本，而不仅仅是日期和时间。
不要提交生成的文件
使用版本控制工具的“忽略”功能来忽略提交和更新生成的文件（例如，目标文件夹，用户设置，IDE生成的文件，每次构建后生成的类等）。这样做，您不会浪费时间来管理那些不稳定/不重要的文件。
持续集成
与版本控制一起使用持续集成。 通过这样做，执行自动构建并将其部署到特定位置。 另外，配置该工具以为每个构建创建单独的版本号（使用预定义的版本控制算法，例如<major_changes>。<minor_changes>。<bug_fixes>）。 这对于跟踪测试和部署很有用。
使用合格的版本控制工具和插件（尤其是用于合并）
版本控制工具的质量也很重要。 它至少必须清楚地显示已更改的文件，具有轻松合并冲突文件并查看文件旧版本的功能。 此外，最好具有分支功能来管理版本并与问题跟踪系统同步以管理与问题相关的代码文件匹配。
使用分支进行测试和不同的代码行
您应该使用不同的代码分支进行开发，测试以及生产。 如果正在测试版本的代码，则不应在该分支上继续开发。 开发可以在另一个分支上继续进行，并且在修复了一些错误并添加了新的属性后，如果将对新版本进行测试，则应该为新的测试分支提供新版本。 当达到稳定的测试分支时，它可以作为生产分支发布。
您还可以查看以下链接，了解版本控制的基础知识： http : //betterexplained.com/articles/a-visual-guide-to-version-control/
翻译自: https://www.javacodegeeks.com/2014/03/software-version-controlling-best-practices.html
转播
