git svn网守存储库

我已经使用git很长时间了，主要是git svn。现在我想说服我的同事们从svn切换到git。但不幸的是，前提条件是svn存储库持续存在相当长的一段时间。因此，我寻找了一个解决方案，并提出了这本书：

C:\tmp\devs\adm\websites>git checkout svn/trunk
Note: checking out 'svn/trunk'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at e53fba9... [maven-release-plugin] prepare release kaksi

C:\tmp\devs\adm\websites>git merge --no-ff remotes/bare_repo/svn/trunk
Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 web/howto.txt
 create mode 100644 web/readme.txt

C:\tmp\devs\adm\websites>git svn dcommit
Committing to http://localhost/svn-repos/company-repo/websites/trunk ...
        A       web/howto.txt
        A       web/readme.txt
Committed r8
        A       web/readme.txt
        A       web/howto.txt
r8 = 28da267255ae56022bd4ed3c0f4886da1ac04944 (refs/remotes/svn/trunk)
No changes between current HEAD and refs/remotes/svn/trunk
Resetting to the latest refs/remotes/svn/trunk

Jon Loeliger的“Git版本控制”。我买了它，它真的很好，但我不完全理解建立git svn守门人回购的指南

在第16章中，他描述了 发生冲突的情况 Subversion存储库，以及至少一个 两个想要使用的用户 吉特。他提出了一个单独的建议 “网守”git存储库 subversion的唯一接口。 git svn克隆颠覆后 回购（带--prefix=svn/），所有 然后把树枝推到一个光秃秃的地方 存储库（git push../svn-bare.git “refs/remotes/svn/：refs/heads/svn/”， 其他git用户被告知要克隆 该回购协议现在包含本地 所有svn遥控器的分支

这部分有效，我想我完全理解。但我不明白下一部分：

如果克隆裸存储库的开发人员将更改从其repo推回到裸存储库，然后我在裸存储库中将其提交给svn，那么用户推送的提交将丢失，原因很充分，因为git svn创建了替换的提交。或者我错了吗？这是如何工作的

书上说

然后，要合并回subversion，在 守门人回购协议，你知道吗

git签出svn/trunk（或其他 分支-这是签出一个 分离的头部，因为svn/躯干是一个 （远程） git合并--没有新功能 git svn数据委员会

如何在一个空的存储库中签出一个分支？我认为这不管用

这将导致在服务器上进行合并提交 拆下头部，然后修改 提交（在git svn id行之后） 添加）放在真正的svn/主干上 分支机构

什么是真正的svn/trunk

已分离服务器上的提交 head“比冗余更糟糕。使用 它最终会为其他任何事情而改变 结果是冲突。所以，忘了吧 关于那个承诺，如果你没有 它首先在一根树枝上， 这更容易忘记”（乔恩） 洛伊利格）

我有点困惑。有人对创建git svn gatekeeper回购有更好的解释吗？我搜索了网站和这个网站，但没有找到任何适合我的

---

在与同事合作时，我已经厌倦了在svn分支和合并上浪费这么多时间。

我认为您不应该将更改推回到原始回购。我这里有一个示例设置，您可以尝试：

在我的设置中（我已经使用了3-4个月，没有任何问题），更改应该总是“流动”到SVN存储库中。我不太理解这种把关技术

如何在裸存储库中签出分支？我认为这不起作用

是的，它是这样做的：您只需在本地克隆分支，在此过程中进行非裸回购，您可以签出/创建（再次在本地）任意数量的分支

需要裸回购协议作为上游回购协议（见“”）

但为了将任何内容推送到它，即其他开发人员将其在非svn分支中的更改推送回gatekeeper repo，他说其他开发人员必须首先克隆该裸repo，对本地副本进行所有相关修改，然后推送回裸repo。
另外，为了验证推送，您可以在裸回购上设置一些钩子：请参见“”

然后，到

dcommit

，网守还将克隆该网守repo，他/她将从中：

• 签出与svn相关的远程分支（“

  svn

  ”是远程回购的名称），例如“

  svn/trunk

  ”
• 合并该未命名分支中的相关更改

• git svn dcommit

因此，总结一下：

• 开发人员克隆该网守repo以在其自己的分支中记录其更改（他们可以将其推后，因为网守repo是裸的）
• 负责推回实际SVN repo的人员还克隆了该网守repo，以便选择需要合并到专门绑定到SVN的Git分支的内容（例如，请参见“”）

---

我曾尝试自动化Jon Loeliger所描述的程序，并使其正常工作。他开始时非常详细地说明了要执行的步骤，但“合并回Subversion”部分相当简短。我曾尝试使用git svn进行不同的设置，也遵循了Thomas Ferris Nicolaisen提供的优秀设置，并使用了他的示例项目（经过修改）用于测试“网守设置”：

