Git für Perforce-Benutzer

85

Ich benutze Perforce seit einigen Jahren. Ich würde gerne zur Verwendung von Git für meinen persönlichen Code wechseln, aber alle Git-Tutorials, die ich gesehen habe, gehen entweder davon aus, dass Sie eine vollständige Quellcodeverwaltung n00b sind (was sie unglaublich langweilig macht) oder dass Sie es gewohnt sind svn (was ich nicht bin).

Ich kenne p4 und verstehe auch die Idee hinter einem verteilten Versionsverwaltungssystem (also brauche ich kein Verkaufsgespräch, danke). Was ich möchte, ist eine Übersetzungstabelle vom Befehl p4 in äquivalente Git-Befehle sowie die Befehle "Ich kann nicht ohne leben", die kein p4-Äquivalent haben.

Da ich vermute, dass jeder p4-Benutzer eine andere Teilmenge von p4 verwendet, sind hier einige der Dinge, die ich regelmäßig in p4 mache, die ich in git tun möchte, die aus den von mir betrachteten Dokumenten nicht sofort ersichtlich sind ::

  1. Erstellen Sie mehrere ausstehende Änderungslisten in einem einzelnen Client. ( p4 change)
  2. Bearbeiten Sie eine ausstehende Änderungsliste. (auch p4 change)
  3. siehe eine Liste aller meiner ausstehenden Änderungslisten ( p4 changes -s pending)
  4. Liste aller geänderten Dateien in meinem Client ( p4 opened) oder in einer ausstehenden Änderungsliste ( p4 describe)
  5. siehe einen Unterschied einer ausstehenden Änderungsliste (ich verwende dafür ein Wrapper-Skript, das p4 diffund verwendet p4 describe)
  6. Sehen Sie für eine bestimmte Datei, welche übermittelten Änderungslisten welche Zeilen beeinflusst haben ( p4 annotate)
  7. Für eine bestimmte Datei finden Sie eine Liste der Beschreibungen der Änderungslisten, die die Datei betroffen haben ( p4 log)
  8. eine ausstehende Änderungsliste einreichen ( p4 submit -c)
  9. eine ausstehende Änderungsliste abbrechen ( p4 revert)

Viele davon drehen sich um "Änderungslisten". "Änderungsliste" ist die p4-Terminologie. Was ist der git-äquivalente Begriff?

Es hört sich so an, als ob Zweige das sein könnten, was Git-Benutzer anstelle dessen verwenden, was p4 Änderungslisten nennt. Ein bisschen verwirrend, da p4 auch so etwas wie einen Zweig hat, obwohl es sich nur um vage verwandte Konzepte zu handeln scheint. (Obwohl ich immer dachte, dass das Konzept von p4 für einen Zweig ziemlich seltsam ist, unterscheidet es sich noch einmal vom klassischen RCS-Konzept eines Zweigs.)

Wie auch immer ... Ich bin mir nicht sicher, wie ich das erreichen soll, was ich normalerweise in p4-Änderungslisten mit Git-Zweigen mache. In p4 kann ich so etwas machen:

$ p4 edit a.txt
$ p4 change a.txt
Change 12345 created.

Zu diesem Zeitpunkt habe ich eine Änderungsliste, die a.txt enthält. Ich kann die Beschreibung bearbeiten und weiterarbeiten, ohne die Änderungsliste einzureichen. Wenn sich herausstellt, dass ich einige Änderungen an anderen Dateien vornehmen muss, z. B. einen Bugfix in einer anderen Codeebene, kann ich dies auf demselben Client tun:

$ p4 edit z.txt
$ p4 change z.txt
Change 12346 created.

Jetzt habe ich zwei separate Änderungslisten im selben Client. Ich kann gleichzeitig daran arbeiten und muss nichts tun, um zwischen ihnen zu "wechseln". Wenn es Zeit für ein Commit ist, kann ich sie separat einreichen:

$ p4 submit -c 12346  # this will submit the changes to z.txt
$ p4 submit -c 12345  # this will submit the changes to a.txt

Ich kann nicht herausfinden, wie ich das in Git replizieren kann. Aus meinen Experimenten geht nicht hervor, dass dies git addmit dem aktuellen Zweig verbunden ist. Soweit ich das beurteilen kann, werden beim git commitFestschreiben aller Dateien, die ich erstellt habe, git addunabhängig davon, in welchem ​​Zweig ich mich zu diesem Zeitpunkt befand:

$ git init
Initialized empty Git repository in /home/laurence/git-playground/.git/
$ ls
a.txt  w.txt  z.txt
$ git add -A .
$ git commit
 Initial commit.
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 a.txt
 create mode 100644 w.txt
 create mode 100644 z.txt
