同一个svn存储库的不同git-svn克隆是否可以分享更改然后git svn dcommit?

Ced*_*uin 33 svn git git-svn code-sharing

我在网上看过很多"从svn转到git"和其他"git-svn工作流程"的文章,但我认为它们经常处理过于简单的情况.它们通常针对那些只想在本地使用git和hack的人,而不是使用git的全部功能,比如在多个开发人员之间使用git-svn克隆svn存储库时的pull,fetch,merge等,然后仍然希望能够随时将他们的更改推送到(官方)svn存储库,然后回到git工作并分享他们的东西等.

每当这些文章承认你不能做你在纯git中所做的一切时,后果和可能的搞砸都没有明确解释(或者也许只是我?).即使是git-svn手册页也提到了警告,但并没有真正广泛地提及.

基于我所读到的内容,我觉得当git-svn以特定方式使用时可能会出现问题,我将在下面介绍.有人可以告诉我,我是对的吗?

这是"通缉"的做事方式:

  1. 我们在svn存储库中有一个项目
  2. 开发人员一个git-svn-clone是svn repo.他开始在当地破解东西
  3. 开发人员B git-svn-clone与svn repo相同.他开始自己破解东西.
  4. 在做了一段时间后,可能添加开发者C/D/...,并让其他开发人员做"标准"svn提交到原始回购,git用户想要分享他们的代码并做各种git魔术.
  5. 这些git用户中的任何一个都希望能够将现在合并的更改推送到svn(dcommit?)

我的问题是:我在做梦吗?我前段时间读过一本git书,我认为,git-svn-clone可以创建git存储库,当然它们是svn repo的"镜像",但是不同开发人员以这种方式创建的git存储库会有所不同" ids"和提交将有不同的哈希.所以我的理解是那些git repos不会共享任何常见的git祖先,因此无法使用共享,合并等所需的所有git命令.这是真的,我们是否会面临这个工作流程的问题?

有时我读到这可以完成,至少使用一个"官方"裸git存储库,这将是唯一一个git-svn-cloned,并且所有git用户都必须从这个开始.然后你需要一个负责这个中央git仓库的人,并在将所有东西都提交给svn repo之前收集git devs之间的变化.这将是git用户"不知道"原始git repo来自svn的唯一方法,并允许他们使用所有git命令.唯一需要精通git和svn(并且了解git-svn警告)的人将是"合并经理"(或者他称之为的任何人).

我完全误解了git-svn警告吗?有没有更简单的方法呢?

Tho*_*sen 23

我最近一直在尝试这个,并且认为我设法提出了一些有点工作的设置.是的,这是一个严格的仅限rebase政权,是的,它很复杂,但你确实可以使用Git在本地工作(速度,历史,藏匿,索引等).

当您与团队中的其他Git用户进行协作时,您可以在幕后使用分支机构,但我没有对此进行过多的个人实验.只要你在提交之前线性化日志它应该工作.

这是短版本(重复了很多已经说过的内容):

  1. 将Subversion repo克隆到中央服务器上的"获取"仓库中
  2. 在同一台服务器上启动"裸"仓库
  3. 从fecthing repo推送到裸仓库
  4. 让开发人员克隆裸仓库然后
    1. git svn init svnurl 配置git-svn远程,和
    2. git update-ref refs/remotes/git-svn refs/remotes/origin/master 所以git-svn有一个指向修订版的指针
  5. 自动(提交挂钩)具有"获取"repo svn rebase,并推送到裸仓库
  6. 开发人员从裸仓库中撤出 git pull --rebase
  7. git svn dcommit首先运行的开发人员必须update-ref在SVN进行更新修订的情况下重复上述操作.

这个页面上的工作流程有一个例子(在我可以内联图像之前,我需要更多的声誉点).更新:我们走了:

  • 这个答案中的**关键点**是步骤“6”:“git update-ref refs/remotes/git-svn refs/remotes/origin/master”。这使得开发人员可以将他们的克隆链接到 svn。这就是允许共享 `origin/master` 的原因,并且*同时*使用它来推送到 svn。如果没有步骤“6”,开发人员将不得不在“origin/master”和“git-svn”分支之间跳转。获取存储库和提交挂钩并不是绝对必要的:开发人员可以在“dcommit”到 svn 之后立即推送到裸存储库的“master”。 (2认同)

nes*_*983 19

问题当然是第4步.dcommit尝试将您的本地历史记录重播到服务器.Dcommit假装您是SVN客户端.现在,如果您提交的代码不仅仅来自您,那么很难向SVN提出这些代码.

这是大师在这件事所写的内容:

  • 为了简单和与SVN互操作,建议所有git-svn用户直接从SVN服务器(远程SVN存储库)克隆,获取和dcommit,并避免所有git-clone/pull/merge/push git存储库和分支之间的操作,这些操作通过git svn clone检索,也用于将更改集推送到远程SVN存储库.
  • 在git分支和用户之间交换代码的推荐方法是git format-patch和git am,或者只是git svn dcommit到SVN存储库.
  • 由于git svn dcommit在内部使用git svn rebase,我们git推送到git svn之前的任何git分支都需要强制覆盖远程存储库上的现有ref.这通常被认为是不好的做法,请参阅git-push文档了解详细信息.
  • 不推荐在我们计划从git svn dcommit的分支上运行git merge或git pull.SVN不以任何合理或有用的方式表示合并,因此使用SVN的用户无法看到我们所做的任何合并.此外,如果我们从作为SVN分支的镜像的git分支git merge或git pull,git svn dcommit可能会提交到错误的分支.
  • git clone不会在refs/remotes/hierarchy或任何git-svn元数据或config下克隆分支.因此,使用git-svn创建和管理的存储库应该使用rsync 进行克隆,如果要进行克隆的话.
  • 我们不应该对我们已经提交的更改使用git commit的--amend选项.我们已经将其提交到远程存储库以供其他用户使用的提交被认为是不好的做法,并且与SVN的命令类似于此.有关此内容的更多信息,请参阅修改单个提交和 重写历史记录问题.

  • "没有合并/拉动,差异和补丁"..--但仅限于:"我们计划从一个分支机构git svn dcommit".这意味着,是的你*可以*去git merge/pull/cherrypick并获得力量/魔力; 你只需要在另一个分支上解决你的变化; 在你把它推入svn之前.这不是太难,改变或合并 - 应该在那里做. (3认同)