使用 git 和 git-svn 进行分散式开发
我们有2-3个2-3人的小团队。我们都使用 git 进行本地存储，使用 svn 进行中央存储库，并且 git-svn 进行同步。这一直有效，除非我们想在团队之间共享代码。
所以我们尝试了 git pull，这会产生很多冲突，并且它不会检测到我们在同一棵树上。它获取所有更改（与克隆然后拉取相同） 当然我不想克隆完整的仓库。每次我想分享。
请建议更好的流程。
- 我们无法摆脱中央 svn。
- 我们不能每次都克隆。
We have 2-3 small teams of 2-3 people. We all use git for local and svn for central repository and git-svn got sync. This is works all the time except when we want to share our code between the team it self.
So we have tried out git pull, this creates lots of conflicts and it does not detect that we are on the same tree. It fetches all the changes (same as clone then pull)
Of course i dont want to clone full repo. every time I want to share.
Please suggest a better flow.
- We can't get rid of central svn.
- We can't clone every time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
指定一名团队成员作为“git hub”，他/她与 SVN 服务器同步，其他团队成员与他们交互，而不是直接与 SVN 服务器交互。这样 git 就会知道所有团队成员都在同一棵树上。
Nominate one team member as the 'git hub', he/she syncs with the SVN server, other team members interact with them, rather than the SVN server directly. That way git will know that all team members are on the same tree.
SubGit 似乎是您的一个不错的选择。
SubGit 是服务器端解决方案，它允许 Git 访问 Subversion 存储库，反之亦然。这意味着您只能使用您选择的 Git 客户端来处理 Git 存储库。
您需要将 SubGit 安装到您的 Subversion 存储库中一次。之后，SubGit 立即将每次 svn commit 上的 svn revision 转换为 git commit，并在每次 git Push 上将 git commit 转换为 svn revision。
SubGit 是闭源软件，但对于开源项目来说是免费的。有关更多信息，请参阅 SubGit 文档。
SubGit seems like a great alternative for you.
SubGit is server-side solution, it enables Git access to Subversion repository and vice versa. That means you can work with Git repository only, using Git client of your choice.
You need to install SubGit into your Subversion repository once. After that SubGit immediately translates svn revision into git commit on every
svn commitand git commit into svn revision on everygit push.SubGit is closed-source software but it is free for open-source projects. For more information please refer to SubGit documenation.
要添加 Chris Huang-Leaver 的答案，您需要一个中心点来使用 svn 存储库进行 dcommit/rebase。
这并不否认 Git 的“去中心化”方面，它只是允许每个人使用一个“中央”参考存储库（即与 svn 同步的存储库）作为其远程存储库之一，
没有简单的方法可以避免克隆来自（可能巨大的）svn 存储库的所有内容的负担，因为生成的Git 存储库无法拆分为子模块。
这至少留下了一个“解决方案”，其中涉及：
显然需要自动化，但一个团队将专注于其中一个 git 存储库作为其“中心”存储库，而负责 SVN 同步的人员将使用来自以下位置的补丁来更新这些较小的 Git 存储库：主要（和隐藏）Git<=>SVN 存储库。
To add to Chris Huang-Leaver's answer, you need a central point to dcommit/rebase with the svn repo.
That doesn't deny the "decentralized" aspect of Git, it simply allows everyone to work with, as one of their remote repositories, one "central" repo of reference (i.e. the one sync with svn)
There is no easy way to avoid the burden to clone everything coming from the (potentially huge) svn repo, because the resulting Git repo cannot be split into submodules.
That leaves at least one "solution", which would involve:
It obviously needs to be automated, but one team would focus on one of those git repos as its "central" repo, and the person in charge of SVN synchronization would update those smaller Git repos with patches coming from the main (and hidden) Git<=>SVN repo.