$ vi a.txt z.txt 
2 files to edit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   a.txt
#   modified:   z.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git branch aardvark
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git add a.txt 
$ git checkout master
M   a.txt
M   z.txt
Switched to branch 'master'
$ git branch zebra
$ git checkout zebra
M   a.txt
M   z.txt
Switched to branch 'zebra'
$ git add z.txt 
$ git status
# On branch zebra
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt
#
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git status
# On branch aardvark
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt

In diesem Beispiel scheinen die Erdferkel- und Zebrazweige genau die gleichen Änderungen zu enthalten, und basierend auf der Ausgabe git statusscheint es, dass das Festschreiben in beiden den gleichen Effekt hat. Mache ich etwas falsch?

Laurence Gonsalves
quelle
2
Sie können einfach perforce für Ihren persönlichen Code verwenden, vorausgesetzt, die kostenlosen 5 Clients reichen aus.
Logan Capaldo
3
Das hatte ich getan, aber ich möchte zu etwas wechseln, das Open Source ist und auch von Open Source-Projekten verwendet wird. Ich habe sowohl über Git als auch über Mercurial nachgedacht. Ich habe mich zu Git geneigt, weil es mehr Schwung zu haben scheint.
Laurence Gonsalves
1
Du solltest Git besser von Grund auf lernen. Der von Git vorgeschriebene Workflow unterscheidet sich stark von dem von Perforce vorgeschriebenen Workflow. Übersetzte Workflows sind umständlich, und der Versuch, Funktionen gleichzusetzen, verwirrt Ihr Verständnis. Glücklicherweise bietet die Git-Community eine Fülle von Dokumentationen für Anfänger, z. git-scm.com/book
Colonel Panic
1
@ColonelPanic Ich kann Ihren Standpunkt verstehen, aber das Problem mit einer solchen Dokumentation ist, dass es Zeit verschwendet, grundlegende Dinge zu erklären, die jeder Perforce-Benutzer bereits kennen würde. Das Lesen einer solchen Dokumentation ist genauso ärgerlich wie der Versuch, ein Tutorial zu einer anderen Programmiersprache zu lesen, in dem in einem Kapitel erklärt wird, was Variablen sind.
Laurence Gonsalves
@ColonelPanic Das heißt, ich habe einige andere Git-Dokumentationen gelesen, einschließlich Git From the Bottom Up und Git for Computer Scientists , die eigentlich sehr nützlich waren. Ich benutze Git seit einigen Jahren (beachten Sie, als diese Frage ursprünglich gestellt wurde), und ich denke, die Hauptprobleme beim Lernen von Git sind nicht mangelnde Dokumentation, sondern schlechte Nomenklatur, interne Inkonsistenz, stark überladene Befehle und bestimmte unfertige Teile, die nicht für den tatsächlichen Gebrauch bereit sind. Ich wünschte, jemand würde gehen und die ganze Kruft aufräumen, aber das würde diejenigen ärgern, die sich daran gewöhnt haben.
Laurence Gonsalves

Antworten:

72

