git log 只返回对主分支所做的提交？

git log to return only the commits made to the master branch?

提问by Kris Anderson

I've done a bit of searching and found:

我做了一些搜索，发现：

git log myBranchName

as a possible solution. But what happens when my branch is the master branch? when I run:

作为可能的解决方案。但是当我的分支是主分支时会发生什么？当我运行时：

git log master

It seems to return everything commited to any branch. Based on what I've read, it lists all of the commits related to the master branch. Knowing that, how I can call up the commit history of the master branch only?

它似乎返回提交给任何分支的所有内容。根据我阅读的内容，它列出了与 master 分支相关的所有提交。知道了，我怎么能只调用 master 分支的提交历史？

回答by parkydr

I think this is what you want

我想这就是你想要的

git log --first-parent master

To quote the manual

引用手册

Follow only the first parent commit upon seeing a merge commit. This option can give a better overview when viewing the evolution of a particular topic branch, because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits brought in to your history by such a merge.

看到合并提交后，只关注第一个父提交。在查看特定主题分支的演变时，此选项可以提供更好的概览，因为合并到主题分支往往只是调整到不时更新的上游，并且此选项允许您忽略引入到的单个提交你的历史通过这样的合并。

回答by poke

Due to Git's branching model, commits do not belong to a single or multiple branches. Branches are pointers to single commit objects within the whole commit graph. So when you say a commit is “on a branch X” in X, you usually mean that it is reachable when starting at the commit the branch X points to.

由于 Git 的分支模型，提交不属于单个或多个分支。分支是指向整个提交图中单个提交对象的指针。所以当你说一个提交是“在 X 的分支 X 上”时，你通常的意思是当从分支 X 指向的提交开始时它是可达的。

For git log, the default behaviour is equal to git log HEADwhere HEAD refers to the commit the current branch currently points at. So if you are on the master branch, it is equal to git log master, showing all commits that are reachable when starting at the most recent commit.

对于git log，默认行为等于git log HEADHEAD 指的是当前分支当前指向的提交。因此，如果您在 master 分支上，则它等于git log master，显示从最近一次提交开始时可以访问的所有提交。

Unfortunately what you are referring to as a commit made to a certain branch is not clearly defined in Git. If I make a commit on master, and then create a new branch that points to the same commit (e.g. using git branch newbranch), then that branch is literally identical to the master branch except for the name. So every property “made on branch master”would now also imply “made on branch newbranch”. As such you cannot have this property in Git.

不幸的是，您所说的对某个分支的提交在 Git 中没有明确定义。如果我在 master 上进行提交，然后创建一个指向相同提交的新分支（例如 using git branch newbranch），那么该分支实际上与 master 分支相同，只是名称不同。因此，每个“在 master 分支上制造”的属性现在也意味着“在分支 newbranch 上制造”。因此，您不能在 Git 中拥有此属性。

Even parkydr's solution, which shows all commits which were made only on a single side of merges is not a failproof solution. Ideally it would hide all those commits which were made on a separate non-master branch and which were then merged back into master. As such you would only get commits that are either made to the master-line directly or which are merge commits merging in some other commits. However there are two things that will prevent this from working:

即使是 parkydr 的解决方案，它显示了仅在合并的一侧进行的所有提交，也不是防故障解决方案。理想情况下，它将隐藏在单独的非主分支上进行的所有提交，然后将其合并回主分支。因此，您只会获得直接对主线进行的提交或合并提交并合并到其他一些提交中的提交。但是，有两件事会阻止此操作：

1. Fast-forward merges: When you branch off from master and create some commits, while creating no new ones on master directly, then a git merge somebranchon master will fast-forward the commits, resulting in the master branch pointing to the same commit as somebranch. As such you “lose” the information that those commits were originally created on a separate branch. You can force Git to always create merge commits though, using git merge --no-ffbut this won't help you afterwards.
2. The merge order is not guaranteed: When you are on master and merge a branch in, then the previous master commit will alwaysbe the first parent. So you would get your desired behaviour. However it is perfectly possible to be on said branch, and merge master in instead, resulting in the master commit being the second parent. Then master could be fast-forwarded (or reset) to the new commit resulting in a “reversed” view.

1. 快进合并：当你从 master 分支并创建一些提交，而没有直接在 master 上创建新的提交时，然后一个git merge somebranchon master 将快进提交，导致 master 分支指向与somebranch相同的提交。因此，您“丢失”了这些提交最初是在单独的分支上创建的信息。您可以强制 Git 始终创建合并提交，但使用git merge --no-ff之后这对您没有帮助。
2. 不能保证合并顺序：当您在 master 上并合并一个分支时，之前的 master 提交将始终是第一个父级。所以你会得到你想要的行为。然而，完全有可能在所述分支上，并合并 master，从而导致 master 提交成为第二个父级。然后 master 可以快进（或重置）到新的提交，从而导致“反向”视图。

So, the bottom line is that you cannot safely get such a history. You're better off getting used to how Git's flexible branching model works.

所以，底线是你不能安全地获得这样的历史。你最好习惯 Git 灵活的分支模型的工作方式。