同一个svn仓库的不同git-svn克隆可以共享更改，然后git svn dcommit？

Question

我读过大量“从SVN到Git的”等“混帐svn的工作流程”在网络上的文章，仍然我认为他们经常处理过于简单的情况。他们通常针对那些只想在本地使用git和hack的人，而不使用git的全部功能，比如在多个开发人员之间进行pull，fetch，merge等操作，他们都会使用git-svn克隆svn仓库，然后仍然期望能够随时将他们的变化推送到（官方）svn仓库，并重新开始在git中工作并共享他们的东西等。

每当这些文章承认你不能做你所做的一切在纯粹的混帐中，后果和可能的混乱从未被清楚地解释过（或者也许只是我？）。即使是git-svn手册页也提到了警告，但并不是真正以广泛的方式。

基于我读过，我觉得当混帐SVN在特定的方式，我将在下面说明使用可能有问题。有人可以告诉我，如果我对此正确吗？

这里是“通缉令”的做事方式：

1. 我们有一个项目在SVN仓库
2. 开发一个git - svn的克隆的svn的回购。他开始在本地破解东西
3. 开发人员B git-svn-clone与svn相同。他开始自行破解事物。
4. 这样做了一段时间，可能增加开发者的C/d/...，并具有其他开发商谁做后的“标准” SVN提交到原来的回购，git的用户希望分享自己的代码和做各种的git魔术。
5. 那些混帐用户中的任何一个希望能够推动现已合并更改为SVN

我的问题是（dcommit）：我是在做梦？我前一段时间阅读过，在我认为的git书中，git-svn-clone可以创建git仓库，这当然是svn仓库的“镜像”，但不同开发人员创建的git仓库会有不同的“ ID“和提交会有不同的哈希值。所以我的理解是，那些git repos不会共享任何常见的git祖先，因此将无法使用所有需要共享，合并等的git命令。这是真的吗，我们会面对这个工作流程的问题吗？

有时我读过这个可以做到，至少使用一个“官方”裸git仓库，这将是唯一一个被git-svn克隆的，并且所有的git用户都必须从这个仓库开始。然后你需要一个负责这个中心git回购的人，并收集git开发者之间的变化，然后把所有的东西交给svn回购。这将是git用户“不知道”原始git repo来自svn并让他们使用所有git命令的唯一方法。唯一需要流利的git和svn（并了解git-svn警告）的人将是“合并经理”（或他所称的任何人）。

上午我完全误解的git - svn的注意事项？有没有更简单的方法来做到这一点？

Answer 1

的问题当然是第4步中找到。 dcommit会尝试将本地历史记录重播到服务器。 Dcommit假装你是SVN客户端。现在，如果您要提交的代码不仅来自您，那很难拒绝SVN。

下面介绍一下guru写就此事：

• 为了简单起见，用SVN互操作，这是 建议所有混帐SVN用户 克隆，获取和dcommit直接从 在git仓库和分支机构 之间的SVN服务器（远程SVN 仓库），并避免所有的 git-clone/pull/merge/push操作 ，这些都是通过git svn 克隆，并且还用于将更改集推回远程SVN 存储库。
• 在git分支 和用户之间交换代码的推荐方法是git format-patch和git am，或者只是将git svn dcommit添加到SVN 存储库。
• 由于混帐SVN dcommit混帐使用SVN变基内部，任何的Git分支，我们 混帐推到SVN dcommit混帐之前 他们将需要迫使现有裁判的覆盖 在远程 库。这通常是 被认为是不好的做法，详情请参阅 git-push文档。
• 运行git merge或git pull不建议在我们计划从 git svn dcommit的分支上进行。 SVN并非 表示以合理的方式合并或 有用的方式，因此使用SVN 的用户无法看到我们所做的任何合并。 此外，如果我们git合并或git 拉从一个SVT分支镜像的git分支，git svn dcommit可能会提交到错误的 分支。
• git clone不会在refs/remotes/hierarchy或git-svn元数据或配置下克隆分支或 。因此， 使用git-svn创建和管理的存储库使用 应该使用rsync 进行克隆，如果完全要完成克隆 。
• 我们不应该使用git commit的--amend选项来改变我们已经提交的 。这是 认为不好的做法 - 已宣布 提交我们已经推送到 远程存储库为其他用户，和 dcommit与SVN是类似的。 这个更多信息可在修改单个提交和 Problems with rewriting history找到 。

