面向Perforce用户的Git

我已经使用Perforce很多年了。我想转而使用git编写我的个人代码，但我看到的所有git教程要么假设您是一个完整的源代码管理n00b（这让它们变得非常乏味），要么假设您已经习惯svn（我不是）

我知道p4，我也理解分布式源代码控制系统背后的想法（所以我不需要推销，谢谢）。我想要的是一个从p4命令到等效git命令的转换表，以及没有p4等效命令的“离不开”命令

由于我怀疑每个p4用户都使用不同的p4子集，下面是我在p4中经常做的一些事情，我希望能够在git中做这些事情，这些事情在我看过的文档中并不明显：

在单个客户端中创建多个挂起的变更列表。（

p4更改

）

编辑挂起的变更列表。（同时

p4更改

）

查看所有挂起的更改列表（

p4更改-s挂起

）

我的客户端（

p4已打开）或挂起的更改列表（
p4描述
）中所有已更改文件的列表

查看挂起变更列表的差异（我为此使用了一个包装器脚本，它使用

p4diff

和

p4descripe

）

对于给定的文件，请参阅哪些提交的变更列表影响了哪些行（

p4 annotate

）

对于给定文件，请参阅影响该文件的变更列表的描述列表（

p4 log

）

提交挂起的变更列表（

p4 submit-c

）

中止挂起的变更列表（

p4 revert

）

其中很多都是围绕“变更列表”展开的。“变更列表”是p4术语。git的等价术语是什么

听起来git用户可能使用分支来代替p4所称的变更列表。有点混乱，因为p4也有一个叫做分支的东西，尽管它们似乎只是模糊相关的概念。（虽然我一直认为p4的分支概念很奇怪，但它与经典的RCS分支概念又有了不同。）

无论如何。。。我不知道如何完成我通常在带有git分支的p4变更列表中所做的工作。在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中复制它。从我的实验来看，

gitadd

似乎与当前分支没有关联。据我所知，当我

git提交时

它将提交我

git添加的所有文件

-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 init
已在/home/laurence/Git playerly/.Git中初始化空Git存储库/
$ls
a、 txt w.txt z.txt
$git添加-A。
$git提交
初始提交。
3个文件已更改，3个插入（+），0个删除（-）
创建模式100644 a.txt
创建模式100644 w.txt
创建模式100644 z.txt
$vi a.txt z.txt
2个要编辑的文件
$git状态
#论分行行长
#已更改但未更新：
#（使用“git add…”更新将提交的内容）
#（使用“git签出--…”放弃工作目录中的更改）
#
#修改：a.txt
#修改：z.txt
#
未向提交添加任何更改（使用“git add”和/或“git commit-a”）
$git aardvark分行
$git结帐土豚
M a.txt
mz.txt
切换到aardvark分支
$git add a.txt
$git签出主机
M a.txt
mz.txt
切换到“主”分支
$git斑马分行
$git结帐斑马
M a.txt
mz.txt
切换到“斑马”分支
$git add z.txt
$git状态
#斑马
#要提交的更改：
#（使用“git重置磁头…”取消分级）
#
#修改：a.txt
#修改：z.txt
#
$git结帐土豚
M a.txt
mz.txt
切换到aardvark分支
$git状态
#树枝上的土豚
#要提交的更改：
#（使用“git重置磁头…”取消分级）
#
#修改：a.txt
#修改：z.txt

---

在本例中，aardvark和zebra分支似乎包含完全相同的一组更改，并且根据

git status

的输出，在这两个分支中进行提交似乎具有相同的效果。我做错什么了吗？

我没有足够的p4经验来制作一份真正的备忘单，但至少有一些相似之处可以依靠。p4“变更集”是git“提交”

使用

git add

将对本地工作空间的更改添加到“索引”中，然后使用

git commit

提交索引。因此，无论出于何种目的，索引都是挂起的变更列表

使用

git diff

和

git status

查看更改，其中

git diff

通常显示工作区和索引之间的更改，但

git diff--cached

显示索引和存储库之间的更改（=挂起的更改列表）

---

要获得更深入的信息，我建议。由于您一般都了解版本控制，您可能会浏览很多版本控制，并提取git特定的信息…

我没有太多使用Performance，因此这可能不是一个1:1的翻译。然后，像git和mercurial这样的分布式源代码管理系统有一个不同的工作流程，所以实际上没有（也不应该有）1:1的翻译。不管怎样，下面是：

• 创建多个挂起的变更列表->改用分支。在git中，分支轻快，创建不到一秒钟，合并通常不到两秒钟。不要

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

  git checkout -b new-branch-name
  

  git branch
  

  git branch -a
  

  git status
  

  git diff
  

  git diff HEAD
  

  git blame filename
  

  git gui blame filename
  

  git log filename
  

  git commit
  

  git checkout -b new-feature-a
  

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

  git checkout new-feature-a
  

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

  git stash
  

  git checkout new-feature-z
  git stash pop
  

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

  git checkout -b dev-config
  

  git add .
  git commit
  

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

  git rebase -i master
  

  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
  

  # 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
  

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

  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
  

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

  git commit a.txt
  git commit z.txt
  

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

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