6

我们有 2-3 个 2-3 人的小团队。我们都将 git 用于本地，将 svn 用于中央存储库，并且 git-svn 得到了同步。这一直有效，除非我们想在自己的团队之间共享我们的代码。

所以我们尝试了 git pull，这会产生很多冲突，并且它不会检测到我们在同一棵树上。它获取所有更改（与克隆然后拉取相同）当然我不想克隆完整的仓库。每次都想分享。

请提出更好的流程。

  1. 我们无法摆脱中央 svn。
  2. 我们不能每次都克隆。
4

3 回答 3

3

指定一名团队成员作为“git hub”，他/她与 SVN 服务器同步，其他团队成员与他们交互，而不是直接与 SVN 服务器交互。这样 git 就会知道所有团队成员都在同一棵树上。

于 2011-01-10T09:42:07.153 回答
3

SubGit对您来说似乎是一个不错的选择。

SubGit是服务器端解决方案，它允许 Git 访问 Subversion 存储库，反之亦然。这意味着您只能使用您选择的 Git 客户端来处理 Git 存储库。

您需要将 SubGit 安装到您的 Subversion 存储库中一次。之后，SubGit 立即将 svn revision 转换为 git commit on every svn commit，并将 git commit 转换为 svn revision on every git push。

SubGit 是闭源软件，但对开源项目是免费的。有关更多信息，请参阅SubGit 文档。

于 2011-12-09T04:05:03.093 回答
2

要添加到 Chris Huang-Leaver 的答案，您需要一个中心点来使用 svn repo 进行 dcommit/rebase。
这并不否认 Git 的“去中心化”方面，它只是允许每个人使用作为他们的远程存储库之一的一个“中央”参考存储库（即与 svn 同步的一个）

没有简单的方法可以避免克隆来自（可能很大的）svn repo 的所有内容的负担，因为生成的Git repo 不能拆分为 submodules。
这至少留下一个“解决方案”，其中包括：

  • 在主要的 Git 旁边创建不同的 Git（与 SVN 同步）
  • 从主仓库导出补丁
  • 将这些补丁应用于代表主 Git 存储库中的项目的每个 Git 存储库。

它显然需要自动化，但一个团队将专注于其中一个git 存储库作为其“中央”存储库，负责 SVN 同步的人员将使用来自主（和隐藏）Git 的补丁更新那些较小的 Git 存储库<=>SVN 回购。

于 2011-01-10T11:49:34.773 回答