個人前端開發工做流 - 代碼管理篇

代碼管理

Git

關於Git Workflow的討論不少，最著名的當屬Vincent Driessen的那篇博客A successful Git branching model。Vincent的工做流的結構很棒，首先有2個主要分支，master 和 develop，分別是主分支和開發分支。而後還有3類次分支，它們可能數量不少，而且不會長時間存在，分別是開發新功能用的feature，發佈用的release和修復bug用的hotfix。大體的Git操做能夠理解爲這樣：

# create branch
git checkout -b develop master
git checkout -b feature develop
# commit something
git add widget.js
git commit -m "add a function"
# merge to develop
git checkout develop
git merge --no-ff feature
# delete branch
git branch -d feature

首先建立開發分支 develop ，而後再從開發分支建立一個次分支，接着提交代碼並註釋提交，合併會開發分支 develop ，最後刪除這個臨時的次分支。--no-ff的意思是不使用快速合併。其餘開發過程當中也是大同小異，release分支還有hotfix分支可能須要在確認沒問題時合併到develop和master兩個分支中而後刪除。

不過這個工做流是考慮到團隊開發而設計的，很標準簡約，但細節不足。而Benjamin Sandofsky的文章Understanding the Git Workflow則更加趨向於對commit的管理，也許不能算作工做流，至少算是一種理念。他強調必定要保留有一個私人的分支只存在於本地，而後在合併到主分支時清除本來的commit log。這裏會用到一個 merge 命令的參數 --squash 這樣合併後不會帶來任何commit log。

# create brach
git checkout -b private master
# commit something
git add widget.js
git commit -m "add a function"
# merge brach but don't commit
git checkout master
git merge --squash private
# commit once
git commit -m "only this commit"

但我認爲Git工做流和其餘一切工程過程同樣，不存在銀彈。不過這種合併的方式能夠成爲一種很好的操做流來完成屬於每一個人本身的工做流。另外從這兩種不一樣風格的Git工做流中也許能找出一些有趣的點。如下是個人見解：

• 主分支數由開發流程複雜度決定，而開發流程複雜度應該由項目主管根據項目規模肯定，因此項目規模決定了主分支數，除了develop也許還須要test、build等等。
• 次分支數由人員和實際狀況決定，bug數會決定hotfix的數量，也許產品經理會決定feature的數量，多個不一樣版本的同類產品也可能會增長release的數量。若是項目規模足夠大時，幾個小組解決一個問題時也會產生多個臨時分支。
• 多人協做以及長時間開發均可能致使日誌混亂沒法管理，使用squash參數配合臨時分支能夠清理對別人沒必要要的commit信息。
• 應使用--no-ff能夠避免快速合併，使每次合併等於一次提交，記錄在log中，保持分支健康。

所以，在實際開發的工做流中應該按照實際狀況建立分支，但應按照以上規範合併分支。

Github

Github不止是每一個Coder的FaceBook，仍是一個很是棒的遠程Git倉庫，有不少小組將正式項目託管在上面。其實Github上和Git沒有太多差異，只是多了一個遠程倉庫Remote的操做，另外相信每一個初入Github的新手都爲私鑰公鑰頭疼了很久，下文將會討論Github的倉庫建立和平常操做兩部分。

首先須要在本地創建與Github賬戶的聯繫，在shell中安裝SSH，而後像這樣使用SSH安裝SSH密鑰(幫助文檔)：

ssh-keygen -t rsa -C "your_email@example.com"
# Creates a new ssh key, using the provided email as a label
# Generating public/private rsa key pair.
# Enter file in which to save the key (/c/Users/you/.ssh/id_rsa): [Press enter]
ssh-add id_rsa

而後會讓你輸入一個密碼，隨意輸入就能夠了，接着就會生成一個公鑰一個私鑰。在用戶文件夾下的 .ssh 文件夾中找到id_rsa.pub，這個文件裏就是公鑰，複製裏面的內容，而後在Github的Account Settings中的SSH Key頁面，點擊Add SSH Key按鈕，輸入一個用於說明的title，接着粘貼公鑰到Key中就能夠了。

而後必須在Github上點擊 Create a new repo 按鈕來建立一個空項目。固然若是選擇適當的選項就能夠自動生成README文件、Git忽略文件和版權分享聲明文件。以後該項目會有一個倉庫的地址，可使用HTTPS和SSH，甚至還有SVN地址：

https://github.com/<username>/<reponame>.git
git@github.com:<username>/<reponame>.git
https://github.com/<username>/<reponame>

以個人一個對話框jQ插件爲例，首先在項目中初始化git，而後添加一個遠程倉庫，而後就能夠往上面提交代碼了。

git remote add myGithub https://github.com/tychio/dialog.git
git push myGithub master

由於我使用的HTTPS方式提交，以後會須要輸入用戶名和密碼，若是使用SSH方式則使用公鑰而後會在連接時使用生成密鑰時的密碼。使用HTTPS純屬爲了記住Github的密碼，天天都在敲就不會忘記了。

總結

工做流應該是一我的最習慣和熟悉的流程，而不該該是照貓畫虎，邯鄲學步。仍是那句話，不存在銀彈，因此不會有萬用的工做流，只能從中汲取有用的實踐，完善改進本身的工做流，達到提升工做效率的目的。

和學習其餘技術同樣，應用於工做流之中的工具備無數種，但真正須要和適合的只有本身知道，發現問題，帶着問題尋找工具才能真的改進工做流。若是僅僅爲了使用前沿的工具而使用，只會使本身的工做效率大打折扣。記得兩年前我還在瘋狂的複製代碼，每當我意識到不能再這樣下去的時候，工做流就會本身進化，合適的工具近在眼前，工做效率逐漸提高。我發現問題實在是很好的老師，可讓一我的快速的成長，解決它就能夠得到一次提高。

永遠有人有跟你相同的問題，永遠有能解決你當前問題的工具，善於使用問題來選擇它們就能打造更完善的工做流。若是遇到沒有工具能解決的問題，那說明造輪子的時機到了。

---

個人前端開發工做流 系列文章：

• 環境篇
• 自動化篇
• 工具篇
• 代碼管理篇

原文博客http://www.tychio.net/tech/2013/09/25/improve-workflow.html