規範化的軟件項目演進管理--從 Github 使用提及

規範化的軟件項目演進管理

從 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 公共服務了。

國際上有：

• GitHub
• Bitbucket

國內有：

• 開源中國 git@osc

關於以上幾類服務的選擇，能夠參考以下規則：

• 若是想國際化，又有開放精神的，請選擇Github，僅對開源項目免費支持
• 若是想國際化，想創建私有項目的，請選擇Bitbucket，我的團隊能夠免費創建私人項目
• 若是想得到更多的私人項目的權限，請選擇 git@osc，支持1000個免費項目，不限制私有或公有。

因爲在 IT 界， Github 基本上成爲了程序員的精神聖地，成爲了git的代碼名，因此對於初入此門的用戶來講，最好也要在 「行業聖地」 安營紮寨。

只須要完成以下兩個步驟，就可使用 Github 提供的服務了：

• 註冊一個 Github 的帳號
• 建立一個 Github 項目主頁

而更高級的全球化 "碼農" 社交，還至少須要以下動做：

• Watch一個大牛的項目，時刻關注動態，緊跟步伐
• Fork一個項目，本身修改，成爲社區貢獻者

下面將以 Github 對具體對象，來說解如何使用git工具來

3   項目內容

• 可正常運行源代碼
• 項目簡介文檔-ReadMe

本文將以一個 Github 開源項目爲例子進行簡單講解。

本文 GitHub 項目示例

gt-java-sdk

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 項目以後，而後就是不斷地往裏面添加新特性，迭代維護了。

首代產品開發基本的流程以下：

1. 在master分支上開發出第一個可用的項目版本並提交
2. 打上tag並提交測試在ReadMe寫好發佈版本號及發佈特性 tag保證了開發和測試及其它人員描述對象的一致性,開發版和穩定版的tag有不一樣的命名方式
3. 針對具體的tag的源碼進行測試並書寫測試報告
4. 測試代碼，發現問題，重複（1～3）的步驟，直到最後測試經過後，準備發佈前，在ReadMe寫好發佈版本號及發佈特性
5. 給項目打上發佈版的tag，正式發佈此代碼
6. 部署人員將代碼部署到生產場景，上線運行

在修復問題的時候，有以下基本流程：

1. 發現bug，或者要增長新特性
2. 在當前分支的當前節點處新建一個dev分支並切換過去
3. 在dev分支上完成功能（一樣測試迭代到最後經過測試的「真正」完成）
4. 將dev分支合併到maser分支，並打上發佈tag

固然，上述流程只是一種最簡單經常使用的工做流，純粹是用來拋磚引玉。因爲git具備很大的靈活性，用戶徹底能夠根據項目複雜度，團隊規模來定義適合本身的工做流。

有興趣的同窗能夠搜索 「git 工做流」 或者 "git work flow" ，遵照這些工做流，對規範我的開發習慣或者增強團隊協做效率都是極其有幫助的。

6   總結

雖然大牛們老是告誡小白們，不要迷戀工具。可是不能否認，好的工具確實是表明了先進的生產力。

在熟悉了git/github以後，我的能夠獲得以下改變：

1. 再也不爲項目版本管理而煩惱
2. 作事永遠有後悔藥
3. 不用擔憂電腦硬盤掛掉
4. 可讓項目造成穩定的路線圖，整合碎片化的成果
5. 本身的智能成果獲得了積累
6. 本身的品牌也會有展示的平臺

但願更多的軟件版本管理的初學者們可以儘快的養成良好的版本管理系統和高效的版本管理手段，別的不說，至少有一點很是重要的做用就是：

可以保證讓軟件項目組全部的人描述一個項目對象時，精確的肯定是同一對象，這樣能夠少去不少麻煩，少去不少扯皮拉筋的沒必要要的衝突。

這應該是在羣體性軟件活動裏面，除了協做以外我的認爲最大的做用了—— 一個公正的物證平臺。

---

做者:	Harmo哈莫
做者介紹:	https://zhengwh.github.io
技術博客:	http://www.cnblogs.com/beer
Email:	dreamzsm@gmail.com
QQ:	1295351490
時間:	2015-10
版權聲明:	歡迎以學習交流爲目的讀者隨意轉載，可是請 【註明出處】
支持本文:	若是文章對您有啓發，能夠點擊博客右下角的按鈕進行 【推薦】