问题描述
在Windows上，我们有 root \folder1 ， root \folder2 ， root \folder3 。
在Linux上，我们有 root / folder1 / folder2 ， root / folder1 / folder3
我强烈希望不要使用子模块和子树。
是否有另一种解决方案？它会工作创建一个分支并重新安排文件到Linux结构？并将合并分支之间的意义？
编辑
我已经做了更多的阅读，尤其是关于分支工作流程。我现在正在重新考虑NOT子模块声明。我担心包含子模块的日常开发人员存储库以及似乎需要解决的复杂问题。但是，我认为开发人员不需要子模块，他们可以满足嵌入式存储库的需求。
说文件夹1 ，文件夹2 和 folder3 是独立的git存储库 - repo 1 ，回购2 和回购3 。在Windows上，3个存储库是分开的。在Linux上，文件夹1 是回购1 ， folder1 / folder 2 等。
/ code>并且在文件夹2 中存在更改，将 （注意：您也可以在Windows 7上使用，另请参见），这将是一个部署问题：即：您将拥有：
- 您的常规本地副本
- 该副本具有正确的结构
- 一种方法来区分/导入在该副本中进行的任何修改进入常规的git仓库
...所以，保持共同的目录结构仍然是最简单的解决方案。 p>
不，它只会考虑文件夹1 的任何部分的换行符，除了 文件夹2 内容外。
完全符合。
是，将涉及2个回购：一个适用于Windows，Linux适用于Linux。
每个人都可以使用正确的结构来聚合子树回购。
On Windows we have root\folder1, root\folder2, root\folder3.On Linux we have root/folder1/folder2, root/folder1/folder3
I would strongly prefer NOT to use submodules nor subtreees.
Is there another solution? Would it work to create a branch and re-arrange the files to the Linux structure? And would merges between the branches make sense?
Edit
I have done much more reading, especially about branch work flows. I'm now re-considering the NOT submodules statement. I was concerned with having the day-to-day developer repository containing submodules and the complications that seems to entail. But, I think that the developers do not need submodules, they can meet the need with embedded repositories.
Say folder 1, folder 2 and folder3 are separate git repositories - repo 1, repo 2 and repo 3. On Windows the 3 repositories are separate. On Linux, folder 1 is repo 1, folder1/folder 2 is repo 2, etc.
If I'm in folder 1 and there are changes in folder 2, will a git add . not include the folder2 change? Does git stop when it sees another .git?
There could be 2 separate bare repositories for building which includes the 3 repos as submodules in the appropriate configuration for Windows and Linux. The release branches can then be managed here. But what branching is seen in repo 1, 2 and 3? Has anyone tried something like this? Did it work well?
Beside the symlinks mentioned by mvp (note: you can have symlink on Windows 7+ too, see also "Git Symlinks in Windows"), this would be a deployment issue:
Ie: you would have:
- your regular local clone
- a copy of that clone with the right structure
- a way to diff/import any modification made in that copy back into the regular git repo
... so yes, keeping a common directory structure remains the simplest solution.
No, it will only consider changers in any part of folder 1, except folder 2 content.
Exactly.
Note: a bare repo cannot contain another repo, since there is no working tree for said repo to include... anything.
A nested repo wouldn't be recorded at all in a branch of a parent repo, contrary to a submodule.
Yes, subtree (part of git since 1.7.11) would involve 2 repos: one for Windows and one for Linux.
Each one would aggregate subtree repos with the right structure.
这篇关于如何使用Git在不同的平台上拥有不同的工作目录结构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！