在做项目的过程中不断有新的实验和需求，软件的版本也不断的更改，很多时候建了一个又一个复制件目录，v0.1,v0.2,vxxx.xxx，往往把自己都绕进去了。因为这些原因，开始使用 GIT 版本控制器，到现在来说已经用了快一年了，但仍然会有很多这方面的问题，由于我做的是嵌入式开发，往往经常会对硬件进行修改，本文对嵌入式项目进行总结，希望可以找到一个可行性高的项目管理方法。

本文的内容主要针对嵌入式项目研发过程中，可能出现的版本控制，对其他纯软件项目可能并不是特别有效，这边仅给出我自己的方法，如有更好的方法希望可以给出建议。

这边先给出一段我以前写的，网上参考的 git 的分支方案：

在实际开发中，我们应该按照几个基本原则进行分支管理：

• master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
• 干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
• 每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

团队合作示意图：

在原来的基础上进一步修改，我给出的方案是：

• master 分支只用来初始化版本库后，承担第一个文件（.gitignore）的提交，后续不将其他内容合并到master 上。
• 嵌入式项目在研究阶段如果加入一些功能的话往往无可避免的会更改一些硬件，我建议以每个已经制版了的硬件作为一条独立分支，直接接在 master 之后，这样可以让所有的分支结构看起来比较有条例。
• 注意上面是已经制板出来的电路作为一个分支结构，也就是说至少这个版本在一定时间内是一个比较成熟的版本，并不是每次手动更改电路都在 master 后建立一条分支。出现新的硬件版本后，因为新的 board_new 分支接在 master 后，几乎没有内容，可以直接将 这天分支快速合并到现在 board_old 的开发位置。
• 每个制板电路后，在新建可能局部修改硬件的小分支，该分支是接在板分支之后的不直接和 master 分支关联，每次的新功能和小改动都基于这些小分支，这边有两种方法，一种是进一步采用递归，基于 board 建立硬件主分支，其他软件功能性都作为这些硬件改动的从分支，但这种虽然想起来清晰，但操作起来很繁琐而容易出错；另一种是，按照重要性，只将可能出现重用的一些重要功能建立新分支，其他的不再建立分支。
• 一般来说每次硬件的改动都将不会返回上一个版本的硬件，也就是说老的 board_old 分支将不会再使用，但我们最好做好版本控制，可以将内容保存清除，方便万一查看。但也可能某个实验会改回原来的硬件版本，这个时候我建议是手动对比最新版本和老版本的区别（diff），不要使用合并，如果你没对 board_old 进行过修改的话，虽然是可以快速合并的，但仍然不建议这么做。

下面是一个大体思路示意图：

后续有新的发现，仍然会更新本文。