Gitlab 和項目管理

產(chǎn)品部

• 產(chǎn)品經(jīng)理，產(chǎn)品專員

• 平面設計，UI/UE

開發(fā)部

• 軟件項目經(jīng)理

• 開發(fā)組長（根據(jù)項目并行開發(fā)的產(chǎn)品線而定）

• 高級程序員，中級程序員，初級程序員

測試部

• 軟件測試經(jīng)理

• 測試組長（根據(jù)并行測試的項目數(shù)量而定)

• 高級測試工程師（自動化測試），中級測試工程師（功能測試），初級測試工程師（功能測試）

運維部

• 運維經(jīng)理

• 運維組長（根據(jù)服務器數(shù)量而定）

• 高級運維工程師（運維工具研發(fā)），中級運維工程師（8小時，處理日常運維），初級運維工程師（7*24小計監(jiān)控）

• 
  

開發(fā)、測試和運維三個部門的關系

• 開發(fā)，測試，運維不是三個獨立部門，他們相互緊密聯(lián)系，但又相互制約

• 開發(fā)只負責寫程序，將運行無誤的程序提交至版本庫中

• 開發(fā)不能私自將程序交給運維部署，也不能將編譯好的程序給測試人員

• 測試部只能從版本庫提取代碼，然后編譯，打包，運行，測試

• 不允許測試部將代碼交給運維部部署

• 避免代碼沒有經(jīng)過版本庫流入生產(chǎn)環(huán)境，造成線下與線上代碼不一致

• 運維部負責部署應用程序，配置管理，只接受測試部確認無誤的版本，部署代碼只能從版本庫中獲取

  
  

權限角色

文檔角色：產(chǎn)品，設計

報告角色：測試

開發(fā)角色：開發(fā)

運維角色：運維

項目計劃

我常常把項目開發(fā)計劃比做列車時刻表，每一個站對應一個項目節(jié)點即里程碑。

列車時刻表的概念來自早年我參與的一個英國項目，我們使用?TRAC?管理項目，這是一個古老的項目管理軟件，他是很多現(xiàn)代項目管理軟件的雛形，很多思想沿用至今，甚至無法超越它，由于他是 Python 開發(fā)，框架古老，后期無人維護更新跟不上時代節(jié)奏。另一個項目模仿它90%的功能叫 Redmine，Redmine 紅極一時，但是仍然沒有統(tǒng)一江湖。直到 Github/Gitlab 出現(xiàn)，一站式解決了軟件項目管理中遇到的各種剛需問題，TRAC，Redmine，Confluence，Bugzilla，Jira, Mantis, BugFree, BugZero…… 慢慢淡出人們視野。

在 TRAC 中，任務叫做 Ticker 翻譯成中文就是“票”，項目是沿著 Roadmap 走，走過的路叫時間線 Timeline， 里程碑又形象的比做站點，每個 Milestone 里面是一組 Ticker。每次升級就如同買票上車，火車不等人，同理項目也按照自己的 Roadmap 運行，錯過只能等下一班。

項目經(jīng)理會在即時通信軟件中，通知發(fā)車時間，需要升級同事就會將自己上手的Ticker代碼合并主干，然后等待發(fā)車。

			
                         [ Roadmap ]		
          ---------------.
          ----\	          \	
Timeline  -----o-----o-----o-----o-----o-----o-----> 		
		  ----------/           /
		  ---------------------
		
		

火車偶爾也會出現(xiàn)晚點，取消班次，臨時停車或不?？恐苯娱_往下一站的情況。項目也是如此：

晚點就是項目延期，取表班次就是停止本次里程碑的上線計劃，臨時停靠即熱修復和緊急上線，不?？烤褪翘^本次里程碑，下一個里程碑一次性解決。

我們常常會在即時通信軟件中發(fā)布發(fā)車時間和詢問發(fā)車時間。

項目計劃應該是像列車時刻表一樣，一旦你定好，就不能隨意修改，必須按照設定的里程碑有條不紊的推進。

我們發(fā)現(xiàn)很多國內(nèi)項目是被任務牽著做，即沒有項目路線圖，走到那里算那里，覺得差不多了就上線，相當隨意。一旦出現(xiàn)交叉，沖突，就會手忙腳亂，回撤更是家常便飯。

工作流

項目管理需要設計工作流

