个人前端开发工做流 - 代码管理篇

代码管理

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