Git Flow详细介绍和使用

git-flow 的工作流程

当在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情，然而，如果在你的团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。

基本上你可以定义一个完全适合你自己项目的工作流程，或者使用一个别人定义好的。

在这章节中我们将一起学习一个当前非常流行的工作流程 git-flow。

什么是 git-flow？

一旦安装安装 git-flow，你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的，这就是我们的工作流程！

git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。

严格来讲，你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 git-flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。

安装 git-flow

最新的git bash已经支持，不用安装，或者使用 Sourcetree。

要了解安装 git-flow 细节，请阅读下面这个文档 official documentation。

在项目中设置 git-flow

当你想把你的项目 “切换” 到 git-flow 上后，Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。

话虽如此，git-flow 却存在一些限制。让我们开始在一个新的项目上初始化它吧，之后我们就会有所发现：

当在项目的根目录执行 “git flow init” 命令时（它是否已经包括了一个 Git 仓库并不重要），一个交互式安装助手将引导您完成这个初始化操作。听起来是不是有点炫，但实际上它只是在你的分支上配置了一些命名规则。
尽管如此，这个安装助手还是允许你使用自己喜欢的名字。我强烈建议你使用默认的命名机制，并且一步一步地确定下去。

分支的模式

git-flow 模式会预设两个主分支在仓库中：

  • master 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
  • develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。

这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。

让我们开始探索一些在现实应用中可能遇到的案例吧！

功能开发

对于一个开发人员来说，最平常的工作可能就是功能的开发。这就是为什么 git-flow 定义了很多对于功能开发的工作流程，从而来帮助你有组织地完成它。

开始新功能

让我们开始开发一个新功能 “rss-feed”：

概念

在这些命令的输出文本中，git-flow 会对刚刚完成的操作打印出一个很有帮助的概述
当你需要帮助的时候，你可以随时请求帮助。例如：

正如上面这个新功能一样，git-flow 会创建一个名为 “feature/rss-feed” 的分支（这个 “feature/” 前缀 是一个可配置的选项设置）。你已经知道了，在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
git-flow 也会直接签出这个新的分支，这样你就可以直接进行工作了。

完成一个功能

经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：

最重要的是，这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：

  1. 一个在更广泛的 “开发” 背景下的全面测试。
  2. 稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。

之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。

管理 releases

Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。

创建 release

当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：

请注意，release 分支是使用版本号命名的。这是一个明智的选择，这个命名方案还有一个很好的附带功能，那就是当我们完成了release 后，git-flow 会适当地自动去标记那些 release 提交。

有了一个 release 分支，再完成针对 release 版本号的最后准备工作（如果项目里的某些文件需要记录版本号），并且进行最后的编辑。

完成 release

现在是时候按下那个危险的红色按钮来完成我们的release了：

这个命令会完成如下一系列的操作：

  1. 首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
  2. 然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
  3. 为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
  4. 清理操作，版本分支会被删除，并且回到 “develop”。

从 Git 的角度来看，release 版本现在已经完成。依据你的设置，对 “master” 的提交可能已经触发了你所定义的部署流程，或者你可以通过手动部署，来让你的软件产品进入你的用户手中。

hotfix

很多时候，仅仅在几个小时或几天之后，当对 release 版本作做全面测试时，可能就会发现一些小错误。
在这种情况下，git-flow 提供一个特定的 “hotfix” 工作流程（因为在这里不管使用 “功能” 分支流程，还是 “release” 分支流程都是不恰当的）。

创建 Hotfixes

这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。

就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！

完成 Hotfixes

在把我们的修复提交到 hotfix 分支之后，就该去完成它了：

这个过程非常类似于发布一个 release 版本：

  • 完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。
  • 这个 hotfix 程序将被标记起来以便于参考。
  • 这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。

还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。

回顾一下

最后，在结束这个章节之前，我要再次强调几个重点。

首先，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。

