关于使用git-svn repo的团队的工作流程的问题

Question

我正在阅读git和git-svn。我对git很新，但我已经能够创建一些基本的回购。但是，我对团队使用git-svn的工作流程有点困惑。目标是将svn转换为git以进行分支和共享，然后在准备推送到生产时返回主svn repo。以下是我的问题：

团队中的每个成员是否应该从svn repo创建一个git repo？这种方法在合并回到svn / pull时会起作用吗？

-OR -

如果从svn创建一个git repo，那么该repo会被“公开”推送给团队成员进行克隆吗？那么更改是否会被拉回原来的git repo进行变基并推送到svn？

-OR -

我们可以像上面那样做，只是从彼此的工作副本仓库中取出更改吗？

-OR -

我是否在工作流程中添加了太多复杂性，应该继续使用svn，因为它不能完全转换为git？

Answer 1

开发人员是否需要本地仓库，而无法连接到主仓库？ （即：在笔记本电脑上的飞机上编码）

如果不是，那么我会完全避免这种头痛，只使用SVN和特定于dev的分支。

但是，如果您真的喜欢git的分布式方法，我会选择第三种选择：

  

是否应该创建一个git repo   svn，那个回购被推了   '公开'让团队成员克隆？   然后将更改撤回   最初的git repo用于变基和   推到svn？

使用：

  

我们可以像上面那样做   只是拉彼此的变化   工作副本回购？

这应该可以正常工作。

Answer 2

我总是沿着这些方向做点什么。在这里，我们有一个svn存储库，但有些人宁愿使用git。我们只有一个人创建了git存储库，然后我们都在自己之间共享（而不是每个人创建自己的git-svn副本 - 原始导入花了30多个小时）。现在任何想要的人都可以使用git和git svn dcommit将他们的更改推回到“真正的”svn存储库。

Answer 3

将每个用户的git存储库视为一个花哨的Subversion客户端，特别是在不涉及中央存储库的情况下很容易共享修订版的客户端。然后每个人都应该做对他们最好的事情。

您还可以将Subversion存储库视为一个奇特的git存储库。

  

如果从svn创建一个git repo，那么该repo会被“公开”推送给团队成员进行克隆吗？那么更改是否会被拉回原来的git repo进行变基并推送到svn？

我认为这不是必要的，因为git svn clone与git clone的工作方式大致相同。

最重要的事情是在执行git svn rebase之前始终执行git svn dcommit。如果您在git存储库之间进行了大量的修订共享，那么在执行git svn dcommit之前检查您将要推送到Subversion的更改可能是个好主意。

Answer 4

Git-svn轻松支持您想要做的事情。我建议每个开发人员从Subversion存储库（git svn clone）创建自己的Git存储库。如果他们愿意，开发人员可以互相拉扯，包括已经推送到Subversion的提交和没有推送到Subversion的提交。

svn update的git-svn等价物是git svn rebase，它有效地对Subversion存储库执行git rebase操作。

，会自动跳过任何已经准备提交的提交，这些提交已经由其他人提交。