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

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

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

создать несколько ожидающих изменений в одном клиенте. (p4 change)редактировать ожидающий список изменений. (такжеp4 change)см. список всех моих ожидающих изменений (p4 changes -s pending)список всех измененных файлов в моем клиенте (p4 opened) или в ожидающем списке изменений (p4 describe)увидеть разницу ожидающих изменений (я использую скрипт-обертку для этого, который используетp4 diff а такжеp4 describe)для данного файла посмотрите, какие представленные списки изменений повлияли на какие строки (p4 annotate)для данного файла см. список описаний списков изменений, которые повлияли на файл (p4 log)отправить ожидающий список изменений (p4 submit -c)отменить ожидающий список изменений (p4 revert)

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

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

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

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

На данный момент у меня есть список изменений, который содержит .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 он собирается зафиксировать все файлы, которые яgit addНезависимо от того, в какой отрасли я был в то время:

$ 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

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