其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。

记住，使用 git-flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。

上面的工作流程不涉及到代码评审过程，开发人员开发完就可以合并分支。但是如果合并分支之前需要进行代码评审，那么整个流程就变复杂，我们下面分析增加了代码评审情况下的工作流。

代码评审下的 git-flow 的工作流程

我们使用 Git Flow 来进行版本管理控制，它相对于 GitHub Flow 更适合在产品开发中快速迭代，这种代码管理模式应该已经广泛使用了。

另外，我们鼓励使用 Git 客户端 SourceTree，它集成了 Git Flow 的一些基本操作。如果严格遵循 Git Flow 的流程进行版本管理控制，那么我们只用管开始和结束一个 Feature/Release/Hotfix，基本上是不用手动 merge 分支的。

新功能开发流程
  1. 从 develop 分支创建 feature 分支；
  2. 开发调试完将 feature 分支提交到远程版本库；
  3. 提交 pull request 请求合并到 develop 分支；
  4. 相关负责人 code review 后如果同意合并后，删除远程 feature 分支，如果不同意，重新修改后再上传 feature 分支请求 pull request。
Pull Request

Pull Request是当功能开发者完成一个新功能后向项目维护者发送合并请求通知的机制。它的使用过程如下：

  1. 功能开发者可以通过Gitlab页面发送pull request
  2. 开发管理员自己或组织其他的团队成员审查、讨论和修改代码
  3. 开发管理员合并新增功能分支到develop分支，然后关闭pull request，并且可以选择删除新增分支
工作流程

1. 由开发管理员负责在Gitlab上创建空白的仓库，并clone到本地，在sourcetree的git flow菜单中选择初始化仓库，并push到远端。

2. 在Gitlab上设置保护分支，把master、develop分支保护起来，只有指定人可push。

3. 功能开发者clone代码到本地，先在sourcetree的git flow菜单中选择初始化仓库。

4. 然后再开始新建功能分支，进行开发工作。

5. 新功能开发全部完成或部分完成后，功能开发者把最新代码push到远端同样的新功能分支里，并在Gitflow发起pull request给开发管理员

6. 开发管理员review代码，选择合并代码到develop，并可选择删除已经合并的新功能分支

7. 当开发管理员处理完合并请求后，开发者,切换到develop分支，直接删除自己的本地分支及远程分支，不要点击完成(Finish Feature)，此时开发者pull远端develop分支最新代码即可，可忽视本地的push提醒。

8. release、hotfix分支和feature分支操作类似。

9. 不可点击完成新功能、完成发布版本、完成修复补丁，因为这样会导致自动合并代码到master或develop分支

Git Flow Release

到此为止，我们发现整个的工作流还算可以接受，但是执行 git flow release 的时候，会发现由于 Git Flow 总是假定我们合并的分支可以立即部署到生产环境，所以如果我们的工作流程符合这个过程，是很简单的。

但是更多的时候，我们会遇到同时开发可功能模块A、B、C，最终上线只上线A、C的情况，这种情况下，会涉及到版本会退的问题，这个时候 git flow 反倒是不方便使用了。

这种情况下，GitLab Flow 流程可能更适合我们的工作流程。

参考链接

Apache2/Httpd的目录浏览功能 列出的文件名不完整

Apache2 的目录浏览功能 列出的文件名不完整，修改设置参考如下：

参考链接

Android Studio Flamingo | 2022.2.1 Patch 2 配置Robolectric-3.8/4.3.1/4.5.1/4.6.1单元测试环境

一直通过 Android Studio 3.6.3/4.0/4.1/4.2配置Robolectric-3.8/4.3.1/4.5.1/4.6.1 Powermock-1.6.6单元测试环境 配置 Powermock 进行单元测试。

虽然配置起来稍显复杂，但是也是够用的。

