我想使用本地 Android 存储库服务器在 Android 之上进行开发。我需要将几个新的 git 存储库添加到 git 的层次结构中，并且需要修改现有的 android 源代码以进行 Android 的定制。
克隆 git 存储库的整个 Android 源代码树的“正确”方法是什么，这样我就可以向公共本地存储库服务器推送/拉取，并且仍然可以轻松地从 Android 上游提取新的更改？
我特别寻求有关如何使用 repo 脚本与我自己的服务器交互，以及如何设置 manifest git 存储库和管理其中的分支的建议。
I want to develop on top of Android using a local Android repository server. I need to add several new git repositories to the hierarchy of gits, and I need to modify existing android sources for a custom tailoring of Android.
What is the "correct" way to clone the entire Android source tree of git repositories, such that I can push/pull to/from a common local repository server, and still easily pull new changes from Android upstream?
I am specifically looking for advice on how to use the repo script for interaction with my own server, and how to set up the manifest git repository and managing branches therein.
发布评论
评论（1）
在您的 git 服务器
因为你指定了 --mirror，所以创建的所有仓库都将是“裸”仓库，这是 git 正确的方式创建一个镜像，除非你是 git uberlord。
在您的客户端上：
repo init -u [电子邮件受保护]： platform/manifest.git # 您可以使用不同的方式访问您的 git 服务器；我必须对此示例进行一些假设。
尚未同步存储库。您的清单可能是错误的。查看符号链接的 .repo/manifest.xml...cat 它并在顶部阅读...它可能指向 android.googlesource.com。但如果它显示“..”，我认为这意味着“回到我的服务器”，因此您可以跳到步骤 6）。但如果它确实指向另一台服务器（不是您的），则转到步骤 3。
git commit; git push)，以便团队中的其他人在以下情况下获得“无清单编辑”体验：他们repo init;从您的服务器回购同步。一旦您看到“无清单编辑”
repo init; repo 同步工作，然后再次转到 default.xml，然后开始添加新的 XML 元素以及大量其他现有 Android 项目元素；这些新元素将指向您的自定义项目。对于这些新项目，只需像平常一样 git init 它们，并确保它们有一个与相同 匹配的分支，以便 repo 同步遇到这些新项目就会成功。如果您确实在清单 元素中设置了默认分支，那么只需让每个人都创建一个本地分支集以遵循在 revision 属性中指定的远程分支。因此，例如，如果 位于您的清单中，则在执行存储库同步后，当您 cd 到感兴趣的子项目时，执行以下操作：
git checkout -bbranch_a origin/branch_a然后，如果用户 git push（据我所知，没有要推送的 repo 命令），并且如果其他人在推送之后进行
./repo 同步，他们将从原始用户那里获取这些更改...只要您使用相同的清单并实际推送到由指定的默认修订版（分支）那个体现。这是最简单的食谱。如果您想创建实际的功能分支，那么如果您希望“存储库同步”正常工作，则必须更定期地编辑清单...并且您将必须与其他人沟通当您执行此操作时，团队会获取您的清单版本。或者，如果您只接触一两个 git 存储库，那么您可以像这些存储库上的正常操作一样放弃存储库同步和 git 推/拉，并在大量迭代时忽略安静树的其余部分。最终对我来说，这听起来像是一条更简单的道路。我会尽可能忽略 repo；仅将其用于“所有项目”同步，并在您专注于 1 或 2 个项目时将其保留。
关于从上游获取更新。我认为这样做的方法是更改 default.xml 以指向原来的 git 位置（如 android.googlesource.com），进行存储库同步以使所有新内容合并，并且一旦完成同步，提交回您的存储库。我还没有这样做；所以我不能太具体，但这就是我打算这样做的方式。
我忽略上面的服务器管理详细信息。例如，您需要在 git 服务器上的某个目录中调用 repo init ，使其成为可用的 git 存储库；我假设您知道如何管理 git 服务器。
On your git server
Because you specified --mirror, all repos created will be 'bare' repos, which is the git-correct way to create a mirror unless you are a git uberlord.
On your client:
repo init -u [email protected]:platform/manifest.git # you may use a different means of accessing your git server; I have to assume something for this example.
no repo sync yet. Your manifest is probably wrong. Look at the symbolic linked .repo/manifest.xml... cat it and read at the top the
<remote fetch=""... it probably points back to android.googlesource.com. but if it says '..' I think that means 'come back to my server', so you can skip to step 6). But if it does point back to another server (not yours), then go to step 3.<remote fetch="CHANGE ME"to point back to your git servergit commit; git push), so that others on the team will have 'no-manifest-edit' experience when theyrepo init; repo syncfrom your server.Once you see a 'no manifest edit'
repo init; repo syncwork, then go to your default.xml again, and just start adding new XML elements along with the tons of other existing Android project elements; these new elements will point to your custom projects. For these new projects, just git init them as you normally would, and make sure they have a branch matching the same<default revision="whatever_branch_you_see_here"so that arepo syncwill succeed when it encounters these new projects.If you do indeed set a default branch in your manifest
<default revision=""element, then just have everyone make a local branch set to follow the remote branch specified in the revision attribute. So, for example, if<default revision="branch_a"is in your manifest, after you do a repo sync, when you cd into a sub-project of interest, do a :git checkout -b branch_a origin/branch_aThen, if the user
git push's (there is no repo command to push, as far as I'm aware), and if someone else does a./repo syncafter that push, they will get those changes from the original user... as long as you are using the same manifest and actually pushing to the default revision (branch) specified by that manifest.That's the simplest recipe. If you want to make actual feature branches, then you'll have to edit your manifest more regularly if you want 'repo sync' to just work... and you will have to communicate to the rest of the team to grab your version of the manifest when you do that. Alternatively, if it's just one or two git repos you are touching, then you could just forego repo sync and git push/pull like normal on those repos and ignore the rest of the quiet tree for the times you are heavily iterating. This sounds, ultimately to me, like a simpler path. I'd ignore repo as much as you possibly can; only using it for 'all project' syncs and leaving it alone for the times you are focusing on 1 or 2 projects.
Regarding getting updates from upstream. I think the way to do that is to change your default.xml to point back to your original git location (like android.googlesource.com), do a repo sync to cause all the new stuff to merge in, and once done with the sync, commit back up to your repo. I haven't done this yet; so I can't be too specific, but this is how I plan to do it.
I'm ignoring server administration details above. For instance, you need to call the repo init in a certain directory on your git server to cause it to be an available git repository; I'm assuming you know how to administer your git server.