GitFlow - 规范 git 操作流程
GitFlow 是由 Vincent Driessen 提出的一个 Git 操作流程标准。包含如下几个关键分支：
| 名称 | 说明 |
|---|---|
| master | 主分支 |
| develop | 主开发分支，包含确定即将发布的代码 |
| feature | 新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理，以避免一些后面不必要的代码冲突 |
| release | 发布分支，发布时候用的分支，一般测试时候发现的 bug 在这个分支进行修复 |
| hotfix | 热修复分支，紧急修 bug 的时候用 |
GitFlow 的优势有如下几点：
-
并行开发：GitFlow 可以很方便的实现并行开发：每个新功能都会建立一个新的 feature 分支，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的 feature 分支才会合并到主开发分支上（也就是我们经常说的 develop 分支）。另外，如果你正在开发某个功能，同时又有一个新的功能需要开发，你只需要提交当前 feature 的代码，然后创建另外一个 feature 分支并完成新功能开发。然后再切回之前的 feature 分支即可继续完成之前功能的开发。
-
协作开发：GitFlow 还支持多人协同开发，因为每个 feature 分支上改动的代码都只是为了让某个新的 feature 可以独立运行。同时我们也很容易知道每个人都在干啥。
-
发布阶段：当一个新 feature 开发完成的时候，它会被合并到 develop 分支，这个分支主要用来暂时保存那些还没有发布的内容，所以如果需要再开发新的 feature，我们只需要从 develop 分支创建新分支，即可包含所有已经完成的 feature 。
-
支持紧急修复：GitFlow 还包含了 hotfix 分支。这种类型的分支是从某个已经发布的 tag 上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的 tag，而不会影响到你正在开发的新 feature。
Glow flow 是如何工作的
新功能都是在 feature 分支上进行开发
image
feature 分支都是从 develop 分支创建，完成后再合并到 develop 分支上，等待发布。
image
当需要发布时，我们从 develop 分支创建一个 release 分支
image
然后这个 release 分支会发布到测试环境进行测试，如果发现问题就在这个分支直接进行修复。在所有问题修复之前，我们会不停的重复发布->测试->修复->重新发布->重新测试这个流程。
发布结束后，这个 release 分支会合并到 develop 和 master 分支，从而保证不会有代码丢失。
image
master 分支只跟踪已经发布的代码，合并到 master 上的 commit 只能来自 release 分支和 hotfix 分支。
hotfix 分支的作用是紧急修复一些 Bug。
它们都是从 master 分支上的某个 tag 建立，修复结束后再合并到 develop 和 master 分支上。
image
gitignore - 干掉那些干扰代码
为什么提到 gitignore，审过 PR（Pull request） 或者 MR（Merge request）的同学应该深有体会，当一个带着一大堆 Pods 库代码的 PR/MR 袭来的时候，你的内心应该是绝望的……所以我们要了解下怎么把一些非模块相关的代码 ignore 掉。
创建项目仓库中的 .gitignore
如果你在项目仓库内创建一个 .gitignore 文件，Git 会根据这个文件来决定哪些文件和目录是需要忽略的。
注意：如果你想把一个已经被跟踪的文件 ignore 掉，这是时候新增的规则并不会对这个文件产生作用，你需要先用下面的指令把这个文件设置为不跟踪：
git rm --cached FILENAME
创建全局的 .gitignore
这个其实没啥意思，不过还是看一下怎么设置吧：
git config --global core.excludesfile ~/.gitignore_global
iOSer 需要的 .gitignore
Github 官方模版给出的建议如下：
通过这个文件我们可以看到，忽略的内容主要包含下面几种：
-
构建产生的目录和文件；
-
各种临时配置文件；
-
Obj-C / Swift 相关的特定文件；
-
CocoaPods 第三方 Pods 库目录；
-
Carthage 构建目录；
-
fastlane 构建产生的文件；
-
代码注入工具产生的目录及文件。
-
我们可以根据自身项目的情况来对这些配置进行相应的调整和定制。
网友评论