mirror of
https://github.com/PGYER/codefever.git
synced 2026-06-03 15:39:55 +08:00
d3de96487f
* fix(Useless Code): remove useless code * feat(Deploy Scripts): add deploy scripts * fix(Delopy Script): change settings * fix(Deploy Script): fix ssh-keygen script * fix(Deploy Script): change env file path * feat(Deploy Script): add db migration * fix(Deploy script): change script * feat(Deploy Script): add sql file to create database * fix(Deploy Script): add composer support * fix(Deploy Script): add composer * fix(Service Script): add http gateway * fix(Deploy Script): add git path * fix(Deploy Script): fix setting bugs * fix(Init Script): get user from config * fix(Service): adjust run users * feat(Doc): add doc * fix(Doc): change docs * fix(Deploy script): change owner of storage path * feat: codefever-community documentation system * fix(Doc): doc details page style * feat: fix page navigation * fix(SQL File): fix db file fit MySQL 5.7 * fix(FileTree): empty repository display * fix: fix helper navigation * docs(zh-cn essential part): * fix(Doc Style): change markdown.css * docs(contribution doc): * fix: unified page style * docs(Readme): add readme * build(Build): Co-authored-by: cubic <carneywu@pgyer.com> Co-authored-by: pololi <pololi@pgyer.com> Co-authored-by: yangchen <chenyang@pgyer.com>
32 lines
3.6 KiB
Markdown
32 lines
3.6 KiB
Markdown
# 何选择 Git 工作流 ?
|
||
|
||
选择 `CodeFever` 则相当于选择了 `分布式` Git 工作流程, 常见的分布式流程有 `集中式工作流` , `集成管理者工作流` 和 `主管副主管工作流` 每一种工作流都有自己的特点, 这里需要根据自己项目的特点来判断。
|
||
|
||
`CodeFever` 提供了 `分支` , `合并请求` 和 `Fork` 功能，因此可以轻松支持这三种工作流。
|
||
|
||
### 集中式工作流
|
||
|
||
集中式系统中通常使用的是单点协作模型——集中式工作流。 一个中心 `仓库`, 可以接受代码, 所有人将自己的工作与之同步。 若干个开发者则作为节点, 即中心仓库的消费者与中心仓库同步。
|
||
|
||
这意味着如果两个开发者从中心仓库克隆代码下来, 同时做了一些修改， 那么只有第一个开发者可以顺利地把数据推送回共享服务器。 第二个开发者在推送修改之前， 必须先将第一个人的工作合并进来， 这样才不会覆盖第一个人的修改。 这和 Subversion （或任何 CVCS）中的概念一样, 而且这个模式也可以很好地运用到 Git 中。
|
||
|
||
如果在公司或者团队中, 你已经习惯了使用这种集中式工作流程, 完全可以继续采用这种简单的模式。 只需要搭建好一个中心仓库, 并给开发团队中的每个人推送数据的权限, 就可以开展工作了。Git 不会让用户覆盖彼此的修改。
|
||
|
||
当然这并不局限于小团队。 利用 Git 的分支模型, 通过同时在多个分支上工作的方式, 即使是上百人的开发团队也可以很好地在单个项目上协作。
|
||
|
||
### 集成管理者工作流
|
||
|
||
Git 允许多个远程仓库存在, 使得这样一种工作流成为可能: 每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。 这种情形下通常会有个代表“官方”项目的权威的仓库。 要为这个项目做贡献, 你需要从该项目克隆出一个自己的公开仓库, 然后将自己的修改推送上去。 接着你可以请求官方仓库的维护者拉取更新合并到主项目。 维护者可以将你的仓库作为远程仓库添加进来, 在本地测试你的变更, 将其合并入他们的分支并推送回官方仓库。
|
||
|
||
这是 GitHub 和 GitLab 等集线器式（hub-based）工具最常用的工作流程。人们可以容易地将某个项目派生成为自己的公开仓库, 向这个仓库推送自己的修改, 并为每个人所见。 这么做最主要的优点之一是你可以持续地工作, 而主仓库的维护者可以随时拉取你的修改。 贡献者不必等待维护者处理完提交的更新——每一方都可以按照自己的节奏工作。
|
||
|
||
### 主管与副主管工作流
|
||
|
||
这其实是多仓库工作流程的变种。 一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式。 被称为 `副主管（lieutenant）` 的各个集成管理者分别负责集成项目中的特定部分。 所有这些副主管头上还有一位称为 `主管（dictator）` 的总集成管理者负责统筹。 主管维护的仓库作为参考仓库, 为所有协作者提供他们需要拉取的项目代码。
|
||
|
||
这种工作流程并不常用, 只有当项目极为庞杂, 或者需要多级别管理时, 才会体现出优势。 利用这种方式, 项目总负责人（即主管）可以把大量分散的集成工作委托给不同的小组负责人分别处理, 然后在不同时刻将大块的代码子集统筹起来, 用于之后的整合。
|
||
|
||
|
||
|
||
> 详细请阅读参考文章: [分布式 Git - 分布式工作流程](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows)
|