Git工作流差异

🗒️Git工作流差异

type

status

slug

date

Gitlab 和 Github flow

Gitlab Flow

about.gitlab.comWhat are GitLab Flow best practices?

What are GitLab Flow best practices?

Using these best practices, software development teams can use GitLab Flow to software development.

GitHubGitHub - jadsonjs/gitlab-flow: Shows the Gitlab flow workflow

GitHub - jadsonjs/gitlab-flow: Shows the Gitlab flow workflow

Shows the Gitlab flow workflow. Contribute to jadsonjs/gitlab-flow development by creating an account on GitHub.

about.gitlab.comWhat are GitLab Flow best practices?

What are GitLab Flow best practices?

Using these best practices, software development teams can use GitLab Flow to software development.

about.gitlab.comCombine GitLab Flow and GitLab Duo for a workflow powerhouse

Combine GitLab Flow and GitLab Duo for a workflow powerhouse

Add the AI-powered capabilities of GitLab Duo to GitLab Flow to boost the efficiency of DevSecOps workflows. This is a guide for deployment in your environment, including a video tutorial.

11 条最佳实践

分支管理：优先使用功能分支进行开发，避免直接在主分支提交，便于代码审查和保持主分支整洁。

测试范围：对所有提交（不仅是主分支上的）都进行测试，确保主分支始终通过测试，避免开发前重复测试主分支的低效行为。

测试执行：所有提交都需运行完整测试；若测试耗时超 5 分钟，可并行运行，包括开发和新版本相关的测试套件。

代码审查：合并到主分支前必须进行代码审查，且应尽早开展，以便及时发现并解决潜在问题。

自动部署：基于分支或标签实现自动部署，可通过创建生产分支等方式，替代手动或脚本部署。

标签设置：标签由用户手动设置，用于触发 CI 操作，而非由 CI 自动修改仓库；需详细指标时，通过服务器报告呈现新版本信息。

版本发布：以标签为依据创建新发布，保障开发环境的整洁与高效。

提交规范：已推送到公共分支的提交不应进行变基，以保证提交历史的真实性和可追溯性（特殊情况如代码审查后压缩提交可例外）。

分支流向：所有开发都从主分支开始，最终目标也是合并回主分支，避免出现长期存在的分支。

漏洞修复：先修复主分支的漏洞，再将修复内容挑选到发布分支，防止仅修复发布版本而忽略主分支的问题。

提交信息：提交信息需清晰反映修改的内容、原因，以及选择该方案的理由，助力代码审查和后续开发理解。

关键逻辑

在 Gitlab flow 中最主要的原则是上游优先 (Upstream first), 也就是只存在一个主分支 master, 它是所有分支的上游，只有通过测试之后才能往下游合并。

持续发布

在开发时，会从 master 另外建立分支做开发，当开发到一段落后，就会发 pull request (PR) 来 merge to master, 在发 PR 之后，会进行 code review、自动化测试…等等，通过后才可 merge 回 master, 接著再依序往下合并。

而如果在 production 环境中发生 bug, 则要再从 master 建立一个新的分支，修改完成后要先合并到 master, 通过 code review 及测试之后再使用 cherry-pick 依序往 pre-production、 production 分支合并。——merge 代码后，gitlab 在该 commit 提供快捷的 cherry-pick 操作

版本发布

Gitlab flow 对于版本发布的专案，建议是每一个稳定版本都要从 master 拉出新的分支，例如下图的 2-3 stable, 2-4 stable. 如果有 bug, 一样要再建立一个新的分支，修改完后一样要先合并到最上游的 master, 通过测试之后再合并到版本发布的分支，并且更新版本号。

GitHub Flow

master 分支永远是随时可部署发布的

需求新增基于 master 分支，并创建一个语义化分支

定期推送本地分支到远端

合并到 master 需要提 PR

PR 一旦经过 code review 无误后即可合并到 master

master 一旦接收到合并请求，即可立即部署发布

Git 分支策略 - AWS 规范性指导

查看 Trunk、 GitHub Flow 和 Gitflow 分支策略，然后选择最适合贵组织的策略。

https://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/choosing-git-branch-approach/git-branching-strategies.html

git Flow

分支类型	分支命名示例	来源分支	合并目标	用途说明	典型命令示例
`main` / `master`	`main` 或 `master`	无（初始化）	所有最终发布分支	用于部署生产环境，保持随时可发布状态	`git checkout maingit pull`
`develop`	`develop`	`main`	`main`	用于日常开发，集成所有 feature 分支变更	`git checkout developgit merge feature/xxx`
`feature` 分支	`feature/login-api`	`develop`	`develop`	开发新功能，按任务或模块分支命名	`git checkout -b feature/xxx develop`
`release` 分支	`release/1.0.0`	`develop`	`main`、`develop`	发布准备阶段，修复 bug、更新文档、生成 changelog 等	`git checkout -b release/1.0.0 develop`
`hotfix` 分支	`hotfix/fix-login`	`main`	`main`、`develop`	紧急修复生产环境 bug	`git checkout -b hotfix/fix-login main`
`bugfix` 分支	`bugfix/issue-123`	`develop`	`develop`	非紧急的 bug 修复，和 feature 同级别，归并回 develop	`git checkout -b bugfix/issue-123 develop`
`support` 分支	`support/v1.0-maint`	`main`	`hotfix` 等	旧版本长期维护分支（可选）	`git checkout -b support/v1.0-maint main`

cherry pick上面的差异

Git cherry-pick 会产生新的提交对象（commit hash）

即使 cherry-pick 的代码改动内容完全一样：

Git 仍然会 创建一个新的提交对象

因为新的提交有不同的：

提交时间（timestamp）
父提交（parent commit）
提交者信息（可能一样）
所以它的 commit hash 自然不同

个人理解，GitHub 的 pr cherry-pick 方便在各个分支之间流转

平台	Cherry-pick 后代码相同	Diff/对比视图是否显示该提交
GitHub	✅ 相同	❌ 不显示差异（只显示内容差异）
GitLab	✅ 相同	✅ 显示差异（按 commit hash）

GitHub 的 Pull Request 对比逻辑是基于内容和文件差异（patch-based diff）为主。

如果 cherry-pick 的提交内容和目标分支已有提交的内容完全一致，它会识别为冗余变更，因此不显示为变更项。

它重视实际代码行的 diff，而不是 commit hash。

其他

Git、GitHub、GitLab Flow，傻傻分不清？一图看懂各种分支管理模型

PHP配置跨域支持

AI Code 遇到的问题