Git для пользователей Perforce

Я использую Perforce в течение нескольких лет . Я хотел бы переключиться на использование git для моего личного кода, но все учебные пособия по git, которые я видел, либо предполагают, что у вас есть полный исходный контроль n00b (что делает их невероятно утомительными), либо что вы привыкли к svn (а я не такой).

Я знаю p4, и я также понимаю идею распределенной системы управления исходным кодом (так что мне не нужны коммерческие предложения, спасибо). Что мне нужно, так это таблица перевода из команды p4 в эквивалентные команды git, а также команды «не могу жить без», у которых нет эквивалента p4.

Поскольку я подозреваю, что каждый пользователь p4 использует другое подмножество p4 , Вот некоторые из вещей, которые я регулярно делаю в p4, которые я бы хотел делать в git, которые не сразу очевидны из документов, которые я просмотрел:

1. создание нескольких ожидающих списков изменений в одном клиенте. ( p4 изменить )
2. редактировать ожидающий список изменений. (также p4 change )
3. см. список всех моих ожидающих списков изменений ( p4 changes -s pending )
4. список всех измененных файлов в моем клиенте ( p4 открыт ) или в ожидающем списке изменений ( p4 description )
5. см. Разницу в ожидающем списке изменений (я использую для этого сценарий оболочки, который использует p4 diff и p4 описывают )
6. для данного файла, посмотрите, какие отправленные списки изменений повлияли на какие строки ( p4 annotate )
7. для данного файла, см. список описаний списков изменений, которые повлияли на файл ( p4 log )
8. отправить ожидающий список изменений ( p4 submit -c )
9. отменить ожидающий список изменений ( p4 revert )

Многие из них вращаются вокруг «списков изменений». "список изменений" - это терминология p4. Что такое термин, эквивалентный git?

Похоже, что ветки могут быть тем, что пользователи git используют вместо того, что p4 вызывает списки изменений. Немного сбивает с толку, поскольку в p4 также есть нечто, называемое ветвью, хотя они, кажется, являются лишь смутно связанными понятиями. (Хотя я всегда думал, что концепция ветки p4 была довольно странной, она снова отличается от классической концепции RCS ветки.)

В любом случае ... Я не уверен, как выполнить то, что я обычно делаю в списках изменений p4 с ветвями git. В p4 я могу сделать что-то вроде этого:

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

На данный момент у меня есть список изменений, содержащий a.txt. Я могу отредактировать описание и продолжить работу, не отправляя список изменений. Кроме того, если выяснится, что мне нужно внести некоторые изменения в некоторые другие файлы, например, исправить ошибку в каком-то другом слое кода, я могу сделать это в том же клиенте:

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

Теперь у меня есть два отдельных списка изменений в тот же клиент. Я могу работать над ними одновременно, и мне не нужно ничего делать, чтобы «переключаться между ними». Когда приходит время коммита, я могу отправить их отдельно:

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

Я не могу понять, как воспроизвести это в git. Из моих экспериментов не видно, что git add связан с текущей веткой. Насколько я могу судить, когда я git commit это ' s собираюсь зафиксировать все файлы, которые я git add -ed, независимо от того, в какой ветке я находился в то время:

$ 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

В этом примере ветви трубкозуба и зебры, похоже, содержат точно такой же набор изменений , и на основании вывода git status кажется, что выполнение фиксации в любом из них будет иметь тот же эффект. Я что-то делаю не так?