Git flow和Github

Question

我很难理解Git流是如何与Github一起工作的。

Github允许集成变更的叉/拉请求模型，其中整个上游回购及其所有分支都被复制到叉中。

然后，使用git流，我将从dev分支(比方说)分支分支，然后当完成时，我的更改将被合并到我的叉的dev分支中，而不是上游。因此，当请求返回上游回购时，它将merges (叉)合并到dev(上游)，但这就失去了对我的特性分支的所有知识，等等。

因此，要使Git流正常工作，我是否需要停止分叉回购，并在上游回购中直接创建功能分支？

那么叉/拉应该与git流分开吗？

Answer 1

那么叉/拉应该与git流分开吗？

是：

• 一个(Gitflow)是一个合并工作流 (从哪里合并到哪里)
• 另一个(GitHub叉/拉请求)是一个出版工作流程 (要推送的内容和位置)。

因此，关于工作流的亚特兰蒂斯教程有两个部分：

• 急流

​

​

• 分叉工作流

​

​

只想知道应该在上游还是分叉中使用git-flow。 在分叉中使用git流是没有意义的，因为当合并回上游回购时，您会丢失所有的信息。

确切地说:试图合并两个工作流是没有意义的，因为这两个工作流都用于不同的需求：

• gitflow：对Git的公共访问，所有开发人员都可以在其中推动(并且必须就分支和合并约定达成一致)。
• 分叉工作流：没有对一个常见回购的访问，因此需要一个叉子(一个开发人员拥有并可以推送的回购)，异步贡献通过拉请求返回到原始回购。