当Github提交来自pull-request/merge而不是直接提交时，我如何查看？
我们更喜欢使用GitHub的功能分支工作流(主要像github工作流)。我的职责之一是检查这是否整齐地完成了，但当我查看https://github.com/<our-org>/<repo>/commits/master时，我看不到任何界限，当提交是直接在repo上时，还是当PR被审查和接受时。
我绝对看不到将提交链接到or或类似的方法。这是可能的/容易的吗?我是不是在web UI上错过了它？
回答 1
Stack Overflow用户
发布于 2019-01-03 03:32:56
简单的答案是，你可以告诉Github禁止直接推送到master。这会让你的工作自动化。所有提交给大师的承诺必须来自公关。https://help.github.com/articles/about-protected-branches/
您还可以要求某些自动状态检查通过，然后才能合并PR，如自动代码审查和CI。https://help.github.com/articles/about-required-status-checks/
更复杂的答案..。
PR和其他提交没有什么明显的不同。但是，根据你如何合并你的PR和查看你的提交，将会有大量的线索。
git log和Github提交历史对你撒谎。Git历史是相互关联的提交，实际的分支如下所示。
A - B - F - G - H - I [master]
\ /
----C - D 每个字母都是一个提交。它们是相互联系的。代码库从A开始。[master]是一个“分支标签”，但它实际上只是一个指向提交I的标签。我们可以看到，C、D和E是作为分支的一部分完成的，H是将其合并到主节点中的提交。
所有这一切都可以在历史记录中看到，即使在分支被“删除”之后也是如此，因为这只是删除了标签。如果你知道怎么看，历史还是可以看到的。git log --graph --decorate --all和其他各种存储库查看工具揭示了真实的历史。
$ git log --graph --decorate --all --oneline
* f164d0e (HEAD -> master) Merge branch 'feature'
|\
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1我们可以清楚地看到合并点和在分支中完成了哪些提交。当您合并PR时，Github将向合并提交的消息中添加更多信息，例如PR #，以便可以追溯到其来源。这对以后的人们来说是非常有用的。
不幸的是，Github和git log (默认情况下)组成了一个整洁、易于阅读和错误的线性历史。这是与Git混淆的主要原因之一。
$ git log --all --oneline
f164d0e (HEAD -> master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1除了提交消息之外，分支和合并的所有指示都会丢失。所以一定要看看真实的历史。
另一种你会丢失历史的方式是你如何合并你的PR。压缩、重置和快进合并都将丢失分支的历史记录。
果汁
这是最糟糕的。它接受分支中的所有提交，并将它们粉碎为一个提交。如果您有一个分支，其中包含仔细考虑的提交和消息，这些消息清楚地解释了为什么要进行每个更改，那么所有这些都会混乱在一起。
Before squash
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After squash
* d6054cf (HEAD -> master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1虽然这对于进行合并的人来说可能非常方便，但对于后来试图弄清楚在该分支中做了什么以及为什么要做的人来说，这是非常可怕的。
重设基地
rebase有很多很好的用法。例如，更新功能分支最好使用rebase来完成，以避免在历史中进行大量不必要的记账合并。但当分支完成时，它应该被合并，而不是重新建立基础。重新设定基址会消除该分支存在的情况。
Before rebase
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After rebase
* aff85f0 (HEAD -> master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1至少单个提交仍然存在，但是它们作为单个单元作为分支的一部分来修复问题的拓扑证据已经消失了。
快进
类似于rebase，如果Git不需要合并，它就不会合并，它只会将分支标签前移。如果自创建分支以来没有在master上执行任何工作，就会发生这种情况。例如。
Before
* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -> master) commit 2
* 46edb1d commit 1
After fast forward
$ git merge feature
* eb54d0d (HEAD -> master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1https://stackoverflow.com/questions/54011756
复制相似问题