你會發(fā)現(xiàn) Gitlab 并沒有提供工作流的功能？為什么？你是否想過？不僅Gitlab 沒有 ，微軟的 Microsoft Project 也沒有，為什么 Microsoft Office 不提供這種功能？

談談我的一段職業(yè)生涯，大約在2000年我來到深圳，第一份工就是OA（辦公自動化）系統(tǒng)開發(fā)，當時有很多公司開發(fā)類似產(chǎn)品，也包括金山軟件，用友等等。20年過去了，OA沒有一個標準，也沒有一個成功的產(chǎn)品，OA似乎成為企業(yè)數(shù)字化轉(zhuǎn)型不上的工具之一，上了之后又發(fā)現(xiàn)這東西根本沒法使用。

OA 沒有成為主流的原因，死結就是工作流，每個公司都有自己的流程，無法統(tǒng)一標準，即使是管理學誕生的西方國家，也沒有統(tǒng)一的流程，流程是隨著市場和環(huán)境不斷變化的，沒有任何流程能始終延續(xù)。經(jīng)歷了德魯克時代的企業(yè)到目前為止保留下來的流程也只有部分行政審批流程。

這就是微軟不碰這塊，IBM也做，Oracle 也不做的原因。雖然技術上已經(jīng)又成熟的工作流引擎，圖形化配置，使用過的人都表示巨難用，對于非技術的行政人員幾乎都放棄了。

但凡設計流程，設計者都會表現(xiàn)自己，最終設計的出的流程無比復雜，看似流程堪稱完美，執(zhí)行起來不是內(nèi)耗就是受阻。幾乎都是做加法思維，能做減法思維的人少之又少。

工作流設計原則

1. 遵循減法原則而不是加法原則，參與人越少越好，節(jié)點越少越好。

2. 盡量線性，從一端流向另一段，中間盡量不出現(xiàn)分叉。

3. 盡可能不出現(xiàn)邏輯判斷分叉，例如 A審批決定下一步是流向B還是C

4. 避免循環(huán)，依賴關系避免循環(huán)，即流程后退。

目的是讓工作流可操作，易操作，能冗余。

下面這個流程有問題嗎？

		
開發(fā)人員提測 -> 開發(fā)組長審批 -> 技術部門審批 -> 測試部門審批 -> 測試組長審批 -> 分配測試人員
		
		

稍具規(guī)模的企業(yè)不都是這樣做的嗎？

		
     開發(fā)人員提測        |       分配測試人員
--------------------------------------------------
     開發(fā)組長審批        |       測試組長審批
--------------------------------------------------
     技術部門審批        |       測試部門審批		
		
		

矩陣轉(zhuǎn)換一下，看的更清晰，工作流從一段流向另一段，經(jīng)歷兩個部門，六個節(jié)點。理論上審批超過三層就要控制，超過三層就會影響進度。為什么會出現(xiàn)這種情況？

我做過分析，國內(nèi)的管理層大可分為兩類，一類是著重考察項目過程本身，一類是主要考察項目的參與者和結果，前者著重于時間管理，后者傾向于績效考核。?^[1]

第一類管理者，很清楚項目的 Roadmap，所以根本無需做，技術部門審批到測試部門審批這個審批過程，這些工作都是在 Roadmap 會議定定好的，按時發(fā)車即可。

第二類管理者，通常是學管理出身，運用管理學工具管理項目，他無法參與項目過程，只能關注時間點和進度，不斷催促，他需要知道現(xiàn)在做什么？什么時候做完？所以需要事事審批。

議題

Issues 議題

Milestones 里程碑

敏捷開發(fā)中可以每周一個里程碑，或者每個月一個里程碑。

修正路線圖（Roadmap）

每間隔一端時間需要調(diào)整一次 Roadmap 的設置，因為有些項目會延期，有些會提前完成，還有需求變更等因素都會影響 Roadmap。

工作報告

由于項目是由上至下層層分解下去的，制定了嚴格的Roadmap，每個參與者知道自己該做什么，如何做，什么時間完成，也就無需再向上匯報工作。

團隊所要做的就是按照 Roadmap 的時間和節(jié)點走即可。

5W2H 任務分配法則

一旦時間點確定，接下來就是分配任務倒指定開發(fā)人，任務的分配十分講究，分配任務要精確描述，不能使用模糊語言，那樣會造成誤解。我的分配原則是5W2H方法：

