blocks|key|1609265|text|简单的答案是，你可以告诉Github禁止直接推送到master。这会让你的工作自动化。所有提交给大师的承诺必须来自公关。https://help.github.com/articles/about-protected-branches/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1609266|您还可以要求某些自动状态检查通过，然后才能合并PR，如自动代码审查和CI。https://help.github.com/articles/about-required-status-checks/|1609267|1609268|更复杂的答案..。|1609269|PR和其他提交没有什么明显的不同。但是，根据你如何合并你的PR和查看你的提交，将会有大量的线索。|1609270|git+log和Github提交历史对你撒谎。Git历史是相互关联的提交，实际的分支如下所示。|style|CODE|1609271|A+-+B+-+F+-+G+-+H+-+I+[master]
+++++\+++++++++/
++++++----C+-+D+|code-block|syntax|javascript|1609272|每个字母都是一个提交。它们是相互联系的。代码库从A开始。[master]是一个“分支标签”，但它实际上只是一个指向提交I的标签。我们可以看到，C、D和E是作为分支的一部分完成的，H是将其合并到主节点中的提交。|1609273|所有这一切都可以在历史记录中看到，即使在分支被“删除”之后也是如此，因为这只是删除了标签。如果你知道怎么看，历史还是可以看到的。git+log+--graph+--decorate+--all和其他各种存储库查看工具揭示了真实的历史。|1609274|$+git+log+--graph+--decorate+--all+--oneline

*+++f164d0e+(HEAD+->+master)+Merge+branch+'feature'
%7C\++
%7C+*+ae7b325+feature+2
%7C+*+562cb51+feature+1
*+%7C+2504fb9+master+4
*+%7C+a3e73ae+master+3
%7C/++
*+e8bd7c4+commit+2
*+46edb1d+commit+1|1609275|我们可以清楚地看到合并点和在分支中完成了哪些提交。当您合并PR时，Github将向合并提交的消息中添加更多信息，例如PR+#，以便可以追溯到其来源。这对以后的人们来说是非常有用的。|1609276|不幸的是，Github和git+log+(默认情况下)组成了一个整洁、易于阅读和错误的线性历史。这是与Git混淆的主要原因之一。|1609277|$+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|1609278|除了提交消息之外，分支和合并的所有指示都会丢失。所以一定要看看真实的历史。|1609279|1609280|另一种你会丢失历史的方式是你如何合并你的PR。压缩、重置和快进合并都将丢失分支的历史记录。|1609281|果汁|1609282|这是最糟糕的。它接受分支中的所有提交，并将它们粉碎为一个提交。如果您有一个分支，其中包含仔细考虑的提交和消息，这些消息清楚地解释了为什么要进行每个更改，那么所有这些都会混乱在一起。|1609283|Before+squash

*+eb54d0d+(feature)+feature+2
*+218a926+feature+1
%7C+*+2504fb9+(HEAD+->+master)+master+4
%7C+*+a3e73ae+master+3
%7C/++
*+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|1609284|虽然这对于进行合并的人来说可能非常方便，但对于后来试图弄清楚在该分支中做了什么以及为什么要做的人来说，这是非常可怕的。|1609285|重设基地|1609286|rebase有很多很好的用法。例如，更新功能分支最好使用rebase来完成，以避免在历史中进行大量不必要的记账合并。但当分支完成时，它应该被合并，而不是重新建立基础。重新设定基址会消除该分支存在的情况。|1609287|Before+rebase