Ich habe nicht viel perforce verwendet, daher ist dies möglicherweise keine 1: 1-Übersetzung. Andererseits haben verteilte Versionsverwaltungssysteme wie git und mercurial sowieso einen anderen Workflow, so dass es wirklich keine 1: 1-Übersetzung gibt (und es auch nicht geben sollte). Wie auch immer, hier geht's:

  • Erstellen Sie mehrere ausstehende Änderungslisten -> Verwenden Sie stattdessen Zweige. In Git-Zweigen sind die Zweige leicht und schnell, die Erstellung dauert weniger als eine Sekunde und die Zusammenführung normalerweise weniger als zwei Sekunden. Haben Sie keine Angst davor, sich oft zu verzweigen und neu zu gründen.

    git branch new-branch-name
    git checkout new-branch-name
    

    Oder machen Sie alles in einer Zeile:

    git checkout -b new-branch-name
    
  • Eine Liste aller ausstehenden Änderungslisten anzeigen -> Da das Äquivalent mehrerer ausstehender Änderungslisten mehrere Zweige sind, sehen Sie sich nur die Zweige an:

    git branch
    

    Wenn Sie auch entfernte Zweige anzeigen möchten:

    git branch -a
    

    Es wird empfohlen, einen Zweig nach einer erfolgreichen Zusammenführung sofort zu löschen, damit Sie nicht nachverfolgen müssen, welcher Zweig zum Zusammenführen ansteht und welcher bereits zusammengeführt wurde.

  • Alle geänderten Dateien auflisten -> Für eine einzelne ausstehende "Änderungsliste" in einem bestimmten Zweig hat git ein Konzept des Index oder Caches. Um eine Änderung zu übernehmen, müssen Sie zuerst Dateien zu diesem Index hinzufügen. Auf diese Weise können Sie manuell auswählen, welche Dateigruppe eine einzelne Änderung darstellt, oder irrelevante Dateien ignorieren. Um den Status zu sehen, welche Dateien zu diesem Index hinzugefügt wurden oder nicht, gehen Sie einfach wie folgt vor:

    git status
    
  • Siehe einen Unterschied einer ausstehenden Änderungsliste -> Dies besteht aus zwei Teilen. Zuerst sehen Sie einen Unterschied zwischen dem Arbeitsverzeichnis und dem Index:

    git diff
    

    Aber wenn Sie den Unterschied zwischen dem, was Sie gerade eingeben, und dem letzten Commit wissen möchten, dann fragen Sie wirklich nach einem Unterschied zwischen dem Arbeitsverzeichnis + Index und dem HEAD:

    git diff HEAD
    
  • Sehen Sie für eine bestimmte Datei, welche übermittelten Änderungslisten welche Zeilen beeinflusst haben -> Dies ist einfach:

    git blame filename
    

    oder noch besser, wenn Sie sich in einer Fensterumgebung befinden:

    git gui blame filename
    

    Git GUI braucht länger, um die Datei zu analysieren (sie wurde in tcl anstelle von C geschrieben), aber es hat viele nette Funktionen, einschließlich der Möglichkeit, durch Klicken auf eine Commit-ID eine Zeitreise in die Vergangenheit zu unternehmen. Ich wünschte nur, sie würden eine Funktion für "Zeitreisen" in die Zukunft implementieren, damit ich herausfinden kann, wie ein bestimmter Fehler endlich behoben wird ;-)

  • Für eine bestimmte Datei finden Sie eine Liste der Beschreibungen der Änderungslisten, die die Datei betroffen haben -> auch einfach:

    git log filename
    

    Aber Git Log ist ein viel mächtigeres Werkzeug als nur dieses. Tatsächlich huckepack die meisten meiner persönlichen Skripte aus dem Git-Protokoll, um das Repository zu lesen. Lesen Sie die Manpage.

  • Senden Sie eine ausstehende Änderungsliste -> Auch einfach:

    git commit
    

In meiner Antwort auf eine vorherige Frage finden Sie meinen typischen Git-Workflow: Git lernen. Ich muss wissen, ob ich auf dem richtigen Weg bin

Wenn Sie dem von mir beschriebenen Workflow folgen, sind Tools wie gitk viel wertvoller, da Sie damit Gruppen von Änderungen klar erkennen können.


Zusätzliche Antwort:

Git ist sehr flexibel und es gibt verschiedene Möglichkeiten, das zu tun, was Sie beschreiben. Denken Sie daran, für jede Funktion, an der Sie arbeiten, immer einen neuen Zweig zu starten. Dies bedeutet, dass der Hauptzweig nicht berührt wird, sodass Sie jederzeit zu ihm zurückkehren können, um Fehler zu beheben. Wenn man in Git arbeitet, sollte man fast immer beginnen mit:

git checkout -b new-feature-a

Jetzt können Sie die Datei a.txt bearbeiten. Um gleichzeitig an einer anderen Funktion zu arbeiten, gehen Sie wie folgt vor:

git checkout master
git checkout -b new-feature-z

Jetzt können Sie die Datei z.txt bearbeiten. So wechseln Sie zurück zu a.txt:

git checkout new-feature-a

Aber warten Sie, es gibt Änderungen an new-feature-z und mit git können Sie keine Zweige wechseln. An diesem Punkt haben Sie zwei Möglichkeiten. Der erste ist der einfachste. Übernehmen Sie alle Änderungen in den aktuellen Zweig:

git add .
git commit
git checkout new-feature-a

Das würde ich empfehlen. Wenn Sie jedoch wirklich nicht bereit sind, den Code festzuschreiben, können Sie ihn vorübergehend aufbewahren:

git stash

Jetzt können Sie zum Zweig new-feature-a wechseln. Um zu dem Code zurückzukehren, an dem Sie gearbeitet haben, legen Sie einfach den Stash ab:

git checkout new-feature-z
git stash pop

Wenn alles erledigt ist, füge alle Änderungen zum Master zurück:

git merge --no-ff new-feature-a
git merge --no-ff new-feature-z

Weil Zusammenführungen so schnell und einfach sind (einfach, weil Konflikte so selten sind und Konfliktlösung, wenn es passiert, nicht zu schwer), verwenden wir Zweige in Git für alles.