- What：做什么事？
- Why：為什么做這件事？有什么意義？目的是什么？有必要嗎？
- When：什么時候做，完成的時間是否適當？
- Where：在什么地方做，在什么范圍內(nèi)完成？
- Who：由誰負責做？由誰負責執(zhí)行？誰更合適？熟練程度低的人能做嗎？
- How：怎樣做
-?How?much:?成本?（不是所有崗位都會涉及成本）

任務/議題

議題

運維任務

舉例，運維任務

- What：為api服務器做負載均衡，多增加一個節(jié)點，負載均衡算法采用最小連接數(shù)。
- Why：目前api服務器只有一臺，如果出現(xiàn)故障將影響到所有業(yè)務運行，顧該服務器存在單點故障，需要增加節(jié)點。
- When：本周內(nèi)完成，周末上線。（此處可以寫日期）
- Where：在A機柜，低2機位處，連接倒交換機第三個端口。
- Who：XXX負責網(wǎng)絡配置，XXX負責上架，XXX 負責驗收測試
- How：增加/etc/hosts設置如下
??-?api.example.com???127.0.0.1
??-?api1.example.com??192.168.2.5
??-?api2.example.com??192.168.2.6?

開發(fā)任務

舉例，開發(fā)任務

- What：增加圖片驗證碼。
- Why：目前用戶注冊登陸以及發(fā)帖無驗證嗎，某些用戶通過機器人軟件批量開戶/發(fā)廣告帖，給管理帶來很大困擾。
- When：2014-06-15 開始開發(fā)，2014-06-20 12:00?上線。
- Where：用戶注冊，登陸與發(fā)帖處增加該功能，。
- Who：張三負責驗證碼生成類的開發(fā)，李四負責用戶注冊，登陸UI修改，王五負責發(fā)帖UI的修改。
- How：具體怎么操作的細節(jié)，此處省略200字...

測試任務

舉例，測試任務

- What：測出XXX軟件并發(fā)性能。
- Why：目前XXX軟件在線任務達到200后，用戶反映速度慢，經(jīng)常掉線。
- When：故障時間點10：00AM，需要周二完成測試，周五完成優(yōu)化，月底上線。（此處可以寫日期）
- Where：在AAA分支檢出代碼，編譯后部署到BBB環(huán)境。
- Who：XXX負責網(wǎng)絡配置，XXX負責軟件部署，XXX 負責測試
- How：具體怎么操作的細節(jié)，此處省略200字...

運營任務

舉例，促銷任務

- What：XXX產(chǎn)品促銷。
- Why：目前XXX產(chǎn)品在 XXX 市場占有率 XXX 用戶反映 XXX。
- When：促銷起始時間 XXX 結束時間 XXX
- Where：AAA 細分市場，BBB區(qū)域。
- Who：XXX負責 XX，XXX負責 XX，XXX 負責 XX
- How：具體怎么操作的細節(jié)，此處省略200字...
-?How?much:?成本XXX

并行開發(fā)

多個功能并行開發(fā)最常遇到的問題就是沖突，例如A，B，C三個功能同時開發(fā)，共用一個分支（development）A開發(fā)完成，B功能開發(fā)1/3，C功能有BUG，此時升級A功能，B跟C也會被升級上去。

實現(xiàn)并行開發(fā)，需要滿足兩個條件。一是合理的任務分解，二是配套的環(huán)境，三是分支的應用。

任務分解

任務分解要盡可能解耦，出現(xiàn)交叉合并為一個任務。一個任務對應一個功能，功能與功能之間依賴關系必須理清，避免出現(xiàn)交叉依賴和循環(huán)依賴。

			
A -> B -> C
      \-> D -> E
       	  \--> F		
			
			

配套環(huán)境

配套環(huán)境是指開發(fā)和測試環(huán)境，參考生產(chǎn)環(huán)境，以最小化實例，最小化節(jié)點，滿足運行項目的環(huán)境，盡量減少環(huán)境差異，包括硬盤配置差異，網(wǎng)絡差異，資源配置差異，以及應用軟件安裝配置等等差異。

準備配套環(huán)境

