有时有必要在整个存储库中保留有关源代码的反馈，例如，当接受其他开发人员的支持代码或连接到新项目时。
Github及其类似物中的审阅过程是围绕所做的更改构建的，在我们的案例中，在进行评论时，需要对整个系统代码的状态进行评论。
如何使用git本身执行此操作：修复review分支中的状态，然后在此分支的合并请求中保留您的注释。
通常，已经说明了该方法的本质，下面仅是一些细节。
问题
想象一下情况：他们给您一个包含代码的存储库，并征求您的意见。通常在这种情况下，注释会在单独的文档/任务/页面中汇合，等等，这不是很方便，因为：
- 随着开发的不断进行，注释在写作过程中可能会过时。
- 很难引用代码的各个部分；诸如Douglas / bar.js：4之类的引用对于在文档和代码之间不断切换非常不便。
- 与代码隔离，文档丢失的可能性很高。
系统代码审查方法
因此，我们需要执行以下操作：修复分支的状态以进行检查，然后将您的评论保留在该分支的合并请求中。
使用为笔记https://github.com/oktend/system-review-example准备的存储库示例，我们将执行以下步骤：
- 我们在存储库中找到要检查的状态（在检查时，这是开发人员中的最后一次提交）：https :
//github.com/oktend/system-review-example/commit/0514531a35edf19e7032eb49f45a98d019f83efe - 从选定状态分支到我们的系统审查分支，例如“ system-review / 1march2020-goodman”：https :
//github.com/oktend/system-review-example/tree/system-review/1march2020-goodman - , , "1march2020-goodman-issues":
https://github.com/oktend/system-review-example/tree/system-review/1march2020-goodman-issues - , , .
- merge request ( pull request) "system-review/1march2020-goodman-issues" -> "system-review/1march2020-goodman":
https://github.com/oktend/system-review-example/pull/1/files
:
https://github.com/oktend/system-review-example/network
merge request , .
, .
:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/review-1march2020-goodman.md
:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/foo.js
- github ( ), IDE, git.
, .
我完全承认我有可能重新发明了自行车，并且在这种情况下有更好的方法，那么我将不胜感激指出最佳方法。
这种方法的想法不是我发明的，而是由一个开发人员提出的，如果Artem表达了愿望，我将以作者的身份指出。