Github方法论？

Question

我对github有点新意，我想尝试一下，但是我对如何正确地做这件事感到有些困惑。

我希望拥有一个主要的回购，它几乎是实时版本的副本，我希望有一个开发回购（每周与主回购合并或不合并），开发人员可以解决开发回购自己的“叉子”我猜？

非常

1. 我希望有一种方法可以让一群开发人员处理主仓库开发版本的“克隆”。
2. 我希望开发版的“克隆”能够使用最新的开发回购进行轻松更新。
3. 我希望开发回购的“克隆”能够快速合并到开发回购中，所以例如如果我编辑一个css文件，并且开发repo添加了一堆新文件，它应该不需要一小时整理冲突。
4. 我希望开发回购能够快速合并到主回购中。

这样做最好的方法是什么？在SVN中，我只会使用一大堆分支（以及15小时的合并），但github似乎在分支方面令人困惑。

任何帮助？

Answer 1

您可以像使用SVN一样使用分支对流程进行建模......但更好，因为分支更容易制作，合并不那么令人愤怒。 Forks增加了另一层分离和访问控制。

只需在Github上拥有一个具有“实时”分支和“开发”分支的单个存储库即可。每个人都有权推动回购。开发人员在“开发”部门工作，有人被提名管理合并到“现场”。从SVN过渡时，这是一个很好的首次使用git，并保持集中式SVN工作流程，但它并没有真正利用Github或git。

接下来的技巧是习惯分支功能。当开发人员想要添加新功能或修复错误时，他们会为此目的进行“开发”分支，并且仅用于目的。可以将此分支推送到Github以允许其他开发人员参与。当它准备就绪时，功能分支进入“开发”。这使得开发人员可以在完成小型，尖锐的提交的同时协作处理功能。它使多个功能和错误修复不会混淆。它使得在查看历史记录时进行更改变得明显，因为它是更大特征分支的一部分。

然后你到了Github "fork and pull" model，这就是你真正利用git的时候。您使用“实时”和“开发”分支保留存储库，并继续使用功能分支，但不是对存储库具有推送访问权限，每个开发人员都会创建自己的存储库的分支，并在功能分支中进行工作。

当他们准备好时，他们send a pull request将他们的工作合并。此拉取请求是对工作进行审核，评论和可能改进的机会。拉取请求的主要优点是请求本身如何使用单词和代码成为关于合并的对话。这是最好的说明with an example。初始拉取请求包含两个提交，通过在选项卡中打开它们很容易查看。然后，当讨论代码并进行更多提交时，它们都会显示在请求中。甚至在差异内部进行讨论。这些拉取请求是进行代码对话的绝佳方式，它们是IMO Github的杀手级功能。