show здійснює з моменту створення гілки

Чи є спосіб побачити за допомогою git logякоїсь іншої команди лише коміти, які були додані після створення гілки?

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

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

Повна документація знаходиться тут: 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 і хочете змінити лише ПІСЛЯ майстра. Використовуйте версію з двома крапками:

> 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).

Я неправильно відповів на свою оригінальну відповідь. Ви хочете позначити подвійні крапки:

git log master..<your_branch_name>

Я отримав інші результати, ніж очікував, тому я зробив тест із такою структурою репо:

a - - c - e - - g - i   master
  \ b - d / \ f - h     test

Потім я спробував git log master..test:

f - h

А потім git log master...test:

  - g - i
  f - h

Тож подвійна крапка показує коміти в, testале не в master( ^master temp), а потрійна крапка показує коміти в masterІ, testале не в обох.

Інша відмінна відповідь у цьому питанні отримала його спершу і має краще пояснення ( https://stackoverflow.com/a/24769534/1185838 ); це, мабуть, повинно бути позначено як відповідь замість мого. Ви також можете посилатися на цю відповідь ( https://stackoverflow.com/a/463027/1185838 ), яка допомогла мені краще зрозуміти різницю між позначенням із подвійною крапкою та потрійною крапкою.

Вибачення за неправильну відповідь!

Стара відповідь - неправильна

Використовуйте три періоди для посилання на коміт, при якому друга гілка відхилялася від першої, або в цьому випадку ваша гілка відхилялася від головного:

git log master...<your_branch_name>

Обов’язково використовуйте три періоди для цього випадку.

Примітка: Ви також можете залишити назву вашої гілки, оскільки git автоматично посилається на вказівник HEAD у такому випадку, наприклад:

git log master...

еквівалентно моєму попередньому прикладу. Це працює скрізь, де доступне порівняння комітів.

Якщо ви перебуваєте у створеній гілці:

git log master..

Так, можна порівняти вашу "нову" гілку з головною гілкою (загальноназваною: "master"):

git log master..<your_branch_name>

Звичайно, замінити <your_branch_name>.

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

У мене в MASTER є таке:

"розробляти" | -> 'GP603'

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

'GP603' [CLONED from the remote / GP603 branch]

Потім я виконав 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.

Ця команда добре працювала для мене. Мені було цікаво бачити лише імена файлів, які змінювались у дельті комітів між початком і кінцем посилання

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

який дає такий вивід,

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

Я часто потрапляю в режим о, Боже, що я зробив . Зокрема, переслідуючий страх стосується останніх змін у поточній галузі. Приємно бачити гру звинувачення в коммітах, яку я роблю наступним чином. (Припускаючи, що ви знаходитесь у поточній галузі інтересів і розгалужили її від розробника )

git log --oneline dev ..

Це дає мені список зобов’язань, які я зробив, щоб відстежити те місце, де хаос, содома та гоморра не є реальністю. Крім того, це допомагає, якщо ви нав’язливо поводитесь, як мавпа СДУГ на ЛСД. Отримавши список підшипників, я можу звузити його та проаналізувати, як задокументовано в цій статті - унизу є розділ про обмеження виходу.