Answer 2

我用来做什么，是创建一个初始的git svn的克隆，然后共享他使用Git的developpers中git的，所以我们有完全相同的引用。

它似乎正确地工作，因为我们能够git的用户之间使用“特定混帐功能”，只要我们住在一个线性树（即基础重建，而不是合并）。

Answer 3

只要您进入“分布式”问题，您最好在开发人员中克隆一个纯粹的git回购。
关于公共SVN回购的进出口阶段，其他用途，脚本
git2svn and svn2git可以帮助封装魔术。

在Git和SVN回购工作时的其他注意事项的问题"Workflow and help with git, 2 svn projects and a single “workcopy”"

Answer 4

我发现this blog post是建议保持一个单独的分支与Subversion版本库同步，这样，它仍然将有可能做俯卧撑/中主分支拉。

Answer 5

我一直在尝试了很多与此最近，并认为我设法拿出多少有些工作的设置。是的，这是一个严格的仅基于rebase的制度，是的，它很复杂，但你确实可以在本地使用Git（速度，历史，存储，索引等）。

当你与你的团队，我认为其他的Git用户合作，但没有亲自尝试了太多本可以用树枝在幕后。只要你在提交之前将日志线性化就可以工作。

这里的短版本（重复了很多东西一直已经说过）：

1. 克隆颠覆回购成“取”回购中央服务器
2. 初始化在同一个“裸”回购上服务器
从fecthing回购
3. 推到裸回购
4. 有开发商克隆裸回购然后
5. git svn init svnurl到config URE git的 - svn的遥控器，和
6. git update-ref refs/remotes/git-svn refs/remotes/origin/master所以GIT-SVN有一个指针指向一个修订

自动（commit钩子）具有与 “获取” 回购SVN底垫，并推到裸回购

开发人员从裸露的回购仓库中提取git pull --rebase

运行git svn dcommit的开发人员首先必须重复上述update-ref以防SVN的新版本出现问题。

有一个illustration of the workflow on this page（我需要更多的声望点，才可以内联图像）。更新：在这里，我们去：

Answer 6

一个我用git-svn的感知的问题是，它存储在提交评论的混帐svn的-ID;因为这会重写那个提交，它会改变它的SHA1，所以你不能在任何人将它分享的地方推送它。

其实我更喜欢的bzr - svn的，因为它不是使用SVN版本属性功能，而不是这意味着没有本地修改重写存储在远程SVN修订BZR REVID。它还具有所需的属性，相同SVN分支的两个独立的pull将导致相同且可互操作的bzr分支。

Answer 7

有一个工具，它解决了共享与Subversion版本库的同步Git仓库的问题。

SubGit是一个Git-SVN双向服务器侧反射镜。

一个可以安装SubGit到Subversion版本库，让Git仓库使用SVN自动同步：

$ subgit configure $SVN_REPOS 
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options; 
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping 
$ subgit install $SVN_REPOS 
... 
$ INSTALLATION SUCCESSFUL 

SubGit安装预提交和post-commit钩子到Subversion版本库，预接收和后收到钩成Git存储库。因此它立即翻译来自SVN和Git端的传入修改。 SubGit安装后，开发人员可以使用任何Git客户端来克隆和使用Git存储库。

SubGit不依赖git-svn，它使用我们团队开发的自己的翻译引擎。有关这方面的更多详细信息，请参见SubGit vs. git-svn比较。有关SubGit的一般文档可用here。

SubGit的版本1.0需要本地访问Subversion存储库，即SVN和Git存储库必须驻留在同一主机上。但在2.0版本中，我们将介绍Git代理模式，当Subversion和Git存储库可以位于任何位置时，只有Git存储库安装SubGit，即Subversion存储库保持不变。

SubGit是一个商业产品。它对开源，学术项目以及多达10个提交者的项目都是免费的。

声明：我是SubGit开发人员之一。