1. 開發(fā)環(huán)境(development)，也叫集成開發(fā)環(huán)境，為開發(fā)團隊提供共享資源，因為每個程序員在自己的電腦上運行一整套的分布式系統(tǒng)不太現(xiàn)實，所以需要將公共部分抽離出來，集中提供服務，例如數(shù)據(jù)庫，緩存，搜索引擎，配置中心，注冊中心等等。

2. 測試環(huán)境(testing)，由于開發(fā)環(huán)境需要頻繁合并新功能，部署，重啟都會影響正常的測試，例如測試一般，開發(fā)環(huán)境上加入了新功能，此時會影響測試。所以我們需要一臺獨立，穩(wěn)定的測試環(huán)境，這個環(huán)境由測試人員自己控制，什么時候部署，測試自己說了算。

3. 用戶交付測試環(huán)境（staging）Stage/UAT 環(huán)境，Beta/Preview 演示環(huán)境，定期同步生產(chǎn)環(huán)境數(shù)據(jù)庫。

4. 功能測試環(huán)境(feature/hotfix) 新功能，BUG修復等等。

上面三個環(huán)境，至少一臺獨立服務器，功能測試環(huán)境(feature/hotfix) 需要若干臺服務器。功能測試環(huán)境的服務器是共享的，即誰提測誰用，用過之后釋放出來。

每個環(huán)境都有一整套，配套的服務，例如數(shù)據(jù)庫，緩存，搜索引擎，消息隊列等等……

代碼分支

時間線分支

1. 開發(fā)分支 Development 面向開發(fā)人員

2. 測試分支 Testing 面向測試人員

3. 交付驗收分支 Staging 交付驗收分支，俗稱 UAT 面向測試和客戶

4. 生產(chǎn)分支 Production，面向用戶

在小公司中通常會省去 UAT 這個環(huán)節(jié)，從 Testing直接上生產(chǎn)環(huán)境

分支權限

分支保護的目的，防止被誤刪除，禁止向該分支提交代碼，代碼只能通過合并方式進入該分支。

分支的權限管理：

1. master: 保護，不能修改代碼，只能合并，只有管理員有權限push

2. staging：保護，不能修改代碼，只能合并，只有管理員有權限push

3. testing：保護，不能修改代碼，測試人員可以合并 merge

4. development：保護，開發(fā)人員可以修改代碼，合并，push

5. tag 標簽：保護，對應 Release 本版

功能分支

功能分支（Feature），任務分解之后，每個功能對應一個分支，功能分支的代碼來自 development 分支，我們會有很多功能分支，開發(fā)任務在功能分支上完成開發(fā)，開發(fā)完成后將任務標記為“測試”，測試部會安排測試環(huán)境，部署該分支上的代碼，測試結果分為BUG和Pending（測試通過，掛起，等待發(fā)車）。

買票上車：在功能分支上，我們有很多開發(fā)完成功能，他們處于掛起狀態(tài)，然后根據(jù)升級計劃，有序的合并到開發(fā)分支，再到測試分支，最后升級到生產(chǎn)環(huán)境。

Feature 分支操作步驟：

1. 創(chuàng)建 Issue 議題

2. 從 Development 創(chuàng)建 Feature 分支

3. 獲取 Feature 分支代碼

4. 修改代碼，提交代碼，測試代碼

5. 合并 Feature 分支到 Development 分支

6. 關閉 Issue 議題

合并流程

代碼合并流程

					
Development -> testing -> staging -> master(production)				
				
				

合并分支

從 development 像 testing 分支合并

git checkout developmentgit pullgit checkout testinggit pullgit merge --no-ff "development"git push  

testing 分支向 master 分支合并

獲取 testing 合并請求的分支

git fetch origingit checkout -b "testing" "origin/testing"  

如果此前已經(jīng)執(zhí)行過，使用下面命令切換分支即可，切換后 pull 代碼，看看有什么新提交

git checkout "testing"git pull

切換到 master 分支

git fetch origingit checkout "master"git branch --show-currentgit merge --no-ff "testing"

將合并結果推送到遠程

git push origin "master"  

除了單個文件

從 development 到 testing

git checkout developmentgit pullcheckout testinggit checkout development public/doc/UserGuide.pdf git statusgit commit -a -m '手工合并'git push  

從 testing 到 staging

git checkout staginggit pullgit checkout testing public/doc/UserGuide.pdf git commit -a -m '手工合并'git push