Hier ist ein weiteres Beispiel für eine häufige Verwendung von Zweigen in Git, die Sie in anderen Quellcodeverwaltungs-Tools nicht sehen (außer vielleicht mercurial):

Müssen Sie Ihre Konfigurationsdateien ständig ändern, um Ihre Entwicklungsumgebung widerzuspiegeln? Dann benutze einen Zweig:

git checkout -b dev-config

Bearbeiten Sie nun Ihre Konfigurationsdateien in Ihrem bevorzugten Editor und übernehmen Sie die folgenden Änderungen:

git add .
git commit

Jetzt kann jeder neue Zweig vom dev-config-Zweig anstelle von master starten:

git checkout dev-config
git checkout -b new-feature-branch

Wenn Sie fertig sind, entfernen Sie die Änderungen in dev-config mithilfe der interaktiven Rebase aus dem Zweig für neue Funktionen:

git rebase -i master

Löschen Sie die Commits, die Sie nicht möchten, und speichern Sie sie. Jetzt haben Sie einen sauberen Zweig ohne benutzerdefinierte Konfigurationsänderungen. Zeit, sich wieder dem Master anzuschließen:

git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it's a good idea to rebase dev-config:
git checkout dev-config
git rebase master

Es ist zu beachten, dass das Entfernen von Änderungen mit git rebase -igerade funktioniert, wenn alle Änderungen in derselben Datei vorgenommen werden. Git merkt sich Änderungen, nicht den Dateiinhalt *.

* Hinweis: Eigentlich technisch nicht ganz richtig, aber als Benutzer fühlt es sich so an


Weitere zusätzliche Antwort:

Aus Ihren Kommentaren geht hervor, dass zwei Zweige gleichzeitig existieren sollen, damit Sie testen können, wie der kombinierte Code funktioniert. Dies ist ein guter Weg, um die Leistungsfähigkeit und Flexibilität von Branchen zu veranschaulichen.

Zunächst ein Wort zur Auswirkung billiger Verzweigungen und veränderbarer Historien auf Ihren Workflow. Wenn ich CVS und SVN verwendete, war ich immer etwas zurückhaltend. Das liegt daran, dass das Festschreiben von instabilem Code unweigerlich den Arbeitscode anderer Leute beeinträchtigen würde. Aber mit git habe ich diese Angst verloren. Das liegt daran, dass in git andere Leute meine Änderungen erst erhalten, wenn ich sie zum Master zusammenführe. Jetzt schreibe ich alle 5 Zeilen, die ich schreibe, Code. Sie brauchen keine perfekte Voraussicht, um sich zu verpflichten. Sie müssen nur Ihre Denkweise ändern: Commit-to-Branch == Add-to-Changeset, Merge-to-Master == Commit-Changeset.

Also zurück zu den Beispielen. So würde ich es machen. Angenommen, Sie haben einen Zweig new-feature-zund möchten ihn testen new-feature-a. Ich würde einfach einen neuen Zweig erstellen, um ihn zu testen:

# assume we are currently in branch new-feature-z
# branch off this branch for testing
git checkout -b feature-z-and-feature-a
# now temporarily merge new-feature-a
git merge --no-ff new-feature-a

Jetzt können Sie testen. Wenn Sie etwas ändern müssen, damit Feature-Z mit Feature-A funktioniert, tun Sie dies. In diesem Fall können Sie die Änderungen in den entsprechenden Zweig zurückführen. Verwenden Sie git rebase -idiese Option , um irrelevante Änderungen aus der Zusammenführung zu entfernen.

Alternativ können Sie auch git rebase verwenden, um die Basis von new-feature-z vorübergehend so zu ändern, dass sie auf new-feature-a verweist:

# assume we are currently in branch new-feature-z
git rebase new-feature-a

Jetzt wird der Zweigverlauf so geändert, dass new-feature-z auf new-feature-a anstelle von master basiert. Jetzt können Sie testen. Alle in diesem Zweig festgeschriebenen Änderungen gehören zum Zweig new-feature-z. Wenn Sie die neue Funktion ändern müssen, wechseln Sie einfach zurück und zur Basis, um die neuen Änderungen zu erhalten:

git checkout new-feature-a
# edit code, add, commit etc..
git checkout new-feature-z
git rebase new-feature-a
# now new-feature-z will contain new changes from new-feature-a

Wenn Sie fertig sind, kehren Sie einfach zum Master zurück, um Änderungen von new-feature-a zu entfernen:

# assume we are currently in branch new-feature-z
git rebase master

