Git存储库有哪些分支策略/工作流程？

#1 楼

Atlassian网站比较了与Git有关的不同工作流程策略。存在更多的策略，例如Linux Kernel团队使用的策略，但与大多数组织无关。

最常用的工作流类型是-



集中化-每个更改都使用单个分支添加。

功能分支-每个更改都添加到其自己的分支上，并考虑合并到中央分支中以进行集成。

Gitflow-基于功能分支工作流程，但还添加了另一个分支来发布稳定版本，并在该稳定版本分支上添加了一堆用于修补程序的分支。

派生-在OSS项目中，通常整个项目都是复制到另一个存储库中，并将更改合并到多个公共存储库之间，或者不进行合并，但仍可供公众使用。

根据组织的不同，其中之一可能更合适。


集中式-非限制性，允许每个人通过推动更改，最少的开销和流程来射击任何人以“破坏构建”不断发展。优点是，即使不起作用，变更也可以持续集成。
功能分支-允许任何人通过添加一些开销过程来添加变更，但是集成到主要协作工作中是受控制的过程。具有在合并请求被遗忘或未参加的情况下延迟整合变更的缺点。
Gitflow-管理各个分支机构的巨额管理费用，给只想将其变更带入分支机构的普通人造成很多混乱。当大多数开发人员只看到其中的“功能分支”部分时，它可以很好地工作。开发部门和稳定部门之间的合并通常会发生得很晚，并且集成并非易事。增加了每个人都必须理解的许多额外开销和术语。
分叉-狂野的西部，需要一台支持每用户管理多个存储库和存储库的服务器（GitHub，GitLab，BitBucket服务器等）。允许每个贡献者有最大的自由去做他想做的任何事情，但是不强迫整合。要求集成要零散地进行，并且必须经常通过跨存储库使用拉取请求来进行高度控制。在无组织的团队（例如OSS项目贡献者）中运作良好。

#2 楼

您可以阅读有关git最佳实践的书：https://git-scm.com/book/en/v2

项目中某些git策略的示例：


创建名为任务，功能/ XXX-1的分支
发送任务进行审查
如果未审查，请修复并再次审查
如果审查，请进行测试
如果进行测试未通过，已修复，并再次进行了检查/测试

首次检查：

git pull dev
git checkout -b feature/XXX-1
git add .
git commit -m 'XXX-1 My task'
git push origin feature/XXX-1

如果需要在检查后修复：

/>

git push origin :feature/XXX-1
git reset --soft HEAD~1
git add .
git commit -m 'XXX-1 My task fix'
git push origin feature/XXX-1