從 stage 到 master

git checkout mastergit pullgit checkout staging public/doc/UserGuide.pdf git commit -a -m '手工合并'git push

合并分支解決沖突

案例，例如我們從 testing 分支向 master 分支合并代碼出現(xiàn)沖突，該如何解決呢？

首先，兩個分支拉取最新代碼

neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git checkout testingneo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git pull    neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git checkout masterneo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git pull

然后合并分支，從 testing 分支向 master 合并

neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git merge --no-ff testing自動合并 neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java沖突（內(nèi)容）：合并沖突于 neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java

自動合并失敗，修正沖突然后提交修正的結果。			
			
					

出現(xiàn)沖突，編輯沖突文件

						
vim neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java
			
					

保存后重看狀態(tài)

neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git status位于分支 master您的分支與上游分支 'origin/master' 一致。
您有尚未合并的路徑。  （解決沖突并運行 "git commit"）  （使用 "git merge --abort" 終止合并）
要提交的變更：  修改：neo-admin/src/main/resources/application-prod.yml  修改：neo-admin/src/main/resources/application-test.yml  修改：neo-common/src/main/java/com/neo/common/enums/IncarAttachTypeEnum.java  修改：neo-incar/src/main/java/com/neo/incar/service/impl/IncarAttachServiceImpl.java
未合并的路徑：  （使用 "git add <文件>..." 標記解決方案）  雙方修改：neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java  

將合并的文件添加到 git

neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git add neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.javaneo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git status                                                                位于分支 master您的分支與上游分支 'origin/master' 一致。
所有沖突已解決但您仍處于合并中。  （使用 "git commit" 結束合并）
要提交的變更：  修改：neo-admin/src/main/resources/application-prod.yml  修改：neo-admin/src/main/resources/application-test.yml  修改：neo-common/src/main/java/com/neo/common/enums/IncarAttachTypeEnum.java  修改：neo-incar/src/main/java/com/neo/incar/service/impl/IncarAttachServiceImpl.java  修改：neo-incar/src/main/java/com/neo/incar/utils/PaperlessConfig.java  

提交代碼

neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git commit -a -m '手工合并分支 testing -> master'[master 3652bf8e] 手工合并分支 testing -> master        

推送代碼

neo@MacBook-Pro-Neo ~/workspace/api.netkiller.cn % git push枚舉對象中: 1, 完成.對象計數(shù)中: 100% (1/1), 完成.寫入對象中: 100% (1/1), 240 字節(jié) | 240.00 KiB/s, 完成.總共 1（差異 0），復用 0（差異 0），包復用 0remote: remote: To create a merge request for master, visit:remote:   http://192.168.30.5/netkiller.cn/api.netkiller.cn/-/merge_requests/new?merge_request%5Bsource_branch%5D=masterremote: To http://192.168.30.5/netkiller.cn/api.netkiller.cn.git   fcaefaf4..3652bf8e  master -> master

Hotfix / BUG 分支

Hotfix / BUG 分支與功能分支類似，都是用于存放 BUG，BUG分支會對應缺陷管理系統(tǒng)中的BUG ID，做到缺陷與代碼可溯源。

hotfix 分支的使用場景，生產(chǎn)環(huán)境發(fā)現(xiàn) bug 需要臨時修復，testing 上面有正在進行的項目，不能從 testing -> master 合并，這時可以從 master -> hotfix 創(chuàng)建分支，修復和測試完成后合并到 master 分支，部署 production 環(huán)境。最后再將 hotfix 合并到 development 分支

對于中小公司，團隊人數(shù)少的情況，可以不用建立 BUG 分支，可以在功能分支上完成修復，再合并到 development 分支。

前滾和后滾

突發(fā)情況，臨時決定撤掉某些功能，這是會用到前滾和后滾操作

后滾操作

后滾操作舉例

Timeline ----- [ 往期里程碑 ]  -----> [ 本次升級里程碑 ] -----> [ 未來升級里程碑 ]                                          ｜                                          V                  o----------o-----o----------o---------o-----o------------->                                       ^          ^     ^          ^         ^     ^         A功能      B功能   C功能     D功能     E功能    N功能      

在本次升級的里程碑中，有五個功能搭便車，這個五個功能是按照順序合并進來的，每次合并都可以找到對應的版本ID。

