layout: "post"
title: "git控制版本方法"
date: "2017-04-12 09:50"
在做項(xiàng)目的過(guò)程中不斷有新的實(shí)驗(yàn)和需求，軟件的版本也不斷的更改，很多時(shí)候建了一個(gè)又一個(gè)復(fù)制件目錄，v0.1,v0.2,vxxx.xxx，往往把自己都繞進(jìn)去了。因?yàn)檫@些原因，開(kāi)始使用 GIT 版本控制器，到現(xiàn)在來(lái)說(shuō)已經(jīng)用了快一年了，但仍然會(huì)有很多這方面的問(wèn)題，由于我做的是嵌入式開(kāi)發(fā)，往往經(jīng)常會(huì)對(duì)硬件進(jìn)行修改，本文對(duì)嵌入式項(xiàng)目進(jìn)行總結(jié)，希望可以找到一個(gè)可行性高的項(xiàng)目管理方法。
本文的內(nèi)容主要針對(duì)嵌入式項(xiàng)目研發(fā)過(guò)程中，可能出現(xiàn)的版本控制，對(duì)其他純軟件項(xiàng)目可能并不是特別有效，這邊僅給出我自己的方法，如有更好的方法希望可以給出建議。
這邊先給出一段我以前寫(xiě)的，網(wǎng)上參考的 git 的分支方案：
在實(shí)際開(kāi)發(fā)中，我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理：
- master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來(lái)發(fā)布新版本，平時(shí)不能在上面干活；
- 干活都在dev分支上，也就是說(shuō)，dev分支是不穩(wěn)定的，到某個(gè)時(shí)候，比如1.0版本發(fā)布時(shí)，再把dev分支合并到master上，在master分支發(fā)布1.0版本；
- 每個(gè)人都在dev分支上干活，每個(gè)人都有自己的分支，時(shí)不時(shí)地往dev分支上合并就可以了。
團(tuán)隊(duì)合作示意圖：
在原來(lái)的基礎(chǔ)上進(jìn)一步修改，我給出的方案是：
- master 分支只用來(lái)初始化版本庫(kù)后，承擔(dān)第一個(gè)文件（.gitignore）的提交，后續(xù)不將其他內(nèi)容合并到master 上。
- 嵌入式項(xiàng)目在研究階段如果加入一些功能的話往往無(wú)可避免的會(huì)更改一些硬件，我建議以每個(gè)已經(jīng)制版了的硬件作為一條獨(dú)立分支，直接接在 master 之后，這樣可以讓所有的分支結(jié)構(gòu)看起來(lái)比較有條例。
- 注意上面是已經(jīng)制板出來(lái)的電路作為一個(gè)分支結(jié)構(gòu)，也就是說(shuō)至少這個(gè)版本在一定時(shí)間內(nèi)是一個(gè)比較成熟的版本，并不是每次手動(dòng)更改電路都在 master 后建立一條分支。出現(xiàn)新的硬件版本后，因?yàn)樾碌?board_new 分支接在 master 后，幾乎沒(méi)有內(nèi)容，可以直接將 這天分支快速合并到現(xiàn)在 board_old 的開(kāi)發(fā)位置。
- 每個(gè)制板電路后，在新建可能局部修改硬件的小分支，該分支是接在板分支之后的不直接和 master 分支關(guān)聯(lián)，每次的新功能和小改動(dòng)都基于這些小分支，這邊有兩種方法，一種是進(jìn)一步采用遞歸，基于 board 建立硬件主分支，其他軟件功能性都作為這些硬件改動(dòng)的從分支，但這種雖然想起來(lái)清晰，但操作起來(lái)很繁瑣而容易出錯(cuò)；另一種是，按照重要性，只將可能出現(xiàn)重用的一些重要功能建立新分支，其他的不再建立分支。
- 一般來(lái)說(shuō)每次硬件的改動(dòng)都將不會(huì)返回上一個(gè)版本的硬件，也就是說(shuō)老的 board_old 分支將不會(huì)再使用，但我們最好做好版本控制，可以將內(nèi)容保存清除，方便萬(wàn)一查看。但也可能某個(gè)實(shí)驗(yàn)會(huì)改回原來(lái)的硬件版本，這個(gè)時(shí)候我建議是手動(dòng)對(duì)比最新版本和老版本的區(qū)別（diff），不要使用合并，如果你沒(méi)對(duì) board_old 進(jìn)行過(guò)修改的話，雖然是可以快速合并的，但仍然不建議這么做。
下面是一個(gè)大體思路示意圖：
后續(xù)有新的發(fā)現(xiàn)，仍然會(huì)更新本文。
