我的前端开发工作流代码管理篇

代码管理

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 ，最后删除这个临时的次分支。&＃8211;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信息。
• 应使用&＃8211;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//.git
git@github.com:/.git
https://github.com//


以我的一个对话框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