*+eb54d0d+(feature)+feature+2
*+218a926+feature+1
%7C+*+2504fb9+(HEAD+->+master)+master+4
%7C+*+a3e73ae+master+3
%7C/++
*+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|1609288|至少单个提交仍然存在，但是它们作为单个单元作为分支的一部分来修复问题的拓扑证据已经消失了。|1609289|快进|1609290|类似于rebase，如果Git不需要合并，它就不会合并，它只会将分支标签前移。如果自创建分支以来没有在master上执行任何工作，就会发生这种情况。例如。|1609291|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+1|1609292|entityMap|0|LINK|mutability|MUTABLE|url|https://help.github.com/articles/about-protected-branches/|1|https://help.github.com/articles/about-required-status-checks/^0|1O|1M|0|0|11|1Q|1|0|0|0|0|0|7|0|0|S|8|0|1S|W|0|0|0|C|7|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1F|6|0|0^^$0|@$1|2|3|4|5|6|7|26|8|@]|9|@$A|27|B|28|1|29]]|C|$]]|$1|D|3|E|5|6|7|2A|8|@]|9|@$A|2B|B|2C|1|2D]]|C|$]]|$1|F|3|-4|5|6|7|2E|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|2F|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|2G|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|2H|8|@$A|2I|B|2J|M|N]]|9|@]|C|$]]|$1|O|3|P|5|Q|7|2K|8|@]|9|@]|C|$R|S]]|$1|T|3|U|5|6|7|2L|8|@$A|2M|B|2N|M|N]]|9|@]|C|$]]|$1|V|3|W|5|6|7|2O|8|@$A|2P|B|2Q|M|N]]|9|@]|C|$]]|$1|X|3|Y|5|Q|7|2R|8|@]|9|@]|C|$R|S]]|$1|Z|3|10|5|6|7|2S|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|2T|8|@$A|2U|B|2V|M|N]]|9|@]|C|$]]|$1|13|3|14|5|Q|7|2W|8|@]|9|@]|C|$R|S]]|$1|15|3|16|5|6|7|2X|8|@]|9|@]|C|$]]|$1|17|3|-4|5|6|7|2Y|8|@]|9|@]|C|$]]|$1|18|3|19|5|6|7|2Z|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|6|7|30|8|@]|9|@]|C|$]]|$1|1C|3|1D|5|6|7|31|8|@]|9|@]|C|$]]|$1|1E|3|1F|5|Q|7|32|8|@]|9|@]|C|$R|S]]|$1|1G|3|1H|5|6|7|33|8|@]|9|@]|C|$]]|$1|1I|3|1J|5|6|7|34|8|@]|9|@]|C|$]]|$1|1K|3|1L|5|6|7|35|8|@]|9|@]|C|$]]|$1|1M|3|1N|5|Q|7|36|8|@]|9|@]|C|$R|S]]|$1|1O|3|1P|5|6|7|37|8|@]|9|@]|C|$]]|$1|1Q|3|1R|5|6|7|38|8|@]|9|@]|C|$]]|$1|1S|3|1T|5|6|7|39|8|@$A|3A|B|3B|M|N]]|9|@]|C|$]]|$1|1U|3|1V|5|Q|7|3C|8|@]|9|@]|C|$R|S]]|$1|1W|3|-4|5|6|7|3D|8|@]|9|@]|C|$]]]|1X|$1Y|$5|1Z|20|21|C|$22|23]]|24|$5|1Z|20|21|C|$22|25]]]]

The simple answer is that you can tell Github to disallow direct pushes to master. That'll automate your job. All commits to master must come from a PR. <a href="https://help.github.com/articles/about-protected-branches/" rel="nofollow noreferrer">https://help.github.com/articles/about-protected-branches/</a>

You can also require that certain automated status checks pass before a PR can be merged like automated code review and CI.
<a href="https://help.github.com/articles/about-required-status-checks/" rel="nofollow noreferrer">https://help.github.com/articles/about-required-status-checks/</a>

<hr>

The more complicated answer...

There is nothing explicitly different about a PR than any other commit. But depending on how you merge your PRs and view your commits there will be plenty of clues.

<code>git log</code> and the Github commit history lie to you. Git history is interconnected commits with actual branches looking something like this.

<pre><code>A - B - F - G - H - I [master]
 \ /
 ----C - D 
</code></pre>

