很抱歉，如果这是重复的，我看了看。
我们要搬到Git。在Subversion中，我习惯于使用\ trunk，\ branches和\ tags文件夹。
使用Git，在分支之间切换将替换工作目录的内容，因此我是否可以假设我们以前的工作方式不适用于Git？
我的猜测是，我将拥有一个可能带有gitignore和readme.txt的repo文件夹，然后是组成该repo的项目的文件夹，仅此而已。
很抱歉，如果这是重复的，我看了看。
我们要搬到Git。在Subversion中，我习惯于使用\ trunk，\ branches和\ tags文件夹。
使用Git，在分支之间切换将替换工作目录的内容，因此我是否可以假设我们以前的工作方式不适用于Git？
我的猜测是，我将拥有一个可能带有gitignore和readme.txt的repo文件夹，然后是组成该repo的项目的文件夹，仅此而已。
Answers:
您将拥有“ trunk”（现在称为“ master”），“ branches”（现在称为“ heads”）和“ tags”（仍称为“ tags”），但它们不会是文件夹，而将是“ refs”，即位于存储库中单独命名空间中的修订的标签。
Subversion和Git有不同的分支方式。基本的Subversion模型是具有一个具有单个全局时间轴的目录树，如果要分支，则可以在另一个目录中复制一个子树。
另一方面，Git的目录树带有修订版本，每个修订版本都定义了其父级，但是每个修订版本可以具有多个父级（合并）和多个子级（分支）。因此，您不必拥有分支的目录，而可以独立创建修订。“参考”仅是与给定“分支”的最新修订版关联的名称。
这种差异是分布式版本控制的基础。Git（和其他分布式系统）没有任何保持历史线性的中央权限，因此可以在多个存储库之间独立创建修订版本，而无需彼此了解，并且系统必须容纳这些修订版本。事实证明，泛化通常使分支和合并变得容易得多。
请注意，在Git中，修订版不在任何分支上。它们就是，分支包含它们。但是，一旦分支合并，或者证明分支已经死了，您可以删除指向它的“ ref”，然后完全忽略它（如果您丢弃旧的试验，最终将使用对其进行垃圾收集git gc）。这可以帮助您避免陷入老旧实验而没人记住的事实。
只需将Git视为在SVN中以2D方式看到的相同数据的3D视图-即使用SVN分支您的根，它作为副本显示为树中的新文件夹。使用Git，当您分支时，它会以副本的形式显示在现有树的顶部。一旦意识到，将差异概念化就很容易了。
使用SVN，您仍然可以像Git一样工作-在分支之间切换将用分支视图替换代码库的单个视图，无论您使用svn switch还是git checkout都适用。
显然，您可以通过将分支检出到其文件夹位置来获得SVN中的分支副本，这与将git repo复制到磁盘上的其他位置相同。
标签同样适用-您可以标记git版本，也可以为发布创建分支。SVN标签与分支相同，唯一的约定是它们被称为“标签”。您可以标记（以及记录修订号）SVN存储库，以获取版本的快照。
git和svn之间的差异更多与签入和签出的方式有关，而不与源代码管理的基础有关。代码的视图可以不同（您永远不会看到在git中包含分支的代码树的单个视图，并且可以在SVN中分支部分存储库，但这最终是微小的差异）