修改文件编码

gitflow.md

-# 分支说明
-
-## 主分支
-
-主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master, pre, test, dev分支
-
-### master分支
-
-master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
-
-master分支只能从pre或者hotfix分支合并, 不能开发.
-
-
-### pre分支
-
-pre分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
-
-当pre分支上的代码已实现了产品文档中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
-
-因此，每次将pre分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。通常而言，“仅在发布新的可供部署的代码时才更新master分支上的代码”是推荐所有人都遵守的行为准则。
-
-pre分支只能从test或者hotfix分支合并, 不能开发.
-
-
-### test分支
-
-test分支是给qa准备的稳定测试版本， 这个版本的代码是可以提测的.
-
-当test分支代码通过qa测试后， 就可以将所有开发成果合并到pre分支上， 进行预发布准备了。
-
-
-### dev分支
-
-dev分支是给客户端联调用的开发版本, 这个分支的代码是可以参与客户端联调的.
-
-当dev分支代码通过客户端联调, 就可以将所有开发成果合并到test分支上， 开始提测.
-
-## 辅助分支
-
-辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。
-
-辅助分支包括：
-
-用于开发新功能时所使用的feature分支；
-
-用于辅助版本发布的release分支；
-
-用于修正生产代码中的缺陷的hotfix分支;
-
-用于工程师自己的独立分支需求的个人分支;
-
-以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。
-
-
-
-### feature分支
-
-使用规范：
-
-可以从pre分支发起feature分支
-
-代码必须合并回dev分支
-
-分支命名惯例： feature/*
-
-feature分支通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回pre分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
-一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
-
-
-
-### hotfix分支
-
-使用规范：
-
-可以从master分支派生
-
-必须合并回master分支,pre分支,dev分支
-
-分支命名惯例：hotfix/*
-
-除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
-当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
-这样做的显而易见的好处是不会打断正在进行的pre分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
-
-
-### 个人分支
-
-使用范围
-
-分支命名规范: {{username}}/feature/*
-
-必须通过pull request merge到dev分支
-
-
-
-
+# 分支说明
+
+## 主分支
+
+主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master, pre, test, dev分支
+
+### master分支
+
+master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
+
+master分支只能从pre或者hotfix分支合并, 不能开发.
+
+
+### pre分支
+
+pre分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
+
+当pre分支上的代码已实现了产品文档中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
+
+因此，每次将pre分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。通常而言，“仅在发布新的可供部署的代码时才更新master分支上的代码”是推荐所有人都遵守的行为准则。
+
+pre分支只能从test或者hotfix分支合并, 不能开发.
+
+
+### test分支
+
+test分支是给qa准备的稳定测试版本， 这个版本的代码是可以提测的.
+
+当test分支代码通过qa测试后， 就可以将所有开发成果合并到pre分支上， 进行预发布准备了。
+
+
+### dev分支
+
+dev分支是给客户端联调用的开发版本, 这个分支的代码是可以参与客户端联调的.
+
+当dev分支代码通过客户端联调, 就可以将所有开发成果合并到test分支上， 开始提测.
+
+## 辅助分支
+
+辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。
+
+辅助分支包括：
+
+用于开发新功能时所使用的feature分支；
+
+用于辅助版本发布的release分支；
+
+用于修正生产代码中的缺陷的hotfix分支;
+
+用于工程师自己的独立分支需求的个人分支;
+
+以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。
+
+
+
+### feature分支
+
+使用规范：
+
+可以从pre分支发起feature分支
+
+代码必须合并回dev分支
+
+分支命名惯例： feature/*
+
+feature分支通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回dev分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
+一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
+
+
+
+### hotfix分支
+
+使用规范：
+
+可以从master分支派生
+
+必须合并回master分支,pre分支,dev分支
+
+分支命名惯例：hotfix/*
+
+除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
+当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
+这样做的显而易见的好处是不会打断正在进行的pre分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
+
+
+### 个人分支
+
+使用范围
+
+分支命名规范: {{username}}/feature/*
+
+必须通过pull request merge到dev分支
+
+
+
+