@echo 1. Clone Subversion repo
cd %WDIR%\devs\adm
call git svn clone -s --prefix=svn/ http://localhost/svn-repos/company-repo/websites --    username adm
cd %WDIR%\devs\adm\websites
call git reset --hard svn/trunk

@echo ----------------------------------
@echo  2. Create bare repo
cd %WDIR%\devs\adm
mkdir websites.git
cd websites.git
call git init --bare 

@echo ----------------------------------
@echo  3. Populate bare with content from gatekeeper 
cd %WDIR%\devs\adm\websites
call git push --all ../websites.git
call git push ../websites.git "refs/remotes/svn/*:refs/heads/svn/*"

@echo ----------------------------------
@echo  4. Setup bare as a remote in gatekeeper and fetch branches 
call git remote add bare_repo ../websites.git
call git fetch bare_repo

Jon Loeliger没有描述第4步，但我猜他就是这么想的

当需要合并回subversion时，请执行以下操作：

C:\tmp\devs\adm\websites>git fetch bare_repo
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ../websites
   e53fba9..2ac281c  svn/trunk  -> bare_repo/svn/trunk

现在我们可以按照书中的步骤进行操作：

C:\tmp\devs\adm\websites>git checkout svn/trunk
Note: checking out 'svn/trunk'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at e53fba9... [maven-release-plugin] prepare release kaksi

C:\tmp\devs\adm\websites>git merge --no-ff remotes/bare_repo/svn/trunk
Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 web/howto.txt
 create mode 100644 web/readme.txt

C:\tmp\devs\adm\websites>git svn dcommit
Committing to http://localhost/svn-repos/company-repo/websites/trunk ...
        A       web/howto.txt
        A       web/readme.txt
Committed r8
        A       web/readme.txt
        A       web/howto.txt
r8 = 28da267255ae56022bd4ed3c0f4886da1ac04944 (refs/remotes/svn/trunk)
No changes between current HEAD and refs/remotes/svn/trunk
Resetting to the latest refs/remotes/svn/trunk

我对这种设置的问题（在本书前面已经警告过我们）是历史被压扁了：

C:\tmp\devs\adm\svn\websites>svn log
------------------------------------------------------------------------
r8 | adm | 2012-05-12 23:21:11 +0200 (lø, 12 mai 2012) | 1 line

Merge remote-tracking branch 'remotes/bare_repo/svn/trunk' into HEAD
------------------------------------------------------------------------

现在考虑将此选项合并回颠覆：

C:\tmp\devs\adm\websites>git checkout -t svn/trunk
Branch trunk set up to track local ref refs/remotes/svn/trunk.
Switched to a new branch 'trunk'

C:\tmp\devs\adm\websites>git fetch bare_repo
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ../websites
   c188a72..b1b4237  svn/trunk  -> bare_repo/svn/trunk

C:\tmp\devs\adm\websites>git rebase remotes/bare_repo/svn/trunk
First, rewinding head to replay your work on top of it...
Fast-forwarded trunk to remotes/bare_repo/svn/trunk.

C:\tmp\devs\adm\websites>git svn reset 2147483647
r7 = c188a72da6df2966e563e9e575b626d5b449400f (refs/remotes/svn/trunk)

C:\tmp\devs\adm\websites>git svn rebase
Current branch trunk is up to date.

C:\tmp\devs\adm\websites>git svn dcommit
Committing to http://localhost/svn-repos/company-repo/websites/trunk ...
        A       web/howto.txt
        A       web/readme.txt
Committed r8
        A       web/readme.txt
        A       web/howto.txt
r8 = 18b7c7b4693cc8e55098bd716c9259ed5570acf0 (refs/remotes/svn/trunk)
No changes between current HEAD and refs/remotes/svn/trunk
Resetting to the latest refs/remotes/svn/trunk

现在，提交历史记录完好无损：

C:\tmp\devs\adm\svn\websites>svn log
------------------------------------------------------------------------
r8 | adm | 2012-05-12 23:51:48 +0200 (lø, 12 mai 2012) | 1 line

'ola added [readme.txt, howto.txt] on svn/trunk'

为了使此设置生效，我们需要使用“git svn reset”命令，否则dcommit将第二次失败，因为git svn对当前版本感到困惑，并且落后于（与我们创建裸回购时的版本相同）。这可能是因为我们使用了rebase，这反过来又是在subversion中获得良好线性历史所必需的

最大的问题是：“git svn reset”真正做什么？

---

是“正向重置”在这种情况下合法使用“git svn reset”？

那么你就有了

开发者把关人git repo svn

？如果是这样，我不理解它的优势。这比只使用

git svn

好吗？在svn消失之前，你看不出你真的可以利用git的分支/合并。@dgnoton一个优势我那是什么