在我的组织中，我们从svn迁移到Enterprise github以获取源代码存储库。我们希望使用一种工具来管理代码审查，但是我们考虑使用Github问题，而不是在我们的CI-CD堆栈中再添加一个工具。
我们的存储库包含一个开发分支，所有开发人员都提交并推送他们的代码。构建和部署也通过开发分支进行。
许多人给我们的一个建议是使用一个临时分支，开发人员在其中签入代码，在该分支上进行代码审查，然后对开发分支执行拉取请求。我们不喜欢这种方法，因为它不必创建额外的拉取请求步骤。如果我们允许有限的开发人员执行拉取请求，则会在他们身上创建额外的瓶颈。如果每个人都有权执行拉取请求，开发人员将绕过审核流程并直接完成拉取请求。
所有这一切都说，我们中的一些人正在考虑将“Github问题”用于所有代码审查任务。在每个推送到开发分支，开发人员可以使用label = CodeReview创建问题。这是个好主意吗？
或者我们应该选择Crucible / Fisheye等解决方案
答案 0 :(得分：3)
您可以在开发过程中的任何时候打开拉取请求：当您很少或没有代码但想要分享一些屏幕截图或一般想法，当您遇到困难并需要帮助或建议时，或者当您准备有人审查你的工作。通过在Pull Request消息中使用GitHub的@mention系统，您可以询问特定人员或团队的反馈，无论他们是在大厅还是十个时区之外。
Pull请求对于贡献于开源项目和管理对共享存储库的更改非常有用。如果您正在使用Fork＆amp; Pull Model，Pull Requests提供了一种向项目维护者通知您希望他们考虑的更改的方法。如果您使用的是共享存储库模型，则Pull Requests帮助在合并到主分支之前启动代码审查和有关建议更改的对话。
讨论并审核您的代码
一旦拉开请求被打开，审核您的更改的人员或团队可能会有问题或意见。也许编码风格与项目指南不符，更改缺少单元测试，或者一切看起来都很棒，道具也是有序的。 Pull Requests旨在鼓励和捕获此类对话。
您还可以根据有关提交的讨论和反馈继续推送到您的分支机构。如果有人评论您忘了做某事或代码中有错误，您可以在分支中修复它并推送更改。 GitHub将在统一的Pull Request视图中显示您的新提交以及您可能收到的任何其他反馈。
合并和部署
一旦审核了Pull Request并且分支通过了测试，就可以将代码合并到主分支进行部署。如果要在GitHub上的存储库中合并之前进行测试，可以先在本地执行合并。如果您没有对存储库的推送访问权限，这也很方便。
合并后，Pull Requests会保留代码历史更改的记录。因为它们是可搜索的，所以任何人都可以及时回过头来理解为什么以及如何做出决定。
注意： 通过将某些关键字合并到Pull请求的文本中，您可以将问题与代码相关联。合并Pull请求后，相关问题也将关闭。例如，输入短语＃32将关闭存储库中的第32个问题。
答案 1 :(得分：0)
最好尝试采用GitHub思维模式，而不是试图坚持更熟悉的SVN工作流程。 GitHub规定了基于分支的GitHub Flow。目前这可能是一个疯狂的概念 - 但它会产生红利，以便按照设计的方式使用该工具。
如果每个人都有权执行拉取请求，开发人员会绕过审核流程并直接获取拉取请求。
虽然每个人都可以而且应该在各个分支机构中工作并创建拉取请求，但您可以强制执行审核。您有多种选择，例如：
除问题外，您可能还想探索GitHub Projects，这是一种可以用来组织问题，提取请求和备注的看板式电路板。