Git 在版本控制中仅使用一些文件创建标记//分支

我已经在使用PVCS控制版本，但我即将开始一个新项目，并希望迁移到Git/SVN，保持与以前相同的结构

代码是C，它的结构使得每个C“对象”都有自己的标记，其中只有它的C文件和需要编译的H文件

在Git/SVN中，是否可以从主干创建一个分支，该分支只包含该“对象”编译、生成标记和将更改合并到主干中所需的文件

我尝试过Git，但每次创建分支时，我都会得到所有文件，包括其他“对象”中我不需要的C和H文件

---

我不知道是否还有另外一家VCS允许创建这种部分标记。

虽然您对Git分支的理解有些混乱，但我想这是可行的

首先，关于分支：在Git中，它们只是对最后一次提交的引用（在后台，分支是一个只有提交散列的文件）

Git、PVCS和SVN都以非常不同的方式工作

在Git中，如果您想将每个分支的文件分开，那么这是可能的（尽管 不寻常的）。创建基本分支的建议如下：

创建git存储库：

ghislain@linux (1): /tmp/example (master) ✔
> git init .
Initialized empty Git repository in /tmp/example/.git/

创建您的文件（尽管您可能已经拥有）：

进行初始提交（作为所有分支的基础）：

使用相关文件按文件类型创建分支：

ghislain@linux (1): /tmp/example (master) ✔
> git checkout -b files-foo master
Switched to a new branch 'files-foo'
ghislain@linux (1): /tmp/example (files-foo) ✔
> git add foo.*
ghislain@linux (1): /tmp/example (files-foo +) ✔
> git commit -m 'foo added'
[files-foo 558cdc6] foo added
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo.c
 create mode 100644 foo.h

对上述文件进行一些修改、更新和处理：

ghislain@linux (1): /tmp/example (files-foo) ✔
> vim foo.h
ghislain@linux (1): /tmp/example (files-foo *) ✔
> git add foo.h 
ghislain@linux (1): /tmp/example (files-foo +) ✔
> git commit -m 'foo.h updated'
[files-foo 9565594] foo.h updated
 1 file changed, 1 insertion(+)

对其他文件执行相同的操作：

ghislain@linux (1): /tmp/example (master) ✔
> git checkout -b files-bar master
Switched to a new branch 'files-bar'
ghislain@linux (1): /tmp/example (files-bar) ✔
> git add bar.*
ghislain@linux (1): /tmp/example (files-bar +) ✔
> git commit -m 'bar files added'
[files-bar 9f78382] bar files added
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar.c
 create mode 100644 bar.h

您的提交日志最终将显示如下，每个文件“类型”有一个分支：

当您想要处理一组文件时，您需要

git checkout

并在那里提交

然而，如果你想要一些交叉引用，或者是共同的引用，结果可能会很棘手 工作对于后者，您必须在

master

中提交并重新设置分支的基础 最重要的是（如果你想保持你的日志干净）

总的来说，这是可行的，但最终可能会让你感到非常麻烦 管理我不知道你的项目是如何运作的，但这样做可能更简单 一起使用可能更经典的分支工作流，特别是如果您

---

是Git的新手。

我无法具体说明Subversion将如何处理这个问题；实际上git和subversion是完全不同的问题。一般来说，我可以说我不相信subversion分支就是这样工作的

我可以肯定地说，git分支不是这样工作的。根据其他答案，您可以将一些东西拼凑起来，以近似于该行为，但我建议您不要这样做。这迟早会引起麻烦的

如果您想单独跟踪和编译文件集，则应将它们保存在单独的repo中，并可能与将其视为子模块的“父repo”一起使用

更一般地说，“切换工具，但保留当前工具的结构”的目标不太现实。每个源代码管理工具都有自己的项目模型、内容和历史。如果您喜欢现有的结构，您可能希望继续使用现有的工具。如果您拥有的工具工作不正常，这可能是该工具使用的结构的症状。

似乎是面向文件的（如CVS或RCS），具有集中存储（如CVS）和锁定（也如CVS）

SVN是面向提交的（并且是集中的），但将分支视为文件子树，使用合并模型而不是锁定模型（尽管实际上SVN也提供文件锁定）。在某些情况下，这可能与您使用标记的方式兼容。但可能不是这样的：如果您在相同的文件系统位置对单个文件进行不同的标记，例如，

dir/sub/file1.c

具有标记A和B，而

dir/sub/file2.c

具有完全不同的标记D和e，那么两者也不会很好地结合在一起

Git和其他现代VCSE是分布式的，而不是集中式的，并且是面向提交的。当系统是分布式的时，锁定文件的整个概念几乎是土司：没有中央权威机构声明谁拥有锁。所以这些都使用合并模型。Git还没有主干的概念：分支都是相等的，或者更准确地说，分支根本没有任何意义。在Git中，重要的是提交图，分支名称实际上是一个补充技巧，用于记住如何在图中工作

（结合可访问性的概念，Git可以丢弃不需要的对象：与其他一些现代图形导向的版本控制系统不同，提交并不比任何其他内部对象更特殊。这可能会有点迷失方向，说得委婉一点：在其他面向提交的VCSE中，一旦进行了提交，它就会永久性地丢失。）粘贴到一个分支上，您总是可以在该分支中找到它。因此，Git在这方面比Mercurial更具飞跃性。）

任何时候，当你有一个面向文件的版本控制系统时，你都很容易挑选出特定的文件，因为VCS就是这样工作的。一旦你进入一个提交模型，“工作区”（无论它在特定的VCS Git中被称为什么，它都使用短语“工作树”或“工作目录”或类似的任何东西）必须与特定提交相匹配，因为您没有获得

fileX.c

的版本V，而是获得组成版本V的所有文件。理论上，可以将此与稀疏签出和多个工作区相结合，以便工作区1具有稀疏提取的

file1.c

的版本V1，工作区2具有版本V1V2是稀疏提取的

file2.c

，诸如此类；但是您将一直与模型斗争。这可能不是一个好主意

最后，我认为除非你坚持使用面向文件的VCS，否则你将不得不改变你的工作流程。

在git上下文中，你所谓的“标记”是令人困惑的，因为git标记是

ghislain@linux (1): /tmp/example (files-foo) ✔
> vim foo.h
ghislain@linux (1): /tmp/example (files-foo *) ✔
> git add foo.h 
ghislain@linux (1): /tmp/example (files-foo +) ✔
> git commit -m 'foo.h updated'
[files-foo 9565594] foo.h updated
 1 file changed, 1 insertion(+)

ghislain@linux (1): /tmp/example (master) ✔
> git checkout -b files-bar master
Switched to a new branch 'files-bar'
ghislain@linux (1): /tmp/example (files-bar) ✔
> git add bar.*
ghislain@linux (1): /tmp/example (files-bar +) ✔
> git commit -m 'bar files added'
[files-bar 9f78382] bar files added
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar.c
 create mode 100644 bar.h

ghislain@linux (1): /tmp/example (files-bar) ✔
> git log --graph --oneline --all
* 9f78382 (HEAD -> files-bar) bar files added
| * 9565594 (files-foo) foo.h updated
| * 558cdc6 foo added
|/  
* a9a05f3 (master) Initial commit