但是当升级到Android Studio Flamingo | 2022.2.1 Patch 2 之后，内置的 Java 版本被升级到 Java 17 ，使用这个 Java 版本执行单元测试，会报错如下：

可是 Powermock 已经长时间没有新版本发布，没有及时跟进 Java 版本的更新。

当时引入 Powermock 的原因是为了解决静态函数的测试问题，但是从 Mockito 3.4.0 版本开始，Mockito 已经支持静态函数测试。

因此，完全可以只使用 Mockto 进行测试。

待测试代码如下:

测试代码如下：

参考链接

Google I/O 2023 - Flutter 3.10 发布，快来看看有什么更新吧

虽然本次 I/O 的核心 keynote 主要是 AI ，但是按照惯例依然发布了新的 Flutter 稳定版，不过并非大家猜测的 4.0，而是 3.10 ，Flutter 的版本号依然那么的出人意料。

Flutter 3.10 主要包括有对 Web、mobile、graphics、安全性等方面的相关改进，核心其实就是：

  • iOS 默认使用了 Impeller
  • 一堆新的 Material 3 控件袭来
  • iOS 性能优化，Android 顺带可有可无的更新
  • Web 可以无 iframe 嵌套到其他应用

继续阅读Google I/O 2023 - Flutter 3.10 发布，快来看看有什么更新吧

Android之FileProvider详解

简介

Android 7.0 之前，文件的 Uri 以 file:// 形式提供给其他 app 访问。

Android 7.0 之后，分享文件的 Uri 发生了变化。为了安全起见，file:// 形式的Uri 不能正常访问。官方提供了 FileProvider，FileProvider生成的Uri会以content://的形式分享给其他app使用。

content形式的Uri可以让其他app临时获得读取(Read)和写入(Write)权限，只要我们在创建 Intent 时，使用 Intent.setFlags() 添加权限。只要接收Uri的app在接收的Activity任务栈中处于活动状态，添加的权限就会一直有效，直到app被任务栈移除。

目的

在7.0 以前，为了访问 file:// 形式的 Uri，我们必须修改文件的权限。修改后的权限对所有 app 都是有效的，这样的行为是不安全的。content://形式的Uri让Android的文件系统更安全，对于分享的文件，接收方 app 只拥有临时的权限，减少了我们app内部的文件被其他 app 恶意操作的行为。

使用

创建FileProvider

在manifest文件<application>标签中添加pvodier标签，配置如下。

android:name指定Provider所在的位置。官方自带的FileProvider已经相当完善，所以我们不需要像Service、Broadcast一样自定义，直接使用自带的就行，直接输入privoder会自动出现提示。

android:authorities相当于一个用于认证的暗号，在分享文件生成Uri时，会通过它的值生成对应的Uri。值是一个域名，一般格式为<包名>.fileprovider。

android:exported设置为false，FileProvider不需要公开。

android:grantUriPermissions设置为true，这样就能授权接收端的app临时访问权限了。

设置共享目录

在res/xml中创建一个资源文件（如果xml目录不存在，先创建），名字随便（一般叫file_paths.xml）。

<paths>必须有1个或多个子标签，每个子标签代表要请求的私有文件目录。不同的子标签代表不同的目录类型。

在<provider>标签中添加<meta-data>子标签。

设置<meta-data>的属性android:name值为android.support.FILE_PROVIDER_PATHS,属性android:resouce的值为刚才我们创建的path文件名。

配置paths

<paths>的每个子标签必须有path属性，代表content Uris的路径。name不需要和path保持一样，只是一个名称。

子标签有以下几种。

files-path

代表内部存储的files目录，与Context.getFilesDir()获取的路径对应。

最终生成的Uri格式为：authorities/pathname/filename

示例：

cache-path

代表内部存储的cache目录，与Context.getCacheDir()获取的路径对应。

external-path

代表外部存储(sdcard)的cache目录，与Environment.getExternalStorageDirectory()获取的路径对应。

