web-dev-qa-db-de.com

zeige Commits seit der Erstellung des Zweiges

Gibt es eine Möglichkeit, mit git log oder einem anderen Befehl nur die Commits anzuzeigen, die nach der Erstellung der Verzweigung hinzugefügt wurden?

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

    --quiet               suppress diff output
    --source              show source
    --decorate[=...]      decorate options
gitgit-log
50
lurscher

Verwenden Sie drei Perioden, um auf das Commit zu verweisen, bei dem der zweite Zweig vom ersten oder in diesem Fall vom Zweig abweicht:

git log master...<your_branch_name>

Stellen Sie sicher, dass Sie für diesen Fall drei Perioden verwenden.

Side-Note: Sie können auch den Zweignamen weglassen, da git in diesem Fall automatisch auf den HEAD - Zeiger verweist, z.

git log master...

entspricht meinem vorherigen Beispiel. Dies funktioniert überall dort, wo ein Commit-Vergleich verfügbar ist.

52
Matt Meng

Die vollständige Dokumentation finden Sie hier: https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html

Angenommen, Sie haben ein Repo, das folgendermaßen aussieht:

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

Überprüfen Sie den Repo-Status:

> 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

und für 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

Angenommen, Sie sind auf myBranch und möchten nur SINCE-Master ändern. Verwenden Sie die Zwei-Punkte-Version:

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

Die Drei-Punkt-Version gibt alle Änderungen vom Tip des Masters bis zum Tip von myBranch an. Beachten Sie jedoch, dass das Common Commit B nicht enthalten ist:

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

BITTE BEACHTEN SIE: git log und git diff DIFFERENTLY VERHALTEN! Das Verhalten ist nicht genau umgekehrt, aber fast:

> 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

Die Version mit zwei Punkten zeigt also den Unterschied zwischen der Spitze des Masters (d. H. D) und der Spitze von myBranch (Z). Die Version mit drei Punkten zeigt den Unterschied zwischen der Basis von myBranch (d. H. B) und der Spitze von myBranch (Z).

48
Alan Thompson

Wenn Sie sich in der Branche befinden, die Sie erstellt haben:

git log master..
11
Shaun Luttin

Ja, es ist möglich, Ihren "neuen" Zweig mit dem Master-Zweig (allgemein "Master") zu vergleichen:

git log master..<your_branch_name>

Ersetzen Sie natürlich <your_branch_name>. 

3
Sandro Munda

Ich könnte falsch liegen, aber ich glaube nicht, dass eine der Antworten genau im OP nachgefragt wurde, also wollte ich eine neue Antwort hinzufügen. Ich glaube, das ist genau die gleiche Frage, die ich hatte, da dies in anderen Quellcodeverwaltungssystemen sehr einfach ist.

Ich habe in MASTER folgendes: 

'entwickeln' | -> 'GP603'

In Origin (meinem lokalen System) habe ich: 

'GP603' [KLONIERT vom Remote-/GP603-Zweig]

Ich habe dann 2 verschiedene Commits ausgeführt. Erste Commit-Änderung Datei X. Zweite Commit-Änderung Datei X und Datei Y. Einige Tage später wollte ich nur meine Annahme des Status des lokalen Zweigs Origin/GP603 bestätigen. Dies ist, was ich tat, um zu bestätigen, dass es nur die 2 Commits gab, an die ich mich erinnere (die in Wirklichkeit die einzigen 2 Commits in der Branche waren).

$ git log Origin/GP.603 ...

(Festschreiben 2) Festschreiben b0ed4b95a14bb1c4438c8b48a31db7a0e9f5c940 (HEAD -> GP.603) Autor: xxxxxxxDatum: Mi 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)

(Festschreiben 1) Festschreiben 2c4541ca73eacd4b2e20d89f018d2e3f70332e7eAutor: xxxxxxxDatum: Di Oct xxxxx -0400

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