Haben Sie keine Angst, eine neue Niederlassung zu gründen. Haben Sie keine Angst, einen Wegwerfzweig zu gründen. Hab keine Angst, Äste wegzuwerfen. Und da merge == submit and commit == Add-to-Changeset keine Angst davor hat, häufig festzuschreiben. Denken Sie daran, Commit ist das ultimative Rückgängig-Tool eines Entwicklers.

Oh, und noch etwas, in Git sind noch gelöschte Zweige in Ihrem Repository vorhanden. Wenn Sie also versehentlich etwas gelöscht haben, von dem Sie später feststellen, dass es nützlich ist, können Sie es jederzeit durch Durchsuchen des Verlaufs zurückerhalten. Hab keine Angst, Äste wegzuwerfen.

Slebetman
quelle
1
Hat jeder Zweig seinen eigenen "Index" oder gibt es einen einzelnen Index, der von den Zweigen geteilt wird? Mein Experiment scheint das letztere vorzuschlagen, aber Sie sagen, "ein bestimmter Zweig-Git hat ein Konzept des Index oder Cache", das das erstere vorschlägt.
Laurence Gonsalves
4
Es ist ein anderes Werkzeug. Sie benötigen einen anderen Workflow und damit eine andere Denkweise und Gewohnheit. Kein Git funktioniert nicht so, wie Sie es beschreiben. Es sind Zweige und sonst nichts. Es gibt jedoch sehr leistungsfähige Tools zur Manipulation von Zweigen. Ich schlage vor, Sie betrachten sich als Neuling, der nichts über Quellcodeverwaltung weiß, und lesen die grundlegenden Tutorials. Betrachten Sie Ihre derzeitige Denkweise als "schlechtes Habbit", gegen das Sie im Git-Land umerzogen werden müssen. Entschuldigung ..
Slebetman
1
Was machen Sie in Git, wenn Sie zwei Dinge gleichzeitig bearbeiten möchten (und an derselben Stelle, damit Sie nicht festgeschriebene Änderungen gegeneinander testen können), diese aber separat festschreiben möchten? Wie können Sie eine Festschreibungsnachricht bearbeiten, bevor Sie eine Festschreibung durchführen? Ich kann akzeptieren, dass der Workflow anders ist, aber Sie haben nicht gesagt, was der git-äquivalente Workflow ist. Zu sagen, dass dies schlechte Gewohnheiten sind, klingt sehr nach dem Versuch, einen Fehler als Feature auszugeben.
Laurence Gonsalves
2
Lesen Sie meine aktualisierte Antwort. Sie denken immer noch an nicht festgeschriebene Änderungen, wenn Sie an nicht zusammengeführte Zweige denken sollten.
Slebetman
2
Sehr ausführliche Antwort. Ab wann sollte dies gewikifiziert werden?
Tim Clemons
1

Ich habe nicht genug Erfahrung mit p4, um einen tatsächlichen Spickzettel zu erstellen, aber es gibt zumindest einige Ähnlichkeiten, auf die ich zurückgreifen kann. Ein p4 "Changeset" ist ein Git "Commit".

Änderungen an Ihrem lokalen Arbeitsbereich werden dem "Index" mit hinzugefügt git add, und der Index wird später mit festgeschrieben git commit. Der Index ist also in jeder Hinsicht Ihre ausstehende Änderungsliste.

Sie betrachten Änderungen mit git diffund git status, wobei git diffnormalerweise Änderungen zwischen dem Arbeitsbereich und dem Index angezeigt werden, jedoch git diff --cachedÄnderungen zwischen dem Index und dem Repository (= Ihre ausstehende Änderungsliste).

Für ausführlichere Informationen empfehle ich http://progit.org/book/ . Da Sie die Versionskontrolle im Allgemeinen kennen, können Sie wahrscheinlich viel davon überfliegen und die git-spezifischen Informationen extrahieren ...

Jakob Borg
quelle
1
Ich würde nicht zustimmen, dass "ein p4-Änderungssatz ein Git-Commit ist"; Sie sind zwar die nächsten Äquivalente, aber ein p4-Änderungssatz ist einer Reihe von Git-Commits viel näher. Ein p4-Änderungssatz repräsentiert ein Merkmal, während ein Git-Zweig ein Merkmal darstellt.
RJFalconer
@RJFalconer Erm. Ein "Zweig" ist auch ein Zweig in Perforce, nicht wahr? Und ein "Changeset" ist eine atomare Sammlung von Änderungen an einer oder mehreren Dateien, ähnlich einem Commit? Wenn nicht, was ist Ihrer Meinung nach das p4-Äquivalent von Commit?
Jakob Borg
Ich würde sagen, dass p4 kein Äquivalent hat, einfach weil der Grad der Atomizität nicht der gleiche ist; In Git kann ich mehrere Änderungen an einer bestimmten Datei vornehmen und diese dann in verschiedenen Commits festschreiben (git add -p), wodurch Refactoring / Bereinigung im Verlauf von Feature / Bugfix getrennt wird. Wenn ich dies in p4 tun würde, müsste ich die beiden getrennt entwickeln. Selbst dann sind meine Commits möglicherweise nicht kontinuierlich, da andere Entwickler sie zwischen sich einreichen können (es sei denn, ich habe eine private Niederlassung, bei der häufig unpraktisch auf der Festplatte dupliziert wird).
RJFalconer
Haftungsausschluss: Ich habe p4 erst seit einigen Monaten verwendet und es ist durchaus möglich, dass es eine Funktion gibt, die dies bewirkt, auf die ich bisher noch nicht gestoßen bin.
RJFalconer
p4-Änderungslisten und p4-Zweige sind logisch dieselben wie Git-Commits und Git-Zweige. Das p4-Regal entspricht dem Git-Stash. Wo sie sich unterscheiden, liegt in der Implementierung (dh verteilt gegenüber Client-Server) und dieser Unterschied führt zu einem p4-Äquivalent zum Git-Checkout, das mehrere Schritte und viel Zeit umfasst. Der Overhead ist so bemessen, dass in der Regel mehrere Zweige lokal auf der Festplatte gespeichert werden, anstatt das Äquivalent zum Git-Checkout auszuführen. p4-Regale werden auf dem Server und nicht im lokalen Repo gespeichert.
Josh Heitzman
1

Ich leide wie Sie unter dem Fehlen des "Changelist" -Konzepts, das nicht genau mit Git-Zweigen identisch ist.

Ich würde ein kleines Skript schreiben, das eine Änderungslistendatei mit der Liste der Dateien in dieser Änderungsliste erstellt.

Ein weiterer Befehl, um nur eine bestimmte Änderungsliste zu senden, indem Sie einfach git commit -a @ change_list_contents.txt und dann "git commit" aufrufen.

Hoffe das hilft, Elias

Elias Bachaalany
quelle
Ja, ich habe tatsächlich darüber nachgedacht, so etwas zu tun, obwohl ich zu dem Zeitpunkt, als ich diese Frage stellte, neu in Git war und deshalb die "native" Lösung kennenlernen wollte. Jetzt finde ich, dass die Hauptsache, die ich vermisse, die Fähigkeit ist, an einer Festschreibungsnachricht zu arbeiten, ohne sie tatsächlich festzuschreiben. Dies könnte gelöst werden, indem eine Datei vorhanden ist, die die "ausstehende Festschreibungsnachricht" enthält, und möglicherweise etwas Magie, um sie beim Schreiben einer Festschreibungsnachricht automatisch zu lesen.
Laurence Gonsalves
@LaurenceGonsalves, der Workflow, den ich verwende, besteht darin, unvollständige Festschreibungsnachrichten (oder sogar nur "WIP") festzuschreiben, während ich mich auf die Arbeit konzentriere, und sie später während meiner Rebase zu ändern. Da Commits rein lokal sind, müssen sie erst endgültig sein, wenn Sie Ihren Zweig verfügbar machen (indem Sie ihn auf Ihre Fernbedienung oder ähnliches übertragen).
RJFalconer
1

Es gibt eine leichtere Alternative in Git, die Teil Ihres Workflows sein könnte. Verwenden des Git-Staging-Bereichs.

Ich nehme oft nur Änderungen vor und sende sie dann als mehrere Commits (z. B. Debug-Anweisungen hinzufügen, Refactor, tatsächlich einen Fehler beheben). Anstatt Ihre Perforce-Änderungslisten einzurichten, dann Änderungen vorzunehmen und dann zu senden, können Sie einfach Ihre Änderungen vornehmen und dann auswählen, wie sie gesendet werden sollen (optional über den Git-Staging-Bereich).

Sie können bestimmte Dateien über die Befehlszeile festschreiben mit:

git commit a.txt
git commit z.txt

Oder stellen Sie die Dateien zuerst explizit bereit:

git add a.txt
git commit
git add z.txt
git commit

Mit Git GUI können Sie Zeilen oder Hunks aus Dateien auswählen, um ein Commit im Staging-Bereich aufzubauen. Dies ist sehr nützlich, wenn Sie Änderungen an einer Datei haben, die in verschiedenen Commits enthalten sein sollen. Von git zu perforiert gewechselt zu sein und das ist eine Sache, die ich wirklich vermisse.

Bei diesem Workflow ist eine kleine Einschränkung zu beachten. Wenn Sie Änderungen A und B an einer Datei vornehmen, die Datei testen und dann A festschreiben, haben Sie diese Festschreibung nicht getestet (unabhängig von B).

Russell Gallop
quelle
Es ist sicher wahr, dass Sie mit Git noch feinkörnigere Commits ausführen können als perforce (dh Linien und Hunks). Das, was ich von perforce (noch) vermisse, ist die Fähigkeit, die Änderungsbeschreibung (auch als Commit-Nachricht bezeichnet) für das, woran ich gerade arbeite, im Auge zu behalten. Wenn ich zum Beispiel den Fehler Nr. 12345 behebe, erstelle ich eine Änderungsliste, in der steht, dass ich das getan habe (aber nicht, auch bekannt als Commit). Während ich daran arbeitete, aktualisierte ich die Änderungsbeschreibung, um anzugeben, was ich getan hatte. Wenn ich fertig bin, würde ich die Änderungsliste festschreiben.
Laurence Gonsalves
In git scheint es das grobe Äquivalent zu sein, diese winzigen (oft nicht funktionierenden) Bits in einen Entwicklungszweig zu übertragen und dann, sobald alles in Ordnung ist, die Änderungen zusammenzuführen. Das fühlt sich für mich immer noch viel langweiliger und klobiger an. Außerdem habe ich mich immer noch nicht wirklich an die Idee gewöhnt, Code zu schreiben, der nicht einmal kompiliert wird.
Laurence Gonsalves
@LaurenceGonsalves Neugierig, wenn Sie sich in der Zwischenzeit daran gewöhnt haben. Ich komme von Git zu Perforce und vermisse es, alle 15 Minuten ein Commit durchführen zu können.
Damian
0

Dies beantwortet Ihre Frage nicht speziell, aber ich weiß nicht, ob Sie wissen, dass eine 2-Benutzer-, 5-Arbeitsbereich-Version von perforce kostenlos von der perforce-Website heruntergeladen und verwendet werden kann .

Auf diese Weise können Sie perforce zu Hause für Ihre persönlichen Projekte verwenden, wenn Sie dies wünschen. Das einzige Ärgernis sind die 5 Arbeitsbereiche, die etwas einschränkend sein können, aber es ist ziemlich unglaublich, dass Perforce für den Heimgebrauch verfügbar ist.

Toby Allen
quelle
2
Das hatte ich getan, aber ich möchte zu etwas wechseln, das Open Source ist und auch von Open Source-Projekten verwendet wird.
Laurence Gonsalves
0

Nachdem ich sowohl Perforce als auch Git ziemlich häufig verwendet habe, gibt es nur einen Weg, wie ich mit Git irgendwo in die Nähe von Perforce-Änderungslisten gelangen kann.

Das erste, was zu verstehen ist, ist, dass die korrekte Implementierung dieser Funktionalität in git so, dass es sich nicht um eine vollständige Kluge handelt, z. B. der Versuch, sie in Zweige zu zerlegen, die folgende Änderung erfordert: git würde mehrere Staging-Bereiche für einen einzelnen Zweig erfordern .

Perforce-Änderungslisten ermöglichen einen Workflow, der in git einfach kein Äquivalent hat. Betrachten Sie den folgenden Workflow:

Check out a branch
Modify file A and add it to changelist 1
Modify file B and add it to changelist 2

Wenn Sie versuchen, dies mit Zweigen in Git zu tun, werden Sie zwei Zweige erhalten, von denen einer die Änderungen an der Datei enthält A, der andere die Änderungen an der Datei B, aber keinen Ort, an dem Sie die Änderungen an beiden Dateien Aund Bunter sehen können die selbe Zeit.

Die nächste Annäherung, die ich sehen kann, besteht darin, git add . -pdie Unterbefehle 'a'und zu verwenden und dann zu verwenden 'd', um ganze Dateien auszuwählen oder abzulehnen. Dies ist jedoch nicht ganz dasselbe, und der Unterschied ergibt sich aus einer grundlegenden Ungleichheit in der allgemeinen Funktionsweise der beiden Systeme.

Git (und Subversion, nicht dass es für diese Diskussion wichtig ist) ermöglichen es, eine Datei zu ändern, ohne vorher jemandem davon zu erzählen. Sie ändern einfach eine Datei und lassen git alles sortieren, wenn Sie die Änderungen festschreiben. Perforce erfordert, dass Sie eine Datei aktiv auschecken, bevor Änderungen zulässig sind. Aus diesem Grund müssen Änderungslisten vorhanden sein. Perforce erfordert im Wesentlichen, dass Sie dem Index eine Datei hinzufügen, bevor Sie sie ändern. Daher die Notwendigkeit mehrerer Änderungslisten in Perforce und auch der Grund, warum Git kein Äquivalent hat. Es braucht sie einfach nicht.

dgnuff
quelle
0

Mit Git 2.27 (Q2 2020) lernte " git p4" vier neue Hooks und auch die --no-verifyOption " ", sie (und den vorhandenen " p4-pre-submit" Hook) zu umgehen .

Siehe Commit 1ec4a0a , Commit 38ecf75 , Commit cd1e0dc (14. Februar 2020) und Commit 4935c45 , Commit aa8b766 , Commit 9f59ca4 , Commit 6b602a2 (11. Februar 2020) von Ben Keene ( seraphire) .
(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 5f2ec21 , 22. April 2020)

git-p4: p4 Submit Hooks hinzufügen

Unterzeichnet von: Ben Keene

Der git-Befehl " commit" unterstützt eine Reihe von Hooks, die das Ändern des Verhaltens des Commit-Befehls unterstützen.

Das git-p4.pyProgramm hat nur einen vorhandenen Hook, " p4-pre-submit".

Dieser Befehl tritt früh im Prozess auf.

Der Prozessablauf enthält keine Hooks zum programmgesteuerten Ändern des P4-Änderungslistentextes.

Fügt git-p4.pyder Submit-Option 3 neue Hooks hinzu .

Die neuen Haken sind:

  • p4-prepare-changelist- Führen Sie diesen Hook aus, nachdem die Änderungslistendatei erstellt wurde.
    Der Hook wird auch dann ausgeführt, wenn die --prepare-p4-onlyOption gesetzt ist.
    Dieser Hook ignoriert die --no-verifyOption entsprechend dem vorhandenen Verhalten von git commit.

  • p4-changelist- Führen Sie diesen Hook aus, nachdem der Benutzer die Änderungsliste bearbeitet hat.
    Führen Sie diesen Hook nicht aus, wenn der Benutzer die --prepare-p4-onlyOption ausgewählt hat .
    Dieser Haken wird die --no-verifynach den Konventionen von ehren git commit.

  • p4-post-changelist- Führen Sie diesen Hook aus, nachdem der P4-Übermittlungsprozess erfolgreich abgeschlossen wurde.
    Dieser Hook akzeptiert keine Parameter und wird unabhängig von der --no-verifyOption ausgeführt.

Der Rückgabewert wird nicht überprüft.

Die Anrufe an die neuen Haken: p4-prepare-changelist, p4-changelistund p4-post-changelistsollten alle innerhalb des try-finally - Block aufgerufen werden.


Vor Git 2.28 (Q3 2020) soll die --prepare-p4-onlyOption " " nach der Wiedergabe eines Änderungssatzes beendet werden, aber (versehentlich?) Weitergeführt werden.

Siehe Commit 2dfdd70 (12. Mai 2020) von Ben Keene ( seraphire) .
(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 7a8fec9 , 02. Juni 2020)

git-p4.py: --prepare-p4-onlyFehler mit mehreren Commits beheben

Unterzeichnet von: Ben Keene

Bei Verwendung git p4 submitmit dieser --prepare-p4-onlyOption sollte das Programm eine einzelne p4-Änderungsliste erstellen und den Benutzer darüber informieren, dass weitere Commits ausstehen, und dann die Verarbeitung beenden.

Durch die p4-changelistHook-Funktion wurde ein Fehler eingeführt , der dazu führt, dass das Programm weiterhin versucht, alle ausstehenden Änderungslisten gleichzeitig zu verarbeiten.

Die Funktion applyCommitkehrt zurück, Truewenn das Festschreiben erfolgreich war und das Programm fortgesetzt werden sollte.
Wenn jedoch das optionale Flag --prepare-p4-onlygesetzt ist, sollte das Programm nach der ersten Anwendung gestoppt werden.

Ändern Sie die Logik in der Ausführungsmethode für P4Submit, um --prepare-p4-onlynach erfolgreichem Abschluss der applyCommitMethode nach dem Flag zu suchen .

Wenn mehr als 1 Commit bis zur Übermittlung an P4 ansteht, bereitet die Methode die P4-Änderungsliste ordnungsgemäß vor, beendet die Anwendung jedoch weiterhin mit einem Exitcode von 1.

In der aktuellen Dokumentation ist nicht definiert, wie der Exit-Code in diesem Zustand lauten soll.

VonC
quelle