我們模擬一個場景，這五個功能是市場部的五個活動，現(xiàn)在由于各種原因，活動D這個功能需要撤掉，我們只需要找到 C功能的版本ID，將代碼恢復到 C功能，然后重新合并一次 E功能

后滾到 C，然后增加 E功能

Timeline ----- [ 往期里程碑 ]  -----> [ 本次升級里程碑 ] -----> [ 未來升級里程碑 ]                                          ｜                                          V                  o----------o-----o----------o---------o                                       ^          ^     ^          ^         ^         A功能      B功能   C功能     D作廢       E功能        

前滾操作

當撤掉的功能需要恢復時就是前滾操作

      Timeline ----- [ 往期里程碑 ]  -----> [ 本次升級里程碑 ] -----> [ 未來升級里程碑 ]                                          ｜                                          V                  o----------o-----o----------o---------o                                       ^          ^     ^          ^         ^         A功能      B功能   C功能     D功能     E功能        

前滾到任意提交版本

Timeline ----- [ 往期里程碑 ]  -----> [ 本次升級里程碑 ] -----> [ 未來升級里程碑 ]                                          ｜                                          V                  o----------o-----o----------o---------o-----o------------->                                       ^          ^     ^          ^         ^     ^         A功能      B功能   C功能     D作廢     E功能    N功能        

前滾后后滾常見操作

導出最后一次修改過的文件

有時我們希望把剛剛修改的文件復制出來，同時維持原有的目錄結構，這樣可能交給運維直接覆蓋服務器上的代碼。我們可以使用下面的命令完成這樣的操作，而不用一個一個文件的復制。

git archive -o update.zip HEAD $(git diff --name-only HEAD^)

導出指定版本區(qū)間修改過的文件

首先使用git log查看日志，找到指定的 commit ID號。

$ git logcommit ee808bb4b3ed6b7c0e7b24eeec39d299b6054dd0Author: 168 126.com>Date:   Thu Oct 22 13:12:11 2015 +0800
    統(tǒng)計代碼
commit 3e68ddef50eec39acea1b0e20fe68ff2217cf62bAuthor: netkiller Date:   Fri Oct 16 14:39:10 2015 +0800
    頁面修改
commit b111c253321fb4b9c5858302a0707ba0adc3cd07Author: netkiller Date:   Wed Oct 14 17:51:55 2015 +0800
    數(shù)據(jù)庫連接
commit 4a21667a576b2f18a7db8bdcddbd3ba305554ccbAuthor: netkiller Date:   Wed Oct 14 17:27:15 2015 +0800
    init repo                       導入 b111c253321fb4b9c5858302a0707ba0adc3cd07 至 ee808bb4b3ed6b7c0e7b24eeec39d299b6054dd0 間修改過的文件。          $ git archive -o update2.zip HEAD $(git diff --name-only b111c253321fb4b9c5858302a0707ba0adc3cd07)

回撤提交

首先 reset 到指定的版本，根據(jù)實際情況選擇 --mixed 還是 --hard

git reset --mixed 096392721f105686fc3cdafcb4159439a66b0e5b --orgit reset --hard 33ba6503b4fa8eed35182262770e4eab646396cd --                      git push origin --force --allorgit push --force --progress "origin" master:master

撤回單個文件提交

例如撤回 project/src/main/java/cn/netkiller/controller/DemoSceneController.java 到上一個版本

?  api.netkiller.cn git:(testing) git log project/src/main/java/cn/netkiller/controller/DemoSceneController.java
commit b4609646ee60927fe4c1c563d07e78f63ab106ea (HEAD -> testing, origin/testing)Author: Neo Chen Date:   Wed Nov 17 18:49:27 2021 +0800
    手工合并，臨時提交
commit bc96eb68ad73d5248c8135609191c51e258edf10Author: Tom Date:   Thu Oct 21 16:29:20 2021 +0800
    獲取激活場景
commit d564ea25bd556324f1f576357563a8ee77b3bdd9Author: Tom Date:   Thu Oct 21 15:15:26 2021 +0800
    獲取激活場景
commit d5a40165ad24a3a021fe58c6d78e0b7d97ab3cc5Author: Tom Date:   Thu Oct 21 14:43:16 2021 +0800
    新增場景角色增加
