从Perforce到Git的迁移

公司经过多次兼并、收购之后，开发团队使用的工具自然会出现鱼龙混杂的现象。就拿源代码管理工具来说，我们同时在使用的就有Perforce、Team Foundation、Subversion等。为了节省成本，也为了统一工程实践（以提高工作效率），我们决定让所有团队迁移到Git。

                 

      集中式（Centralized）的源代码管理                               分布式的（Distributed）源代码管理

之所以选择Git，是因为：

1. 它是主流的；
2. 它是免费、开源的；
3. 它支持分布式开发——这一点特别适合跨国团队；
4. 它支持离线环境下的开发（因为每台开发机本地都有一个代码仓库depository）；
5. 它是跨平台的（支持Windows、MAC、Linux）。

Git工具可以到http://git-scm.com/上去下载。为了方便操作，也可以使用一些带图形界面的Git工具。关于Git的介绍，网上可以找到很多资料。（顺便推荐一下中文版的《Pro Git》：http://git-scm.com/book/zh。）我想在这里分享的是，我们是怎么把一大堆老项目（主要在Perforce上）迁移到Git的。（Perforce用了将近9年，终于要说“bye-bye”啦……）

在Perforce上，我们为每个产品建立了一个*目录。然后，在它下面分别有Main、Work、ThirdParty、Release等子目录。Main里存放一个产品的主要代码，大部分人直接在这上面工作；Work里存放一些试验性质的代码，或者自己开发的小工具；ThirdParty里存放来自第三方的SDK；而Release里存放从Main派生出来的各个版本，典型情况下是为各个客户做的定制和发布，我们一般把它们命名为RelCustomerXV1、RelCustomerXV2、RelCustomerYV1、RelCustomerZV3……整个代码结构看起来是这样的：

在往Git迁移的过程中，Perforce上每个Changelist的历史记录是移不过去的（或许只是我们不知道……）。我们的办法是：在公司里仍然保留一台Perforce服务器，并开放有限的几个账号，必要时可以提供查询功能；将Perforce上最新的一份代码放到Git上去，并且以后所有的开发都在Git上进行。

我们的迁移是这么做的：首先，由管理员在Git服务器上为每个产品建立一个空的代码仓库，比如ios.git、android.git、pcmac.git等；然后，由各个产品的开发主管负责代码的上传与分支的建立。这里的焦点问题是：如何处置那些RelCustomerXXX分支？因为Perforce的分支概念与Git的有较大的区别：Perforce做的是实实在在的代码拷贝，而Git在创建分支时保存的只是指针或引用。要在Git里为每一个RelCustomerXXX创建分支吗？这样的话，服务器上的分支看起来会比较多（通过git
branch -a命令查看），容易造成日后的混淆。经过团队讨论，我们最终决定把这些RelCustomerXXX都建在master上（不另外创建分支），由此带来的问题是：master的体量比较大，在开发人员第一次做git clone的时候会比较耗时。忍了！

往Git上传代码的过程是在Git Bash（Windows | All Programs | Git）里通过执行一系列git命令来完成的。具体步骤如下（以iOS产品为例）：

假设你的工作目录（Working Directory）在D:\GitWorkspace。在运行Git Bash之后，你需要执行cd D:\GitWorkspace进入该目录。然后执行git clone命令将空的代码仓库克隆到本地：

git clone <server URL>:ios.git

克隆完成之后，执行cd命令进入本地仓库（你可以看到默认指向了master）。然后，在文件浏览器里，将Perforce上拿到的最新的产品代码拷贝到D:\GitWorkspace\ios\main中，并且在D:\GitWorkspace\ios\customer_releases\下面建立子目录、拷入各个RelCustomerXXX分支的代码，还有其他一些文件（比如work、thirdparty）都拷入D:\GitWorkspace\ios\……当所有文件都准备好之后，在Git Bash里依次执行下面的命令：

git add -A

git commit -m "the initial porting from Perforce"

git remote add origin <server URL>:ios.git

git push origin master

如果上传的代码比较多，上述过程会比较耗时。至于日后在Git上的产品开发，我们决定采用“Gitflow工作流程”。因此，在完成上述的代码上传之后，每个产品的开发主管须立即创建一个develop分支：

git branch develop

git push -u origin develop

最后，别忘了让另一个开发人员在他的机器上拉一下代码（执行git clone或git pull命令），然后试着编译一下，看看是否有部分文件遗漏了。（完）