内容目录
文档控制2
1.概述4
1.1.概述4
1.2.参考资料4
2.Git相关知识5
2.1.Git代码管理5
3.使用命令行做代码管理和Review7
3.1.概述7
3.2.项目代码管理7
3.3.项目代码Review11
4.使用Eclipse的Git插件做代码管理13
4.1.概述13
4.2.项目代码管理13
4.3.项目代码Review24
本章主要描述文档功能,即当使用Git作为代码管理工具,并结合Phabricator的Arcanist命令行工具做代码Review时,项目从pull到push全程的操作方法。包括两种方式:仅使用命令行和使用Eclipse的Git插件结合命令行。
文档编写基于无限极项目,描述了:开发人员从领取到开发任务到最终代码提交过程中如何进行代码管理和Review。
本章节主要讲解必要的Git相关知识,帮助对文档内容的理解。
本章只讲解代码管理过程中用到的分支创建与合并。
使用Git做项目代码管理时,从宏观上看主分支只有一条:master,每当有新功能开发完成并提交,master分支都会向前移动一步,越来越长。图中HEAD指的是当前分支,它直接指向的是分支,而不是提交(节点)。
当我们创建新的分支,例如 dev 时,Git 新建了一个指针叫 dev,指向 master 相同的提交,再把 HEAD 指向 dev,就表示当前分支在 dev 上:
创建并切换到一个新的分支工作区不会有任何变化。但是再次对工作区的修改和提交就是针对dev分支的了,每次提交,dev会向前移动一步,而master不变。
假如我们在 dev 上的工作完成了,就可以把 dev 合并到 master 上。Git 怎么合并呢?首先切换到master分支,你会发现工作区的内容神奇的还原了。这时你就需要将dev的更改内容合并到master分支了。
使用git merge someBranch命令,可以将someBranch合并到当前分支,删除无用的开发分支,一次功能的开发就完成了。
另外你还需要知道的就是远程和本地的概念。认识什么是远程仓库和本地仓库,并掌握远程分支、本地分支和它们之间的各种操作。
学习地址:http://git-scm.com/book/zh/ch3-5.html
本章以只使用命令行的方式来做代码管理和Review
开发人员接到新的开发任务后,如果没有拉取过远程仓库代码,就拉取一次。否则请先更新到代码最新状态。然后,由第一个人创建一个新的开发分支并推送到远程。再然后,所有开发同一功能的开发人员跟踪对应的远程开发分支,进行开发。最后功能开发完成时,由最后一人提交代码统一提交代码Review,通过后将代码提交到master。功能开发完成。
使用Git Bash或命令行工具,在系统合适位置(如:E:\MyWorkspace)拉取远程仓库代码,这个位置将作为本地仓库。
如果已有对应远程仓库的本地仓库,在本地仓库执行指令”git pull”获取到最新代码,再继续下面的步骤。
这里只解释一遍”git pull”的含义:如果当前分支在跟踪一个远程分支,则将这个远程分支的最新代码拉取到本地仓库。这个解释只是概述大意,不做更深的讨论,想进一步了解,请查看2.1.2小节提供的参考网址。
如果新的开发任务已经创建好了远程分支,则跳到步骤3.2.3.否则创建一个新的开发分支
然后将这个分支推送到远程,远程分支的命名请按照具体规定
此时发现当前分支并没有跟踪远程的开发分支,这就需要下一步
跟踪远程开发分支
其实这句指令是新建一个跟远程分支同名的分支并跟踪这个远程分支。所以这个remote_T34分支是一个本地分支!
功能开发。
如果代码有修改,运行”git status”时Git会给出一些有意义的提示
对修改的代码进行一次提交
再次运行”git status”命令,提示没有需要提交的了,并建议使用”git push”命令将本地修改推送到远程。
代码推送后,执行”git status”发现自己本地仓库的代码已经是最新的了。
本节描述了一次提交。其实一个正常的功能开发就应该伴随着无数次的开发和提交的迭代。
当功能开发完成后,就需要将开发分支的代码合并到master主分支了。这一步是在提交代码Review之前的准备。
首先切换到master分支
当然这个master其实也是本地分支,只是它名字跟远程主分支一样而且它在跟踪远程master。在合并前还需要保证合并的两者都是最新的代码,所以
然后,可以放心合并了。”git merge someBranch”的意思是将someBranch分支的内容合并到当前分支下。
注意这次合并是在本地master分支下,合并本地remote_T34分支的内容。然后你告诉我本地master和本地remote_T34的代码都是最新的,那我合并这两个然后推送到远程是什么效果?诶~,就是合并远程master和远程remote_T34!
但是!此时千万不能推送到远程,因为还没有高层的点头(代码Review)!
其实这个小节主要作用就是处理代码合并时的冲突,如果有冲突,全程大概也只有这个地方高发。合并完成后,就该提交代码Review了。
提交的代码Review通过之后,就可以推送代码到远程了。3.3.将做详细讲解。
执行arc diff提交代码Review,会弹出文本编辑器让你编写一些信息,其中最重要的”Reviewers”和”Subscribers”一定要认真填写。
保存关闭即可。
执行”arc list”查看Review状态,Git Bash对代码Review工具Arcanist的支持不是很完善,如果执行arc开头的命令提示信息不完全或者很怪异,可以更换使用命令行工具
上图的状态是还未审批通过,下图是审批通过
执行”arc land”命令,将代码推送到远程master分支
提示如上图说明推送成功。
命令”arc land”封装了包括”git push”等的许多Git命令,这样你就不用为没有执行”git push”命令的推送到远程感到怪异了。
做到这一步,说明你已经开发完了一个功能,终于可以松一口气了。
本章描述如何使用Eclipse的Git插件来替代命令行做代码管理,但代码因为Eclipse不能对Arcanist支持,所以代码Review依然使用命令行。
本章考虑到开发人员使用Eclipse作为IDE,而Eclipse也提供了对Git支持的插件,所以新开一节讨论这个插件的常用的用法。
将项目导入Eclipse,如果是Git管理的项目,会显示分支信息
如果新的开发任务已经创建好了远程分支,则跳到步骤3.2.3.否则创建一个新的开发分支:在项目上右键->Team->Switch To->New Branch…
弹出框里输入分支名,Finish
将项目推送到远程:右键项目->Team->Push Branch ‘someBranch’…
输入远程分支名,Next
直接Finish
此时,T35分支已经在跟踪远程remote_T35分支了,不信你可以在命令行看到
如果经过了这个步骤,如上面所说,该T35分支已经在跟踪远程remote_T35分支了,跳过下一步(即4.2.3.)。
如果在接到开发任务时,Eclipse已经有了这个项目,则先将代码更新到最新。
切换到master分支下,右键项目->Team->Pull
跟踪远程分支remote_T31,右键项目->Team->Switch To->Other…
选择Remote Tracking下的你需要跟踪的远程分支,Checkout
选择新建一个本地分支来跟踪
分支名改不改随意,Finish。切换到跟踪远程开发分支的本地分支
功能开发。
工程一旦修改,工程目录和被修改过的文件将出现一个”>”。
然后,Commit修改
弹出窗口编辑提交信息,直接Commit或者CommitAndPush
上一步如果选的是Commit,就需要Push了
直接确定Push
Push完成后本次提交完成。
切换到master分支
同样,合并前要保证合并双方都是最新代码,所以要在master分支pull一次,省略。然后直接合并
这次可以选择本地分支了,记得当前的分支么?当前的分支是本地master所以这里选择本地remote_T31分支,合并
如果出现冲突会提示
Eclipse里也会有提示,文件左边有个红色的,文件会如下图
修改后,将修改后的冲突文件Add To Index.
确保将所有冲突文件处理完后,重新CommitAndPush一次。此时本地master分支领先远程master分支3个修改,因为还没有推送到远程。同样推送之前要代码Review。
由于Eclipse没有对Arcanist做任何支持,所以如果想用Arcanist做代码Review,还是使用命令行吧。用法与3.3.无异,请看3.3.节。