commit aa98662cb9e781e328ee3d5cec23af29c81050d9Author: Tom Date:   Thu Oct 21 09:55:29 2021 +0800
    新增場景角色增加
commit 140d22a8d4ea7fcc775d4372e8beb6d854831512Author: Jerry Date:   Sat Oct 16 15:27:30 2021 +0800
    場景接口修改
commit 2ddbb1ff933de663305db2396d99030c938c267aAuthor: Tom Date:   Fri Oct 15 10:55:30 2021 +0800  

只顯示最后五條記錄

?  api.netkiller.cn git:(testing) git log -5 project/src/main/java/cn/netkiller/controller/DemoSceneController.java                      

      ?  api.netkiller.cn git:(testing) git reset bc96eb68ad73d5248c8135609191c51e258edf10 project/src/main/java/cn/netkiller/controller/DemoSceneController.javaUnstaged changes after reset:M  project/src/main/java/cn/netkiller/controller/DemoSceneController.java                      

      ?  api.netkiller.cn git:(testing) ? git statusOn branch testingYour branch is up to date with 'origin/testing'.
Changes to be committed:  (use "git restore --staged ..." to unstage)  modified:   project/src/main/java/cn/netkiller/controller/DemoSceneController.java
Changes not staged for commit:  (use "git add ..." to update what will be committed)  (use "git restore ..." to discard changes in working directory)  modified:   project/src/main/java/cn/netkiller/controller/DemoSceneController.java
?  api.netkiller.cn git:(testing) ? git add project/src/main/java/cn/netkiller/controller/DemoSceneController.java?  api.netkiller.cn git:(testing) ? git commit -m '恢復到上一個版本'[testing 9959acd4] 恢復到上一個版本 1 file changed, 6 insertions(+), 8 deletions(-)  

提交代碼怎樣寫注釋信息

將任務ID寫在代碼提交注釋信息當中，可以實現(xiàn)代碼與任務的綁定，我們在項目平臺上查看代碼的時候，可以直接點擊編號跳到對應的任務。這樣便清晰的直到本次提交對應的任何和需求文檔，便于代碼溯源。

Fixed Bug

svn ci -m "- Fixed bug #53412 (your comment)"                Implemented        svn ci -m "- Implemented FR #53271, FR #52410 (Building multiple XXXX binary)"                        Add        svn ci -m "- Add Feature #534 (your message)"

升級與發(fā)布相關

分支與版本的關系

各種版本來自與那個分支，它們的對應關系是什么？

分支與版本的關系：

1. Alpha 內(nèi)部測試環(huán)境，面向測試人員，不穩(wěn)定版本。來自 testing 分支

2. Beta / Preview / Unstable 新特性，預覽版，面向用戶體驗。來自 staging 分支

3. Stable = Release 穩(wěn)定版，發(fā)行版來自 master/main 以及 tag 標簽

分支與標簽的區(qū)別

分支與標簽的區(qū)別是，分支中的代碼可以修改，標簽可以視為只讀分支。

Release Notes

Release Notes 撰寫說明

當一個項目升級時，需要寫一個文檔紀錄這次變動

1. 內(nèi)容包括

2. 新增了什么

3. 更改了什么

4. 修復了什么

5. 未解決得問題

6. 改善了什么

7. 忽略了什么

常用信息類型

			
New
Changed
Fixed
Unresolved
Improved
Ignore
			
			

例?1.3.?Example - Release Notes

				
NEW - xxxxxxxxxxxxx
CHANGED - xxxxxxxxxxxxx
FIXED - xxxxxxxxxxx
UNRESOLVED - xxxxxxxxx
IMPROVED - xxxxxxxxx
				
				

你也同樣可以參考很多開源組織編寫的Release Notes，例如apache, mysql, php 等等

License

使用開源軟件需要知道各種 License 區(qū)別，以免出現(xiàn)法律糾紛。

GPL 你可以免費使用，但修改后必須開源。

GPLv3 你可以免費使用，但修改后必須開源，不允許加入閉源商業(yè)代碼。

BSD 你可以免費使用，修改后可不開源，基本上你可以我所欲為。

Linux 中有許多BSD代碼，但BSD卻不能移植Linux 代碼到BSD中，這是因為GPL License。

http://www.apache.org/licenses/