Git和Github：如何重组我们的Github和单个团队成员回购协议，以适应我们新期望的工作流程？

背景：

1） 我们是一个由六名初学者组成的团队，他们第一次尝试Git和Github

2） 我们在Github上创建了一个回购协议，然后我们所有人都克隆了它

3） 然后，我们各自制作了自己的本地功能分支，并开始制作我们的第一个功能

4） 现在我们发现了一个工作流，它使用两个永久分支（“主”和“开发”）和任意数量的从“开发”派生的功能分支（完成后返回）。

问题：

A） 让Github和团队回购从当前状态（“主”）转变为我们想要的（“主”和“发展”）的最佳方式是什么

B） 团队的每个成员应该设置什么样的跟踪？例如，我们都对Github上的“开发”保持最新感兴趣，这样我们就可以经常重新设置功能分支的基础

如果这是一个“愚蠢”的问题，谢谢你，对不起。我觉得答案就在眼前，但我没有信心，希望有经验的Git用户能给我一些帮助，最好是使用类似于我所说的工作流的用户。谢谢。

阅读，这篇文章很好地解释了如何与多个开发人员一起使用git管理您的项目。我相信这篇文章的摘要可以用这个图表来表示：

（来源：）

A） 让Github和团队回购从当前状态（“主”）转变为我们想要的（“主”和“发展”）的最佳方式是什么

这很容易。您当前的

master

分支相当于上图中的

develope

分支。因此，您只需要分支出一个

develope

分支，让您的开发人员使用它，而不是

master

B） 团队的每个成员应该设置什么样的跟踪？例如，我们都对Github上的“开发”保持最新感兴趣，这样我们就可以经常重新设置功能分支的基础

因此，就

develope

分支而言，您威胁它的方式与威胁

master

的方式相同。几乎没有什么区别。现在，

master

分支将是一个特殊的分支。它应该总是稳定的，随时可以被其他人下载。因此，您应该只向受信任的人数授予推送到

master

的权限（我不确定

git

是否为您提供推送权限，或者您只需告诉人们并希望他们遵守）。一个可以推到master的人将负责

master

分支中的任何更改

请注意，开发人员仍然可以发布

修补程序

并将其合并到

develope

，但他们应该让那些有特权的人将其与

主程序

合并

release

分支可以采用与

master

类似但限制较少的方法

---

至少有一种强制执行权限的方法是为

master

建立另一个存储库，开发人员可以在其中发出“拉取请求”，而有权限的人可以接受拉取。这实际上就是Linux内核的管理方式。在Linux内核中，有一个

master

存储库，由Linus自己管理。他的副手们维护着几个

develope

分支机构，他们不时向他发送“拉请求”。

我已经读过那篇文章（参见我的观点4）。这就是为什么我想要一个“大师”和一个“发展”分支。我的问题是如何从我目前的状况中达到这一点。