Question

有没有办法用git log或其他命令查看分支创建后添加的提交？

usage: git log [<options>] [<since>..<until>] [[--] <path>...]
   or: git show [options] <object>...

    --quiet               suppress diff output
    --source              show source
    --decorate[=...]      decorate options

Answer 1

完整文档在此处：https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html

假设您有一个如下所示的回购：

base  -  A  -  B  -  C  -  D   (master)
                \
                 \-  X  -  Y  -  Z   (myBranch)

验证回购状态：

> git checkout master
Already on 'master'
> git status ; git log --oneline
On branch master
nothing to commit, working directory clean
d9addce D
110a9ab C
5f3f8db B
0f26e69 A
e764ffa base

和myBranch：

> git checkout myBranch
> git status ; git log --oneline
On branch myBranch
nothing to commit, working directory clean
3bc0d40 Z
917ac8d Y
3e65f72 X
5f3f8db B
0f26e69 A
e764ffa base

假设您在myBranch上，并且您只希望更改SINCE master。使用双点版本：

> git log --oneline master..myBranch
3bc0d40 Z
917ac8d Y
3e65f72 X

三点版本提供从master的tip到myBranch的tip的所有更改。但请注意，不包括公共提交B：

> git log --oneline master...myBranch
d9addce D
110a9ab C
3bc0d40 Z
917ac8d Y
3e65f72 X

请注意：git log和git diff不同！行为并非完全相反，但差不多：

> git diff master..myBranch
diff --git a/rev.txt b/rev.txt
index 1784810..e900b1c 100644
--- a/rev.txt
+++ b/rev.txt
@@ -1 +1 @@
-D
+Z

> git diff master...myBranch
diff --git a/rev.txt b/rev.txt
index 223b783..e900b1c 100644
--- a/rev.txt
+++ b/rev.txt
@@ -1 +1 @@
-B
+Z

因此，双点版本显示从主要尖端（即D）到myBranch（Z）尖端的差异。三点版本显示了myBranch（即B）的基数与myBranch（Z）的顶端之间的差异。

Answer 2

使用三个句点来引用第二个分支与第一个分支分开的提交，或者在这种情况下，您的分支与主分支分开：

git log master...<your_branch_name>

确保在这种情况下使用三个期间。

侧注：您也可以省略分支名称，因为在这种情况下git会自动引用HEAD指针，例如：

git log master...

相当于我之前的例子。这适用于提交比较可用的任何地方。

Answer 3

如果你在你创建的分支上：

git log master..

Answer 4

是的，可以将您的“新”分支与主分支（通常命名为“master”）进行比较：

git log master..<your_branch_name>

当然，请替换<your_branch_name>。

Answer 5

我可能是错的，但我认为OP中并没有确切要求任何答案，因此我想添加一个新答案。我相信这是与我完全相同的问题，因为在其他源代码控制系统中，这很容易做到。

我在MASTER中具有以下内容：

“开发” | ->'GP603'

在ORIGIN（我的本地系统）中，我有：

'GP603'[从remote / GP603分支中删除]

然后我执行了2次不同的提交。第一次提交更改文件X。第二次提交更改文件X和文件Y。一天后，我只想验证我对本地分支ORIGIN / GP603状态的假设。我这样做是为了验证我记得只有2次提交（实际上是分支中仅有2次提交）

$ git log origin / GP.603 ...

（提交2）提交b0ed4b95a14bb1c4438c8b48a31db7a0e9f5c940（HEAD-> GP.603）作者：xxxxxxx 日期：星期三xxxxx -0400

1. Fixed defect where the format of the file names and paths were being added to HashTable in such a way that they would never be matched in any comparison.  This was an
defect causing older failed files to never be moved to the correct directory (WindowsServiceApplication.cs)

2. Removing worthless and contextless message as it does nothing but clog the log with garbage making it harder to read (DinoutFileHandler.cs)

（提交1）提交2c4541ca73eacd4b2e20d89f018d2e3f70332e7e 作者：xxxxxxx 日期：星期二十月xxxxx -0400

In ProcessFile() function need to perform a .ToLower() on the file path string when adding it o the failedFiles collection.

Answer 6

此命令对我来说效果很好。我很有趣，只看到在开始引用和结束引用之间的提交增量中更改的文件名，

 git log --no-merges --pretty=oneline --name-only <begin ref>..<end ref>

给出这样的输出，

<commit hash> <commit subject line>
foo.txtr
bar.txt

Answer 7

我经常进入哦，亲爱的上帝，我做了什么。具体来说，令人担忧的担忧是当前分支机构的最新变化。看到提交的怪异游戏真是太好了，我如下。（假设您位于感兴趣的 current 分支中，并且已从 dev 分支出来。）

git log --oneline开发人员..

它提供了我所做的提交清单，以追溯到不存在混乱，鸡奸和戈莫拉的地方。此外，如果您像LSD上的ADHD猴子那样执着地投入，也会有帮助。确定方位列表后，可以按照this article中的说明缩小范围并进行分析-在底部有一节限制输出。

显示自分支创建以来的提交

7 个答案: