Ich benutze Perforce seit einigen Jahren. Ich würde gerne auf Git für meinen persönlichen Code umsteigen, aber in allen Tutorials, die ich gesehen habe, wird davon ausgegangen, dass Sie eine vollständige Quellcodeverwaltung n00b haben (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 Quellcodeverwaltungssystem (daher brauche ich kein Verkaufsgespräch, danke). Was ich möchte, ist eine Übersetzungstabelle von p4-Befehlen zu äquivalenten git-Befehlen 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 machen möchte, die aus den von mir untersuchten Dokumenten nicht sofort ersichtlich sind beim

erstellen Sie mehrere ausstehende Änderungslisten in einem einzigen Client. p4 change)Bearbeiten Sie eine ausstehende Änderungsliste. (ebenfallsp4 change)siehe eine Liste aller meiner ausstehenden Änderungslisten p4 changes -s pending) Liste aller geänderten Dateien in meinem Client p4 opened) oder in einer ausstehenden Änderungsliste p4 describe)sehe ein Diff einer ausstehenden Änderungsliste (ich benutze ein Wrapper-Skript dafür, das @ verwendp4 diff undp4 describe)ehen Sie für eine bestimmte Datei, welche übermittelten Änderungslisten sich auf welche Zeilen ausgewirkt haben p4 annotate)für eine bestimmte Datei finden Sie eine Liste der Beschreibungen der Änderungslisten, die die Datei betroffen haben p4 log)Sende eine ausstehende Änderungsliste p4 submit -c)abort eine ausstehende Änderungsliste p4 revert)

Viele davon drehen sich um "Changelisten". "Änderungsliste" ist die p4-Terminologie. Was ist das Git-Äquivalent?

Es hört sich so an, als ob Verzweigungen das sind, was Git-Benutzer anstelle dessen verwenden, was p4 Änderungslisten nennt. Ein bisschen verwirrend, da p4 auch so etwas wie eine Verzweigung hat, obwohl es sich scheinbar nur um vage verwandte Konzepte handelt. (Obwohl ich immer dachte, dass das p4-Konzept eines Zweigs ziemlich seltsam ist, unterscheidet es sich doch wieder vom klassischen RCS-Konzept eines Zweigs.)

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

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

An diesem Punkt 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, wie z. B. einen Bugfix in einer anderen Codeschicht, 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. Daran kann ich gleichzeitig arbeiten, und ich muss nichts tun, um zwischen ihnen "umzuschalten". Wenn es Zeit ist, mich zu verpflichten, 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 man dies in Git repliziert. Aus meinen Experimenten geht nicht hervor, dassgit add ist dem aktuellen Zweig zugeordnet. Soweit ich das beurteilen kann, wenn ichgit commit Es werden alle Dateien festgeschrieben, die ichgit add -ed egal in welcher Branche ich mich gerade 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 Aardvark- und Zebra-Zweige genau die gleichen Änderungen zu enthalten und basieren auf der Ausgabe vongit status Es scheint, dass das Ausführen eines Commits in beiden Fällen den gleichen Effekt hat. Mache ich etwas falsch