第一次发布

Git 使用规范流程.md

@@ -0,0 +1,186 @@
+# Git使用流程
+
+![](H:\开发环境部署\Git\使用流程.png)
+
+## 第一步：新建分支
+
+首先，每次开发新功能，都应该新建一个单独的分支（这方面可以参考[《Git分支管理策略》](http://www.ruanyifeng.com/blog/2012/07/git.html)）。
+
+> ```bash
+> # 获取主干最新代码
+> $ git checkout master
+> $ git pull
+> 
+> # 新建一个开发分支myfeature
+> $ git checkout -b myfeature
+> ```
+
+## 第二步：提交分支commit
+
+分支修改后，就可以提交commit了。
+
+> ```bash
+> $ git add --all
+> $ git status
+> $ git commit --verbose
+> ```
+
+git add 命令的all参数，表示保存所有变化（包括新建、修改和删除）。从Git 2.0开始，all是 git add 的默认参数，所以也可以用 git add . 代替。
+
+git status 命令，用来查看发生变动的文件。
+
+git commit 命令的verbose参数，会列出 [diff](http://www.ruanyifeng.com/blog/2012/08/how_to_read_diff.html) 的结果。
+
+## 第三步：撰写提交信息
+
+提交commit时，必须给出完整扼要的提交信息，下面是一个范本。
+
+> ```bash
+> Present-tense summary under 50 characters
+> 
+> * More information about commit (under 72 characters).
+> * More information about commit (under 72 characters).
+> 
+> http://project.management-system.com/ticket/123
+> ```
+
+第一行是不超过50个字的提要，然后空一行，罗列出改动原因、主要变动、以及需要注意的问题。最后，提供对应的网址（比如Bug ticket）。
+
+## 第四步：与主干同步
+
+分支的开发过程中，要经常与主干保持同步。
+
+> ```bash
+> $ git fetch origin
+> $ git rebase origin/master
+> ```
+
+## 第五步：合并commit
+
+分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。
+
+那么，怎样才能将多个commit合并呢？这就要用到 git rebase 命令。
+
+> ```bash
+> $ git rebase -i origin/master
+> ```
+
+git rebase命令的i参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。
+
+下面采用[Tute Costa](https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history)的例子，来解释怎么合并commit。
+
+> ```bash
+> pick 07c5abd Introduce OpenPGP and teach basic usage
+> pick de9b1eb Fix PostChecker::Post#urls
+> pick 3e7ee36 Hey kids, stop all the highlighting
+> pick fa20af3 git interactive rebase, squash, amend
+> 
+> # Rebase 8db7e8b..fa20af3 onto 8db7e8b
+> #
+> # Commands:
+> #  p, pick = use commit
+> #  r, reword = use commit, but edit the commit message
+> #  e, edit = use commit, but stop for amending
+> #  s, squash = use commit, but meld into previous commit
+> #  f, fixup = like "squash", but discard this commit's log message
+> #  x, exec = run command (the rest of the line) using shell
+> #
+> # These lines can be re-ordered; they are executed from top to bottom.
+> #
+> # If you remove a line here THAT COMMIT WILL BE LOST.
+> #
+> # However, if you remove everything, the rebase will be aborted.
+> #
+> # Note that empty commits are commented out
+> ```
+
+上面的互动界面，先列出当前分支最新的4个commit（越下面越新）。每个commit前面有一个操作命令，默认是pick，表示该行commit被选中，要进行rebase操作。
+
+4个commit的下面是一大堆注释，列出可以使用的命令。
+
+> - pick：正常选中
+> - reword：选中，并且修改提交信息；
+> - edit：选中，rebase时会暂停，允许你修改这个commit（参考[这里](https://schacon.github.io/gitbook/4_interactive_rebasing.html)）
+> - squash：选中，会将当前commit与上一个commit合并
+> - fixup：与squash相同，但不会保存当前commit的提交信息
+> - exec：执行其他shell命令
+
+上面这6个命令当中，squash和fixup可以用来合并commit。先把需要合并的commit前面的动词，改成squash（或者s）。
+
+> ```bash
+> pick 07c5abd Introduce OpenPGP and teach basic usage
+> s de9b1eb Fix PostChecker::Post#urls
+> s 3e7ee36 Hey kids, stop all the highlighting
+> pick fa20af3 git interactive rebase, squash, amend
+> ```
+
+这样一改，执行后，当前分支只会剩下两个commit。第二行和第三行的commit，都会合并到第一行的commit。提交信息会同时包含，这三个commit的提交信息。
+
+> ```bash
+> # This is a combination of 3 commits.
+> # The first commit's message is:
+> Introduce OpenPGP and teach basic usage
+> 
+> # This is the 2nd commit message:
+> Fix PostChecker::Post#urls
+> 
+> # This is the 3rd commit message:
+> Hey kids, stop all the highlighting
+> ```
+
+如果将第三行的squash命令改成fixup命令。
+
+> ```bash
+> pick 07c5abd Introduce OpenPGP and teach basic usage
+> s de9b1eb Fix PostChecker::Post#urls
+> f 3e7ee36 Hey kids, stop all the highlighting
+> pick fa20af3 git interactive rebase, squash, amend
+> ```
+
+运行结果相同，还是会生成两个commit，第二行和第三行的commit，都合并到第一行的commit。但是，新的提交信息里面，第三行commit的提交信息，会被注释掉。
+
+> ```bash
+> # This is a combination of 3 commits.
+> # The first commit's message is:
+> Introduce OpenPGP and teach basic usage
+> 
+> # This is the 2nd commit message:
+> Fix PostChecker::Post#urls
+> 
+> # This is the 3rd commit message:
+> # Hey kids, stop all the highlighting
+> ```
+
+[Pony Foo](http://ponyfoo.com/articles/git-github-hacks)提出另外一种合并commit的简便方法，就是先撤销过去5个commit，然后再建一个新的。
+
+> ```bash
+> $ git reset HEAD~5
+> $ git add .
+> $ git commit -am "Here's the bug fix that closes #28"
+> $ git push --force
+> ```
+
+squash和fixup命令，还可以当作命令行参数使用，自动合并commit。
+
+> ```bash
+> $ git commit --fixup  
+> $ git rebase -i --autosquash 
+> ```
+
+这个用法请参考[这篇文章](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)，这里就不解释了。
+
+## 第六步：推送到远程仓库
+
+合并commit后，就可以推送当前分支到远程仓库了。
+
+> ```bash
+> $ git push --force origin myfeature
+> ```
+
+git push命令要加上force参数，因为rebase以后，分支历史改变了，跟远程分支不一定兼容，有可能要强行推送（参见[这里](http://willi.am/blog/2014/08/12/the-dark-side-of-the-force-push/)）。
+
+## 第七步：发出Pull Request
+
+提交到远程仓库以后，就可以发出 Pull Request 到master分支，然后请求别人进行代码review，确认可以合并到master。
+
+（完）

Git使用规范.md

@@ -0,0 +1,95 @@
+# Git使用规范
+
+------
+
+本人在实际工作中总结出的Git使用规范，比较简单，容易落地。
+
+## 1. 分制管理
+
+开发过程主要存在以下分支：
+
+- **master**
+- **dev**
+- hotfix-[问题名称 | bug编号]
+- feature-[功能名称]
+- bugfix-[bug编号]
+- refactor-[重构名称]
+
+### 1.1 master 主分支
+
+```
+- master主分支始终保持稳定的可发布版本
+- 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）
+12
+```
+
+### 1.2 dev 开发分支
+
+```
+- dev开发分支为不稳定版本，可能存在功能缺失，但已有的功能必须是完整的
+- 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发
+12
+```
+
+### 1.3 hotfix-[问题名称 | bug编号] 紧急热修复分支
+
+```
+- 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于**生产线问题紧急修复**！！！！
+- 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除
+12
+```
+
+### 1.4 feature-[功能名称] 功能开发分支
+
+```
+- 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程
+- 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支
+12
+```
+
+### 1.5 bugfix-[bug编号] 问题修复分支
+
+```
+- 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号
+- 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支
+12
+```
+
+### 1.6 refactor-[重构名称] 重构分支
+
+```
+- 从dev分支创建，用于代码的**重大规模重构**（小规模重构创建feature分支即可）
+- 重构以后，必须经过严格测试通过，才能向dev分支合并。
+12
+```
+
+------
+
+## 2. Commit 提交规范
+
+### 2.1 commit提交的日志格式
+
+【**类型:描述**】，其中类型如下表所示
+
+| 类型     | 描述                         |
+| -------- | ---------------------------- |
+| feat     | feature，即新开发的功能      |
+| fix      | 问题修复                     |
+| refactor | 重构代码                     |
+| doc      | 增加文档（如readme），注释等 |
+
+例如：
+
+```text
+fix:修复身份证含字母X的用户无法注册问题
+fix: 紧急修复生产线用户积分不显示的问题
+feat:商品详情页功能
+doc:增加项目readme文档，修改结算条款结算逻辑的注释1234
+```
+
+### 2.2 Commit提交频率
+
+1. 每天下班前必须提交feature分支，并push到远程
+2. hotfix、feature、bugfix、refactor分支尽量按照功能点或修复重构的问题及时commit（不要求push）
+
+![](H:\开发环境部署\Git\Git使用规范.png)

Git分支管理策略.md

@@ -0,0 +1,154 @@
+# Git分支管理策略
+
+作者： [阮一峰](http://www.ruanyifeng.com/)
+
+日期： [2012年7月 5日](http://www.ruanyifeng.com/blog/2012/07/)
+
+如果你严肃对待编程，就必定会使用"[版本管理系统](http://www.ruanyifeng.com/blog/2008/12/a_visual_guide_to_version_control.html)"（Version Control System）。
+
+眼下最流行的"版本管理系统"，非[Git](http://git-scm.com/)莫属。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070501.png)
+
+相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。
+
+但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070502.png)
+
+[Vincent Driessen](http://nvie.com/)提出了一个分支管理的[策略](http://nvie.com/posts/a-successful-git-branching-model/)，我觉得非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用，Git只是用来举例而已。如果你不熟悉Git，跳过举例部分就可以了。
+
+**一、主分支Master**
+
+首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070503.png)
+
+Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
+
+**二、开发分支Develop**
+
+主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070504.png)
+
+这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
+
+Git创建Develop分支的命令：
+
+> 　　git checkout -b develop master
+
+将Develop分支发布到Master分支的命令：
+
+> 　　# 切换到Master分支
+> 　　git checkout master
+>
+> 　　# 对Develop分支进行合并
+> 　　git merge --no-ff develop
+
+这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070505.png)
+
+使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的[《Understanding the Git Workflow》](http://sandofsky.com/blog/git-workflow.html)。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070506.png)
+
+**三、临时性分支**
+
+前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
+
+但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
+
+> 　　* 功能（feature）分支
+>
+> 　　* 预发布（release）分支
+>
+> 　　* 修补bug（fixbug）分支
+
+这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
+
+**四、 功能分支**
+
+接下来，一个个来看这三种"临时性分支"。
+
+第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070507.png)
+
+功能分支的名字，可以采用feature-*的形式命名。
+
+创建一个功能分支：
+
+> 　　git checkout -b feature-x develop
+
+开发完成后，将功能分支合并到develop分支：
+
+> 　　git checkout develop
+>
+> 　　git merge --no-ff feature-x
+
+删除feature分支：
+
+> 　　git branch -d feature-x
+
+**五、预发布分支**
+
+第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
+
+预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
+
+创建一个预发布分支：
+
+> 　　git checkout -b release-1.2 develop
+
+确认没有问题后，合并到master分支：
+
+> 　　git checkout master
+>
+> 　　git merge --no-ff release-1.2
+>
+> 　　# 对合并生成的新节点，做一个标签
+> 　　git tag -a 1.2
+
+再合并到develop分支：
+
+> 　　git checkout develop
+>
+> 　　git merge --no-ff release-1.2
+
+最后，删除预发布分支：
+
+> 　　git branch -d release-1.2
+
+**六、修补bug分支**
+
+最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
+
+修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
+
+![img](http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070508.png)
+
+创建一个修补bug分支：
+
+> 　　git checkout -b fixbug-0.1 master
+
+修补结束后，合并到master分支：
+
+> 　　git checkout master
+>
+> 　　git merge --no-ff fixbug-0.1
+>
+> 　　git tag -a 0.1.1
+
+再合并到develop分支：
+
+> 　　git checkout develop
+>
+> 　　git merge --no-ff fixbug-0.1
+
+最后，删除"修补bug分支"：
+
+> 　　git branch -d fixbug-0.1
+
+（完）

README.md

@@ -1,3 +1,181 @@
-# githelp
+# 珠海智城Git使用规范
+
+![](H:\开发环境部署\Git\使用流程.png)
+
+## **一、基本规范**  
+
+1.1 主仓库必须由团队管理员建立团队仓库，即主仓库建在团队里，由管理员处理合并请求及合并代码；
+
+1.2 团队中建立管理组(admin)和设计组(dev)，设计组成员对仓库只读，设计组成员必须派生主仓库做为个人远程仓库，本地仓库基于远程个人仓库克隆到本地开发，并生成自已的版本分支进行开发；
+
+1.3 当确定一个版本或需要提交至主库的功能时需向主仓库提交合并请求，主库管理员及时做代码合并处理，本地仓库采用及时提交及时推送的习惯，确定版本后需要及时提交，不允许长期不做提交、不合并，需要保证多副本，多备份机制；
+
+1.4 对于个人调试的工具类或推荐的资料、不涉及公司机密的，可以采用公共方式发布自已的仓库，本着开源精神，由本人负责代码的完整性和有效性，也鼓励大家开发开源项目，但不允许将涉及公司业务的代码开源；
+
+1.5 对于完全开源的项目，大家需谨记不可在代码中保留有公司服务器连接的相关信息，如地址、端口、密码等。
+
+## **二、目录结构规范**  
+
+针对于每个项目保证目录统一，以方便代码管理，其中目录主要包括：Management、Document、Code、UI
+
+Management：该项目团队出开发以外的资料
+
+Document：整个项目实施过程中的文档，包括（需求，开发，测试）
+
+Code：项目源代码
+
+ UI：项目UI部分资料
+
+## **三、代码提交规范**  
+
+### 3.1 设置用户名为姓名全拼，邮箱为公司邮箱地址。
+
+### 3.2 代码提交流程
+
+(1) 代码修改完成后，首先进行编码规范检查，注释检查，自我测试，单元测试、编译测试等。
+
+(2) 测试通过后提交至本地，提交过程中检查修改的文件是否正确，有无遗漏文件等，注明修改说明后提交代码。
+
+(3) 拉取服务器上的代码，如果本地代码是最新的提交，则直接推送到服务器。如果拉取到别人提交的代码，则需合并服务器的代码到本地，并仔细检查代码合并结果，如有冲突则需要找到相应的编码人员一起解决冲突。问题解决后，重新编译本地代码，并测试，通过测试后提交本地代码。
+
+(4) 推送本地提交至服务器。服务器检测到有代码推送后会自行构建所有代码。
+
+### 3.3 日常工作流程
+
+(1) 每天早上开始工作前，请先拉取服务器代码，并编译，检查服务器代码是否有错误。检查无误后即可开始自己的工作。如果有误，请通知最后的代码提交者及项目负责人。
+
+(2) 理论上没修改一个完整的功能点都可以提交代码并推送至服务器（参考代码提交流程）。
+
+(3) 每天工作结束后或者下班前，请提交本地代码，并推送至服务器（代码提交流程）。
+
+### 3.4 代码提交说明规范
+
+(1) 使用中文或英文说明提交内容，但必须是正常人可以理解的。
+
+(2) 提交的说明包括两部分，动作类型: 简要说明，以英文的“: ”进行区分。
+
+(3) 动作类型使用英文大写
+
+(4) 理论上一次提交仅包含一个功能点修改，如果功能过大，则需要注明功能点进度。如果一次提交包含多个功能修改，则每个功能点提交描述作为单独一行，每行以英文分号";"作为行尾结束符。
+
+(5) ADD: [PluginFramework], 提交的内容信息。
+
+| **动作** | **说明**                                                     | **示例**                                                     |
+| -------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| ADD      | 新加功能、文件等                                             |                                                              |
+| DEL      | 删除功能、文件等                                             |                                                              |
+| MOD      | 修改功能                                                     |                                                              |
+| FIX      | 修复问题等，如果修复的为BUG，请标注BUG编码                   | FIX: BUG#123, bug's description;  FIX: BUG#124, bug's description; |
+| MERGE    | 合并代码，自动合并时一般不需要修改说明文字                   |                                                              |
+| REVIEW   | 代码审核注释，需注明审核结果(需使用中括号括起)、@被审核者、被审核模块名称、文件名 | REVIEW: [PASS], @zhanxy, for excel operation model           |
+| REFACTOR | 代码重构，需注明重构模块，及说明。一般重构需要使用新的独立分支处理。 |                                                              |
+| DOC      | 文档                                                         |                                                              |
+
+规范说明：
+
+1.用一空行分隔标题与正文。
+
+2.标题使用大写字母。
+
+3.标题不超过50个字符。
+
+4.标题使用祈使语气。
+
+5.标题不要使用句号结尾。
+
+6.正文在72个字符处换行。
+
+7.正文解释是什么和为什么，而不是如何做。
+
+
+
+示例：
+
+新增开放平台验证接口，Token支援多种调用方式，修复短信问题及删除废弃类
+
+ 
+
+1.Add 开放平台验证接口, /OAuth/access_token,/OAuth/refresh_token
+
+2.Mod Token类，修改为使用子类继承，支援多种Token调用
+
+3.Mod Timer类增加ACCESS_TOKEN_TIMER常量
+
+4.Fix 验证码短信文字乱码问题
+
+5.Del Model/UserType.php
+
+
+
+国际知名项目 angularjs 提交历史
+
+![](H:\开发环境部署\Git\示例1.png)
+
+我的提交历史：
+
+![](H:\开发环境部署\Git\示例2.png)
+
+纳尼？？？我都写了什么？？？
+
+
+
+## **四、分支管理规范**  
+
+开发过程主要存在以下分支：
+
+·     **master**
+
+·     **dev**
+
+·     hotfix-[问题名称 | bug编号]
+
+·     feature-[功能名称]
+
+·     bugfix-[bug编号]
+
+·     refactor-[重构名称]
+
+### 4.1 master 主分支
+
+```
+- master主分支始终保持稳定的可发布版本
+- 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）
+```
+
+### 4.2 dev 开发分支
+
+```
+- dev开发分支为不稳定版本，可能存在功能缺失，但已有的功能必须是完整的
+- 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发
+```
+
+### 4.3 hotfix-[问题名称 | bug编号] 紧急热修复分支
+
+```
+- 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于**生产线问题紧急修复**！！！！
+- 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除
+```
+
+### 4.4 feature-[功能名称] 功能开发分支
+
+```
+- 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程
+- 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支
+```
+
+### 4.5 bugfix-[bug编号] 问题修复分支
+
+```
+- 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号
+- 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支
+```
+
+### 4.6 refactor-[重构名称] 重构分支
+
+```
+- 从dev分支创建，用于代码的**重大规模重构**（小规模重构创建feature分支即可）
+- 重构以后，必须经过严格测试通过，才能向dev分支合并。
+```
+
+![](H:\开发环境部署\Git\Git使用规范.png)
 
-git使用规范及相关说明帮助文档

README.md.1

@@ -0,0 +1,3 @@
+# githelp
+
+git使用规范及相关说明帮助文档

基于git的代码版本管理规范及流程-简版.md

@@ -0,0 +1,51 @@
+# 基于git的代码版本管理规范及流程-简版
+
+ 基于git的简单实用的版本管理规范及流程，包括：代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。 
+
+# 代码库分类
+
+根据代码库分布的位置及作用，分为以下几类：
+
+- 主库：位于服务端，所有开发的代码最终都要合到主库。
+- 个人代码库（服务端）：从主库fork出来，位于服务端。每个人自已开发的代码，由本地的git库push到每个人自己的个人代码库（服务端），再由个人代码库（服务端）合入主加。
+- 个人工作库：位于每个开发人员的开发机器，从个人代码库（服务端）clone到本地。每个开发人员开发的代码，先commit到个人工作库，再由个人工作库push到个人代码库（服务端）。
+
+# 人员角色分类
+
+这里说的角色，都是人员在主库上的角色。基于简化的原则，人员分为三类：
+
+- Owner：拥有主库的所有权限。
+- Committer：具有将开发人员的合并需求（MR）合入主库的权限。基于安全考虑，我们设置为只能通过MR的方式将代码合入主库，而不能直接push到主库。
+- Developer：只能从自己的个人代码库（服务端）提交合并代码的请求（MR），是否能够合入，由Committer进行审核。
+
+# 基本流程
+
+在主库已经存在的情况下，日常操作流程如下：
+
+1. 开发人员从主库fork出自己的个人代码库。
+2. 开发人员将自己的个人代码库clone到本地，即个人工作库。
+3. 开发人员在开发了新代码后（包括新增和修改），先将代码commit到自己的个人工作库，再由个人工作库push到个人代码库。
+4. 开发人员提交从个人工作库到主库的MR，Committer审核后，决定是否将MR合入主库。
+5. 每个开发人员从主库pull最新代码到个人工作库。
+
+# 分支管理
+
+- 主库缺省的master分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
+- 主库除了master分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交MR到主库时，指向的是主库的活动分支。活动分支测试稳定后，将主库的活动分支通过MR的形式，合并到主库的master分支，同时打上tag。
+- 如果软件运行过程中发现必须立即修改的bug，则从主库的master分支中，拉出一个bugfix分支。为修复这个bug的所有开发，都基于bugfix分支。待bugfix分支开发完成，并测试稳定后，将bugfix分支以MR的方合入主库的master分支。然后删除bugfix分支，视情况决定是否打tag。
+
+
+
+## 活动分支合入主分支时发生冲突
+
+### 产生原因
+
+平时基于活动分支开发，如果这个过程中为了修复bug而拉了一个bugfix分支，当bugfix分支开发完成并合入master分支后，如果bugfix分支和活动分支修改了相同的文件，则在活动分支合入master分支时就会产生冲突。
+
+### 解决方法
+
+1. 从个人代码库（服务端）clone一个库到本地，即专门用于合并的个人工作库。（也可以用之前的个人工作库，但初学都容易混淆，建议单独clone一个。）
+2. 从主库的活动分支上pull最新的代码到本地。
+3. 从主库的master分支上pull最新的代码到本地。
+4. 此时会产生冲突，手工修复冲突，然后先commit到本地的个人工作库，再push到个人代码库（服务端）。
+5. 提交从个人工作库（服务端）到主库的MR（此时不会再有冲突），然后由Committer审核后将MR合入主库。