показать коммиты с момента создания ветки

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

Трехточечная версия предоставляет все изменения от кончика мастера до кончика myBranch. Однако обратите внимание, что общий коммит 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>

Убедитесь, что используется three периоды для этого случая.

Примечание: Вы также можете не указывать название своей ветви, так как git автоматически ссылается на указатель HEAD в этом случае, например:

git log master...

эквивалентно моему предыдущему примеру.Это работает везде, где доступно сравнение коммитов.

Answer 3

Если вы находитесь в созданной вами ветке:

git log master..

Answer 4

Да, можно сравнить вашу «новую» ветку с мастер-веткой (обычно называемой «master»):

git log master..<your_branch_name>

Конечно, заменить <your_branch_name>.

Answer 5

Я могу ошибаться, но я не думаю, что какой-либо из ответов точно запрашивается в ОП, поэтому я хотел добавить новый ответ. Я считаю, что это точно такой же вопрос, как и у меня, поскольку в других системах контроля версий это очень легко сделать.

У меня есть следующее в MASTER:

'развивать' | -> 'GP603'

В ORIGIN (моя локальная система) у меня есть:

'GP603' [CLONED из удаленного филиала / ветки GP603]

Затем я выполнил 2 разных коммита. Первое изменение коммита Файл X. Второе изменение коммита Файл X и Файл Y. Некоторое время спустя я хотел просто проверить свое предположение о состоянии локальной ветви ORIGIN / GP603. Это то, что я сделал, чтобы проверить, что были только те 2 коммита, которые я запомнил (которые в действительности были единственными 2 коммитами на ветке)

Происхождение журнала git / GP.603 ...

(Фиксация 2) commit b0ed4b95a14bb1c4438c8b48a31db7a0e9f5c940 (HEAD -> GP.603) Автор: ххххххх Дата: ср. Ххххх -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) commit 2c4541ca73eacd4b2e20d89f018d2e3f70332e7e Автор: ххххххх Дата: вт. Окт. Ххххх -0400

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