A公司正在開發軟件,並用自己的SVN同步2個不同的倉庫
B公司也希望在相同的軟件工作,但他們只知道如何使用GIT
B公司不希望使用公司A的存儲庫
公司B能否擁有公司A SVN的同步副本 - 但是在GIT中,他們也可以使用它?
基本上,而不是將它們共享1個庫,將有2個同步信息庫
一個在SVN提交代碼,其他看到它在GIT [反之亦然]
A公司正在開發軟件,並用自己的SVN同步2個不同的倉庫
B公司也希望在相同的軟件工作,但他們只知道如何使用GIT
B公司不希望使用公司A的存儲庫
公司B能否擁有公司A SVN的同步副本 - 但是在GIT中,他們也可以使用它?
基本上,而不是將它們共享1個庫,將有2個同步信息庫
一個在SVN提交代碼,其他看到它在GIT [反之亦然]
GitHub has some support for accessing repositories with both Git and Subversion。雖然我沒有親自嘗試過,但可能是您要找的東西,只要A公司願意切換到GitHub。
或者,我想你可以使用git-svn(tutorial)讓B的git
與公司A的svn倉庫(的副本)交談。 Git-svn完成與您所描述的最接近的工作 - 它以git
的期望格式創建Subversion存儲庫的副本,這意味着所有常規的git
命令都可以使用它。
雖然這不是一個完美的解決方案。下面是the git book不得不說一下:如果你堅持一個Subversion服務器現在或者以其他方式在必要運行的Subversion服務器開發環境
的混帳svn的工具是有用的。然而,你應該認爲它會使Git癱瘓,否則你會在翻譯中遇到可能會讓你和你的合作者感到困惑的問題。爲了避免麻煩,試着遵循以下原則:
保持一個線性提交歷史不含合併提交內容git的合併作出。將您在主線分支之外完成的任何工作重新放回原處;請勿合併。
請勿在單獨的Git服務器上進行設置和協作。可能有一個加速新開發人員的克隆,但不要推送任何沒有git-svn-id條目的東西。你甚至可能想要添加一個預接收鉤子來檢查每個提交消息的git-svn-id,並拒絕包含提交消息的推送。
如果遵循這些指導原則,使用Subversion服務器可以更容易。但是,如果可以轉移到真正的Git服務器上,那麼這樣做可以讓您的團隊獲得更多。
最後,你可以看看this answer,這表明使用商業SubGit工具的用例看起來與你的相反。我也沒有使用SubGit的經驗,但它作爲git-svn的一個更好的替代品銷售,可能值得一試。
真的,從兩個不同的供應鏈管理系統在同一個代碼庫工作在同一時間不同的公司兩個不同的球隊 - 這是你彷彿是想爲 - 聽起來像一個災難即將發生。從你的問題,我不知道你的情況,知道哪個會更好,但我相信你可以嘗試要麼...
無論如何,祝你好運!
這聽起來很可怕。 –