Android系统多人协同开发-源码管理篇二

提示：Android 系统协同开发指导

---

前言

这里以Android 系统开发举例，来说明多人协同开发中的基本步骤、遇到的问题、使用到的工具。

    目的:提供一个思路，在多人协同开发中如何高效率进行开发工作。
使用到的工具：可以参考，实际每个人有自己的开发工具，当然部分工具需要付费。可视化工具也加快开发速度，提高开发效率。

一、参考资料

之前有两篇部分相关资料，编译、打包、git 相关基本知识点，实际开发中实际怎么用的简单描述。 可以提高开发效率，给开发者一个思路。

Android源码管理
AOSP编译打包脚本-项目源码管理经验

二、源码管理-提交代码

项目源码管理

    首先：要理解自己公司源码管理的方式和为什么这么管理，不同公司管理源码方式不一样。这里以目前公司源码管理方式说明，提供大家一个参考。
其次：源码里面涉及到两部分内容 驱动底层、Framework 层

当前源码管理方式核心点如下：

• 系统永远只有一个分支master
• 公版软件: 就是一套代码，master 分支，可以理解为公版代码。
• 分支代码：比如说有两百个项目case,两百个项目代码，那么每次切换项目代码时候，只需要把项目跟公版代码差异化的部分记录到分支项目目录中。那么切换代码的时候 用 copy 脚本把分支代码覆盖到公版代码即可。
  

所以，我们每次切换项目编译、开发中会有以下几个步骤：

• 切换项目：如上项目管理图，进入到对应项目, ./copy 脚本，复制分支项目代码到主分支公版代码。
• 客户修改- 同步代码到分支：根据客户，修改项目中的修改点，对源码进行修改。 编译固件，验证功能。如果OK，切记讲公版上面修改的代码同步到分支代码上面去。
• 提交分支代码： 这里有两部分工作，一部分分支上面的代码提交，另外一部分那就是公版软件代码提交。 那就是 git 命令操作了。

源码提交

这是一个看似简单，实际比较复杂的操作步骤。 也就是说 按照如上进行客户定制，修改了代码，最终是需要上传到服务器，实现多人熊开发的效果。

抛出问题：比如如下抛出这样一个问题： 分支上面的代码，copy 复制之后 全部在编译源码中，但是我又没有修改它，我不可能把分支复制替换的代码全部提交吧。 那需求就是：

• 只提交分支修改的代码、只提交源码中修改的代码。 对于源码被分支覆盖的代码modify 的但是又没有实际再次修改、对于编译生产的文件 都是是不允许提交的。
• 分支代码提交、源码公版修改的代码提交。 所有修改只能一次commit 。

比如如下：编译固件后的一个 git status 文件状态

举例-修改的分支文件的提交操作

如下：在分支上修改了代码-同时编译源码中也修改过的。 如下：比如修改了设置里面一个布局文件 security_dashboard_settings.xml

第一个需要提交的是 分支代码：里面需要新增的修改文件

基于以上，说明 需要提交的，剩下的都是不需要要提交的内容，那怎么处理？？？

步骤一：

• 理解：最终你编译固件，验证功能OK：这个时候才设计到代码同步到服务器。 你可能先修改的编译源码里面的文件再同步到分支代码里面去；你可能直接在分支代码里面修改，再配置copy.sh 复制脚本后再复制同步到编译源码里面去进行编码。 但是最终 要么 同步部分公版代码要么同步分支代码。 这里只需要同步分支代码即可.

git add 分支代码：git add

tit add project/t_project/dm3602/dm3602_jd9366tc_800x1280_new

查看gitk ,Local changes checked in to index but not committed

not commit ：Local uncommitted changes,not checked in to index

部分大量的文件，modify 过，但是不是需要提交的，如下Local uncommitted changes,not checked in to index

git commit 提交代码

在源码文件中，git commit 提交部分代码到git 仓库

git pull 拉去同步远端代码到本地

可能有部分代码合并，如下：

git commit

提交操作 ，然后查看git log 信息记录

git push 同步到服务器

三、知识点扩展

gitk 中 Local changes checked in to index but not committed 和 Local uncommitted changes,not checked in to index 区别

为什么要搞清楚这个问题，如上问题分析：modify 的文件蛮多的，为什么 git add 需要提交的代码就可以了，然后commit ，其它不需要处理的。
再次看一下 gitk 里面常见的图：

简单来说，这两者的核心区别在于你的更改是否被 git add 命令暂存。前者是已暂存的，后者是未暂存的。
为了帮你更直观地理解，下面这个表格清晰地对比了它们的核心区别：

对比维度	Local changes checked in to index but not committed	Local uncommitted changes, not checked in to index
中文理解	已暂存但未提交的更改	未暂存的更改
在Git中的区域	索引（Index） 或 暂存区（Staging Area）	工作目录（Working Directory） 或 工作区（Workspace）
如何产生	对已跟踪的文件修改后，执行 git add	对已跟踪的文件修改后，没有执行 git add
对应的Git命令 git add 修改文件后，直接保存
如何查看详情 git diff --cached 或 git diff --staged	git diff
提交时的影响	执行 git commit 时，这些更改会被提交到版本库	执行 git commit 时，这些更改不会被提交

如何管理这两种状态

# 1. 将"未暂存的更改"变为"已暂存的更改"
git add <文件名>

# 2. 将"已暂存的更改"重新变回"未暂存的更改"（取消暂存）
git reset HEAD <文件名>

# 3. 直接丢弃"未暂存的更改"（危险操作，无法撤销）
git checkout -- <文件名>

所以，可以这么讲：在 add 命令后，直接git checkout 清除掉未缓存到工作区的 -> git commit 提交操作 -> git pull 拉去最新代码 -> git push 同步代码到最新服务器。

一个查看状态的技巧

在命令行中，使用 git status 可以非常直观地看到这两种状态：

• 在 Changes to be committed: 下面并以绿色显示的，就是"已暂存但未提交的更改"。

• 在 Changes not staged for commit 下面并以红色显示的，就是"未暂存的更改"。

总结

• 这里实际就是一次 系统开发中的实战演示
• 实际开发中实际操作才能领悟其中各种命令的意义，方便提升整体开发效率