He estado usando Perforce por varios años. Me gustaría cambiar a usar git para mi código personal, pero todos los tutoriales de git que he visto suponen que eres un completo control de fuente n00b (lo que los hace increíblemente tediosos) o que estás acostumbrado svn (que no soy).

Sé p4, y también entiendo la idea detrás de un sistema de control de fuente distribuida (por lo que no necesito un argumento de venta, gracias). Lo que me gustaría es una tabla de traducción del comando p4 a comandos git equivalentes, así como los comandos "no se puede vivir sin" que no tengan equivalente p4.

Como sospecho que cada usuario de p4 usa un subconjunto diferente de p4, estas son algunas de las cosas que hago regularmente en p4 que me gustaría poder hacer en git que no son inmediatamente obvias de los documentos que he visto. :

crear múltiples listas de cambios pendientes en un solo cliente. (p4 change)editar una lista de cambios pendiente. (ademásp4 change)ver una lista de todas mis listas de cambios pendientes (p4 changes -s pending)lista de todos los archivos modificados en mi cliente (p4 opened) o en una lista de cambios pendiente (p4 describe)veo una diferencia de una lista de cambios pendiente (uso un script de contenedor para esto que usap4 diff yp4 describe)para un archivo determinado, vea qué listas de cambios enviadas afectaron qué líneas (p4 annotate)para un archivo dado, vea una lista de las descripciones de las listas de cambios que afectaron el archivo (p4 log)enviar una lista de cambios pendiente (p4 submit -c)abortar una lista de cambios pendiente (p4 revert)

Muchos de estos giran en torno a "listas de cambios". "lista de cambios" es la terminología p4. ¿Cuál es el término equivalente de git?

Parece que las ramas podrían ser lo que usan los usuarios de git en lugar de lo que p4 llama listas de cambios. Un poco confuso, ya que p4 también tiene algo llamado rama, aunque parecen ser conceptos vagamente relacionados. (Aunque siempre pensé que el concepto de p4 de una rama era bastante extraño, es diferente una vez más del concepto clásico de RCS de una rama).

De todos modos ... No estoy seguro de cómo lograr lo que normalmente hago en las listas de cambios p4 con las ramas de git. En p4 puedo hacer algo como esto:

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

En este punto tengo una lista de cambios que contiene a.txt. Puedo editar la descripción y seguir trabajando sin enviar la lista de cambios. Además, si resulta que necesito hacer algunos cambios en otros archivos, como decir una corrección de errores en alguna otra capa del código, puedo hacerlo en el mismo cliente:

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

Ahora tengo dos listas de cambios separadas en el mismo cliente. Puedo trabajar en estos simultáneamente, y no necesito hacer nada para "cambiar entre ellos". Cuando llega el momento de comprometerse, puedo enviarlos por separado:

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

No puedo entender cómo replicar esto en git. De mis experimentos, no parece quegit add está asociado con la rama actual. Por lo que puedo decir, cuando yogit commit va a confirmar todos los archivos que yogit add-ed no importa en qué rama estaba en ese momento:

$ 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

En este ejemplo, las ramas de oso hormiguero y cebra parecen contener exactamente el mismo conjunto de cambios, y se basan en el resultado degit status parece que hacer un commit en cualquiera tendrá el mismo efecto. ¿Estoy haciendo algo mal?