Each letter is a commit. They're connected to each other. The repo starts at A. <code>[master]</code> is a "branch label" but it's really just a label pointing at commit I. We can see that C, D, and E were done as part of a branch and H is the commit that merged it into master.

All this can be seen in the history even after the branch is "deleted" because that just deletes the label. The history can still be seen if you know how to look. <code>git log --graph --decorate --all</code>, and various other repository viewing tools, reveal the true history.

<pre><code>$ git log --graph --decorate --all --oneline

* f164d0e (HEAD -&gt; master) Merge branch 'feature'
|\ 
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/ 
* e8bd7c4 commit 2
* 46edb1d commit 1
</code></pre>

We can see clearly the merge point and what commits were done in a branch. When you merge a PR Github will add more information to the message of the merge commit such as the PR # so it can be traced back to its source. This is of INVALUABLE use to people later on.

Unfortunately Github and <code>git log</code> (by default) make up a linear history that is neat and easy to read and wrong. This is a source of much of the confusion with Git.

<pre><code>$ git log --all --oneline

f164d0e (HEAD -&gt; master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1
</code></pre>

Aside from the commit messages, all indication of branches and merges is lost. So be sure to look at the true history.

<hr>

The other way you can lose history is in how you merge your PRs. Squash, rebase, and fast-forward merges will all lose the history for the branch.

<h1>Squash</h1>

This is the worst. It takes all the commits in the branch and smashes them into one commit. If you had a branch with carefully considered commits and messages forming a clear explanation of why each change was made, it will all be jumbled together.

<pre><code>Before squash

* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -&gt; master) master 4
| * a3e73ae master 3
|/ 
* e8bd7c4 commit 2
* 46edb1d commit 1

After squash

* d6054cf (HEAD -&gt; master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
</code></pre>

While this might be very convenient for the person doing the merge, it's terrible for anyone later trying to figure out what was done in that branch and why.

<h1>Rebase</h1>

There are many, many good uses for rebase. Updating a feature branch, for example, is better done with a rebase to avoid a lot of unnecessary bookkeeping merges in the history. But when a branch is complete it should be merged, not rebased. Rebasing eliminates that the branch existed.

<pre><code>Before rebase

* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -&gt; master) master 4
| * a3e73ae master 3
|/ 
* e8bd7c4 commit 2
* 46edb1d commit 1

After rebase

* aff85f0 (HEAD -&gt; master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
</code></pre>

At least the individual commits are still there, but the topological evidence that they were done as a single unit as part of a branch to fix an issue are gone.

<h1>Fast Forward</h1>

Similar to a rebase, if Git doesn't need to merge, it won't. It'll just move the branch label forward. This happens if there was no work done on <code>master</code> since the branch was made. For example.

<pre><code>Before

* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -&gt; master) commit 2
* 46edb1d commit 1

After fast forward

$ git merge feature

* eb54d0d (HEAD -&gt; master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1
</code></pre>

We prefer a feature-branch workflow with GitHub (like the github workflow mainly). One of my roles is checking this is being done neatly but when I look at <code>https://github.com/&lt;our-org&gt;/&lt;repo&gt;/commits/master</code> I don't see anything demarcating when a commit is directly on the repo Vs when a PR is reviewed and accepted.

I definitely don't see a way to link commits to PRs or similar. Is this possible/easy and am I just missing it on the web UI?

How can I see when Github commits are from a pull-request/merge instead of direct commits?

我们更喜欢使用GitHub的功能分支工作流(主要像github工作流)。我的职责之一是检查这是否整齐地完成了，但当我查看https://github.com/<our-org>/<repo>/commits/master时，我看不到任何界限，当提交是直接在repo上时，还是当PR被审查和接受时。我绝对看不到将提交链接到...

问当Github提交来自pull-request/merge而不是直接提交时，我如何查看？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当Github提交来自pull-request/merge而不是直接提交时，我如何查看？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当Github提交来自pull-request/merge而不是直接提交时，我如何查看？
EN