規范化的軟件項目演進管理
從 Github 使用說起
1 前言
首先，本文的層次定位是：很基本很基礎的 Github 工具的入門級應用，寫給入門級的用戶看的。
基本上工作過幾年的人，下面描述的這些技能和思想，都應該被打磨成了一種習慣，或者說是標配的屬性了吧，已經不齒於列為 技能 了。但是因為筆者也菜鳥過，在學習這些技能，接受這些思想和培養這些習慣時走過不少彎路，同時也浪費了不少時間，所以想把這些經驗和教訓寫下來，給后來人學習時提供一點參考意見吧。
關於為什么要學會用 Github ，先用最朴素的比方來開頭的引子吧。
就拿年輕人置業買房來說，先不說房子的市場屬性和社會屬性的種種不好，單說它的好處：“房子（House）實際是一個家（Home）的實際物理載體，有了它之后，家庭或者個人的生活經歷能夠得到持續的積累和傳承，家里的用品和設備也能得到比較好的積累，而不是像 租房 打游戲戰的時候，每遷移一個地方就面臨着一大堆東西的舍棄，更不用說自己會花些心思在家的小細節裝飾和整體風格上做功課了”
Github 就是這樣，相當於給了你的智力成果一個房子，一個家，讓你在這上面不斷形成積累，而且會強化你這些碎片化的積累，最后形成氣候，同時因為是“家”，主人也會在情感上更加珍惜，更加的專注的投入，對細節進行打磨，這樣最后才可能做出精品。
2 准備工作
2.1 預備知識
-
- Git版本管理的基本理念
-
- 免費
- 分布式
- 版本控制系統
-
Git的客戶端管理工具 [1]
關於Git版本管理的基本理念，可以直接看官方文檔 [2] ,各國語言都有，自然也少不了中文 [3] ，但是建議英文好的同學，直接閱讀英文原版，這樣有助於理解命令。如果喜歡看出處的紙質教程的，國內也相應的出版物：《Git權威指南》 [4] 可以參考。
由於Git的理論和操作是屬於工具型的，最好的辦法就是多在項目中磨煉，熟練即可，其實常用的功能了並不多，上手也不難。
本文中使用的客戶端管理工具是：Linux平台下的git工具。
在Linux下安裝git客戶端很容易，只需要在機器聯網狀態下，使用如下命令即可：
sudo apt-get install git
如果在Linux Desktop里面需要可視化界面，則安裝：
sudo apt-get install gitk
| [1] | 《Git客戶端及圖形工具》 |
| [2] | 《GitBook-Pro》 |
| [3] | 《GitBook-Pro-中文》 |
| [4] | 《Git權威指南》 |
2.2 預備平台
在掌握了基本的git的版本管理理念之后，就需要實地操作了。所幸的是，對於普通的個人或者小團隊開發者，已經有成熟穩定的git公共服務提供商。普通開發者，不用去搭建git的服務器及服務管理系統，就可以輕松便捷的享受到git的遠端備份和協作服務了。
注意
如果是純粹的個人開發者，而且也沒有雲端備份和多人協作的需求人，直接在本地機器就安裝git客戶端就可以使用離線和git版本管理系統了。當然如果想自己搭建私有的git遠端倉庫服務器，由於git開源的特性，同樣也很容易獲得豐富的文檔和技術支持。
因為項目版本管理及項目交流協作的重要性，國內外已經有很多相當成熟的 git 公共服務了。
國際上有：
國內有：
- 開源中國 git@osc
關於以上幾類服務的選擇，可以參考如下規則：
- 如果想國際化，又有開放精神的，請選擇Github，僅對開源項目免費支持
- 如果想國際化，想建立私有項目的，請選擇Bitbucket，個人團隊可以免費建立私人項目
- 如果想獲得更多的私人項目的權限，請選擇 git@osc，支持1000個免費項目，不限制私有或公有。
由於在 IT 界， Github 基本上成為了程序員的精神聖地，成為了git的代碼名，所以對於初入此門的用戶來說，最好也要在 “行業聖地” 安營扎寨。
只需要完成如下兩個步驟，就可以使用 Github 提供的服務了：
- 注冊一個 Github 的賬號
- 創建一個 Github 項目主頁
而更高級的全球化 "碼農" 社交，還至少需要如下動作：
- Watch一個大牛的項目，時刻關注動態，緊跟步伐
- Fork一個項目，自己修改，成為社區貢獻者
下面將以 Github 對具體對象，來講解如何使用git工具來
3 項目內容
- 可正常運行源代碼
- 項目簡介文檔-ReadMe
本文將以一個 Github 開源項目為例子進行簡單講解。
本文 GitHub 項目示例
3.1 源碼
這個的重要性就自然不用說了。既然是開啟了代碼項目，項目就一定會有它的作用。
一般是如下一個或者幾個作用：
- 個人興趣練手
- 存儲和記錄某些信息，比如文檔
- 為某個需求提供生產力
- 提供某種功能的開源解決方案，服務大眾
- 其它。。。
IT界流傳過這樣一句極端的話： 不產生生產力的代碼實際上和垃圾沒有什么區別 。 這句話有些極端，畢竟有時候出於學習和興趣的代碼也其實也有它的存在意義的。總之，話不多說，這些話不管極端還是中肯，其實主要是表達一個意思：你要讓做的事情有它的價值，你才會有動力長久維護下去，而一般情況下，源碼就是最基本的IT項目的價值體現載體。
示例項目中的價值體現就在於java的源碼項目，解決的問題就是：提供一種驗證服務的部署SDK。而且這個項目一直在隨着業務升級在不斷的迭代更新，已經部署到N多服務器上，持續的產生着生產力，所以有人Wathc,Star這些都不奇怪了。
3.2 項目簡介
項目簡介，就是項目源碼的 “配套” 設施。是一種最快速讓別人了解你項目的向導說明。在 Github 中的體現就是ReadMe。
這里面的項目簡介，還不是像wiki那樣的重試文檔系統，而是在項目根目錄下的 ReadMe 文本文檔。一般的Git的公共服務提供商，例如：Github ， Bitbucket 都會默認將項目根目錄下的 ReadMe 文件進行渲染，以主頁文檔的方式呈現出來。
項目簡介支持兩種渲染格式：
-
- Markdown
-
-
- 優點
-
語法簡單，上手容易，適合寫小型博客文摘
-
- 缺點
-
支持的語言特性有限，不太適合開發大型文檔系統
-
-
- RestructuredText
-
-
- 優點
-
語法特性豐富，適合小，中，大型文檔的系統開發
-
- 缺點
-
實現復雜高級的功能時上手的門檻也比較高
-
兩種寫文檔的方式的具體細節可以到網上查閱相應的語法即可，在此不再贅述。總之，熟練使用這兩種語言中的一種，可以使得寫文檔者以后就更多的關注於文檔的內容的產生，而不是格式的調整了。
個人比較偏愛 restructuredText 來寫ReadMe，主要原因如下：
- 天然支持生成目錄及文章錨點
- 支持文章內交叉引用
- 有比較友好的表格語法
- 很多很多的其它很強的語法特性
- 自己在開發大型文檔的時候都使用rst，所以就不用和markdown混用了
一個比較典型的ReadMe的內容應包括但不限於：
- 目錄
- 項目介紹
- 安裝方法
- 使用Demo
- 發布路線圖
具體可以參考示例項目的 ReadMe 的寫法。
4 常用功能
一個常見 Github 項目，常用的功能圖如下：
即：
- commits 提交記錄
- branches 分支
- release 發布版本
下面將針對每一塊進行詳細介紹。
4.1 commits
用戶在本地的工作空間里面為項目添加新功能或者修改bug，不斷的提交，更新項目的版本，這樣促使項目不斷的向前推進迭代。這些提交過程(commits)日積月累，就由git形成了穩定的提交線路圖。
原則上，用戶應該盡量勤快提交，因為這樣可以小步快速迭代，而且即使出了問題也可以在回滾的版本精確度也會更高：git可以將項目版本恢復到任何的納入版本管理的提交節點處。
4.2 branches
分支是git最重要的特性，這是項目要進行比較大的修改，而且要保證原分支特性能夠得到妥善管理時的一個重要功能。使用分支功能，可以很方便的看到產品的各種重要衍生階段和歸並階段，同時也極大的方便了開發者在這幾個分支之間進行切換。
針對此特性，還誕生了不少工作流，比較典型的分支工作流如下圖：
4.3 releases
在git中除了 分支branch 的概念外，還有 標簽tag 的概念。
通過tag的相應命令，為某個里程碑的可發布版本打上標簽，推送到 Github 上之后的體現形式就是在 relases 選項卡里面提供了tag的各種線路圖，直接打包成壓縮包文件供用戶統一下載。
當然此處也可以針對每個發布的節點標簽寫上發布日志，但是一般不建議這樣，因為這樣這些信息就存儲在 Github 信息系統里面了，而不是存儲在git項目里面了。一般建議將這些信息寫在ReadMe里面，這樣可以維持項目的完整性，同時也沒有丟失掉項目線路圖的具體迭代描述。
5 開發和維護基本過程
在開啟了自己的 Github 項目之后，然后就是不斷地往里面添加新特性，迭代維護了。
首代產品開發基本的流程如下：
- 在master分支上開發出第一個可用的項目版本並提交
- 打上tag並提交測試在ReadMe寫好發布版本號及發布特性 tag保證了開發和測試及其它人員描述對象的一致性,開發版和穩定版的tag有不同的命名方式
- 針對具體的tag的源碼進行測試並書寫測試報告
- 測試代碼，發現問題，重復（1～3）的步驟，直到最后測試通過后，准備發布前，在ReadMe寫好發布版本號及發布特性
- 給項目打上發布版的tag，正式發布此代碼
- 部署人員將代碼部署到生產場景，上線運行
在修復問題的時候，有如下基本流程：
- 發現bug，或者要增加新特性
- 在當前分支的當前節點處新建一個dev分支並切換過去
- 在dev分支上完成功能（同樣測試迭代到最后通過測試的“真正”完成）
- 將dev分支合並到maser分支，並打上發布tag
當然，上述流程只是一種最簡單常用的工作流，純粹是用來拋磚引玉。由於git具有很大的靈活性，用戶完全可以根據項目復雜度，團隊規模來定義適合自己的工作流。
有興趣的同學可以搜索 “git 工作流” 或者 "git work flow" ，遵守這些工作流，對規范個人開發習慣或者加強團隊協作效率都是極其有幫助的。
6 總結
雖然大牛們總是告誡小白們，不要迷戀工具。但是不可否認，好的工具確實是代表了先進的生產力。
在熟悉了git/github之后，個人可以得到如下改變：
- 不再為項目版本管理而煩惱
- 做事永遠有后悔葯
- 不用擔心電腦硬盤掛掉
- 可以讓項目形成穩定的路線圖，整合碎片化的成果
- 自己的智能成果得到了積累
- 自己的品牌也會有展現的平台
希望更多的軟件版本管理的初學者們能夠盡快的養成良好的版本管理系統和高效的版本管理手段，別的不說，至少有一點非常重要的作用就是：
能夠保證讓軟件項目組所有的人描述一個項目對象時，精確的確定是同一對象，這樣可以少去很多麻煩，少去很多扯皮拉筋的不必要的沖突。
這應該是在群體性軟件活動里面，除了協作之外個人認為最大的作用了—— 一個公正的物證平台。
| 作者: | Harmo哈莫 |
|---|---|
| 作者介紹: | https://zhengwh.github.io |
| 技術博客: | http://www.cnblogs.com/beer |
| Email: | dreamzsm@gmail.com |
| QQ: | 1295351490 |
| 時間: | 2015-10 |
| 版權聲明: | 歡迎以學習交流為目的讀者隨意轉載，但是請 【注明出處】 |
| 支持本文: | 如果文章對您有啟發，可以點擊博客右下角的按鈕進行 【推薦】 |