external-files-path

代表app的外部存储的根目录，与Context#getExternalFilesDir(String) Context.getExternalFilesDir(null)获取的路径对应。

external-cache-path

代表app外部缓存区域的根目录，与Context.getExternalCacheDir()获取的路径对应。

external-media-path

代表app外部存储媒体区域的根目录，与Context.getExternalMediaDirs()获取的路径对应。

注意： 这个目录只在API 21（也就是Android 5.0）以上的系统上才存在。

生成Content Uri文件

为了让其他app使用Content Uri，我们的app必须提前生成Uri。

这里注意获取目录，在配置paths时我们讲了，paths的子标签必须和获取目录的代码保持对应。这里我们用的是Context.getFilesDir(),所以paths文件中必须包含files-path子标签，不然别的app获取uri时会出现异常。

最终生成Uri是使用的FileProvider.getUriForFile()。第一个参数就是provider中设置的authorities属性值。

授权临时权限

分享一般只有这读取和写入2种权限，根据需要传入Intent.addFlags()中。

Uri传入Intent

有好几种传入的方式，根据不同的场景使用不同的方式。

为邮箱app分享附件文件

其他分享

使用Intent.setDate或Intent.setClipData()。

最后使用startActivity(intent)启动分享操作。

参考链接

Android之FileProvider详解

解决mysql导入数据文件过慢的问题

目前遇到一个问题，mysql 使用 source 命令导入  *.sql  数据文件时，运行的很慢，大概一秒钟插入一两百条左右的样子，对于大的文件来说这个太慢了。

1.登入mysql

2.查看mysql中对于参数 innodb_flush_log_at_trx_commit 的配置

3.修改

修改完成后在次执行相同的文件，200M大约200w+条的数据在1分钟左右。

对于该参数的不同值的说明：

1.innodb_flush_log_at_trx_commit参数为 0
        binlog_group_flush && thd_flush_log_at_trx_commit(NULL) == 0 条件成立，因此直接return了，那么这种情况下log_buffer_flush_to_disk函数不会调用，因此不会做redo刷盘。依赖master线程。
    2.innodb_flush_log_at_trx_commit参数为 1
        !binlog_group_flush || thd_flush_log_at_trx_commit(NULL) == 1 返回为1即为True，因此调用log_buffer_flush_to_disk(True)，因此需要做redo刷盘，也要做sync。
    3.innodb_flush_log_at_trx_commit参数为 2
        !binlog_group_flush || thd_flush_log_at_trx_commit(NULL) == 1 返回为0即为Flase，因此调用log_buffer_flush_to_disk(Flase)，因此需要做redo刷盘，不做sync。依赖OS的刷盘机制。

参考例子如下：

实际测试结果感觉还是不够快。

参考链接

Unable to find a target named `RunnerTests` in project `Runner.xcodeproj`, did find `Runner`

Flutter 2.x 升级到 3.10.1 版本之后，原来正常编译的项目，iOS环境下（Xcode Version 13.2.1 (13C100)），编译报错：

继续阅读Unable to find a target named `RunnerTests` in project `Runner.xcodeproj`, did find `Runner`

Thymeleaf调用Spring的Bean的函数

问题见：https://stackoverflow.com/questions/53803497

为什么按照官网上的写法调用@Bean报错：EL1057E: No bean resolver registered in the context to resolve access to bean

有时候我们希望自己去通过thymeleaf进行解析文本，调用自定义的函数。比如

如果我们在模板里使用了 ${@beanName.method()}，此时会报错：

但是如果我们是通过模板进行MVC页面渲染就不会报错，其实原因就是因为此时的context里缺少了spring的Beans的信息，通过spring mvc渲染时，框架会加入这些信息。那么手动渲染时我们也添加Beans的信息就可以了。

此时在进行渲染就正常了。

如果想更接近 Spring MVC 解析逻辑的，参考如代码：

参考链接