本文转载自： FPGA的现今未微信公众号
对于FPGA开发者来说，我们或多或少有过这样的经历：
1、项目的代码是不断的通过本地备份（ctrl+c、ctrl+v）来管理，或者干脆没有管理；
2、即使用了版本管理工具（比如SVN或者git），上传代码随意，或者也不上传；
3、感觉每次上传代码都要钱似的，有的人是等一波代码修改后，或者等一段时间后，再一次全部上传，管你是工程过程文件还是中间临时文件，统统上传；
4、上传了什么，代码修改了什么，不好意思，自己也不知道……
作为一个开发者，我们都有过将写好的，或者修改后的代码上传服务器（这里把版本管理工具，比如git、SVN统称为服务器）的经历。究竟应该如何上传服务器呢？从技术上讲，不值一提，但是从工程的角度讲，尤其是一个团队很多人都需要上传服务器的时候，还是需要一点点的规矩来保证我们版本管理的有效性。
本文主要讨论的是FPGA的代码如何上传，至于其他的代码，在版本管理上可能大同小异罢了。
为了方便说明这个问题，我们从FPGA开发流程入手，因为在FPGA不同的阶段，代码上传服务器可以采用不同的策略。
编码阶段上传策略
首先要回答的一个问题，就是什么是编码完成？把代码写完上传服务器就是编码完成？不是，还要加一个条件，就是写的各个一级模块的代码已经通过综合工具比如vivado或者quartus的综合、PR并能生成bit文件。在这个阶段，各个团队成员只需要保证在编码完成的时间点之前，把代码上传就好，没有什么特定的原则性要求，
但是有一个建议：代码写完了，及时上传，服务器不仅是存放代码的地方，更是管理自己代码的工具。
UT阶段上传策略
在UT阶段，是开发人员修改代码最频繁的阶段，由于各个模块的功能都还没有验证完成，在这个阶段，可能还得不到一个基本能用的版本，所以这个阶段对于上传代码也没有什么特定的原则性要求，
同样也有一个建议：那就是上传的代码不能有语法问题，要保证编译能通过。因为在这个阶段，可能有同事已经开始编码版本，验证时序、管脚、硬件点灯等基础功能了。
ST阶段上传策略
ST阶段，开发人员主要工作就是解决仿真人员发现的bug。这个阶段，代码的修改量逐渐开始收敛。服务器上的版本，已经具备了一些基本功能，这个时候上传代码就不能随心所欲，尤其是项目是多人组成的团队来开发时，就需要一些规则来保证我们版本的正确性。
1、代码的上传要采取“蚂蚁搬家”的形式，即每解决一个ST仿真问题，就上传一次代码的修改；
2、每次上传代码，要写好commit，包括上传人、时间、修改原因或者解决了什么问题、解决方案等等，可以根据项目特点选择一个好的commit模版；
3、只上传有意义的修改，没有意义的临时文件，工程文件等不要上传；
4、当一个问题的修改涉及到多人多个模块时，修改完成后要同时上传，保证服务器代码的可用性。
上板测试阶段上传策略
上板测试阶段，代码的修改更加收敛了，而且这个阶段开始发布版本，因此上传代码的策略需要更加的规范化。这个阶段我们把代码上传服务器，需要有一个基本的目标或者原则，那就是：代码服务器上的任何一个版本是可以编译的，可以测试的，不要出现因为个人的失误上传，影响了团队版本的节奏；
这个时候上传的规则，除了ST阶段所提及的外，还有如下要求：
1、基于问题的解决上传代码，每次上传的时候需要做代码修改点的比对，确保修改的正确性。这点很重要，毕竟在上板阶段定位一个低级问题是需要代价的，这个代价不值得；
2、解决一个问题后上传代码，不能引入新的问题，即要保持问题的收敛；
3、解决问题后，要保证正确的版本发布，保证上板测试的版本是回溯的（具体可见：FPGA版本管理）；
4、版本可回退，做好commit，尤其是需要前后版本做对比测试的时候，要保证可以获取的可用的以前版本；
总结
在FPGA开发中，代码上传这件事情要作为一个重点内容纳入团队的项目管理中，可以有效地降低因为代码的管理等这类非技术原因引入的问题，保证我们项目的顺利交付。
