我已将svn存储库迁移到本地开发人员计算机上的git存储库。所以master正在跟踪svn trunk。我希望svn trunk
成为git中的develop
分支,我通过在git中重命名分支来完成。
我通过发出git svn fetch
和git svn rebase
来继续将svn trunk中所做的更改同步到git。这工作得很好。
svn repo中的文件夹结构,因此在git repo中的文件夹结构如下所示
s-online/
├── .git
└── Online
├── config
│ ├── build
│ ├── dataload
│ ├── export
│ ├── http
│ ├── search
│ ├── web
│ └── webservice
└── workspace
├── data
├── logic
├── site
├── stores
└── tools
我想修改git repo中的文件夹结构,如下所示。因此,基本上,将工作区内的所有内容移动到Online文件夹下。
s-online/
├── .git
└── data
├── logic
├── site
├── stores
└── tools
├── config
├── build
├── dataload
├── export
├── http
├── search
├── web
└── webservice
一些开发人员希望从今天开始使用git进行新开发,而其他仍然致力于svn的开发人员需要一段时间才能完全转换为git。
在此之前,挑战是能够将提交从svn trunk同步到我的git repo(已修改的文件夹结构)一段时间。
当我执行git svn fetch
后跟git svn rebase
时,rebase需要一段时间(可以理解,因为我对文件夹结构的更改需要应用于svn提交之上)。但是,对于所有提交给svn的文件(因为git中的文件夹重构),我在rebase期间会遇到所有这些文件的冲突。
我不确定为什么首先提交给svn的所有文件都存在冲突,因为我所做的只是重新组织git中的文件夹结构?
我有什么遗失的吗?
答案 0 :(得分:0)
可能还有其他东西缺失,但通常只要您对svn有活动提交,就应该保持结构和文件同步。最好还是限制git端的合并提交,因为它们可能会使git svn rebase
复杂化,除非你预先压缩这些合并。