公司经过多次兼并、收购之后,开发团队使用的工具自然会出现鱼龙混杂的现象。就拿源代码管理工具来说,我们同时在使用的就有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命令),然后试着编译一下,看看是否有部分文件遗漏了。(完)

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