如果我使用分支而不是修订版，Git 的扩展方式是否相同？
我想使用 Git 有效地存储和版本数据，但我也希望能够按需更改修订版本。
所以我想使用具有许多分支的 Git，而不是通常的修订版。对于我的数据的每个“版本”，都会有一个分支。
每个分支只有少数文件会更改，并且每个分支会有 1-10 个修订版，具体取决于某个修订版更改的频率。
所以文件/数据加载几乎是正常的，我只会有很多分支而不是修订。
我知道这是一种奇怪的 Git 使用方式，但它能扩展吗？
dbyrne 询问了用例。我不确定是否有帮助，但这里是：
- 我计划版本 Vagrant 元数据
- 我在单独的 SCM 中有一些项目（例如 SVN）并且每个修订都属于 Vagrant VM
- 每个 Vagrant VM 都有元数据和安装文件，对于许多修订来说通常是相同的
- 有时我必须更改元数据并且我需要支持我的项目的分支，所以我想要对每个修订版使用 Git 分支
- 我的应用程序将跟踪项目修订和 Git 元数据
- 我的应用程序将检查每个给定项目版本的相关文件
- 使用元数据，可以为每个项目修订创建一个虚拟机
I want to use Git to store and version data efficiently, but I also want to be able to change revisions on demand.
So I want to use Git with many branches instead of the usual revisions. For every "version" of my data there will be a branch.
Only a few files will change per branch and there would be 1-10 revisions per branch, depending on how often a certain revision has to change.
So the file/data load would be almost normal, I would only have a lot of branches instead of revisions.
I know that this is a strange way to use Git, but would it scale?
dbyrne asked for the usecase. I am not sure if helps, but here it is:
- I plan to version Vagrant metadata
- I have some project in a separate SCM (e.g. SVN) and every revision belongs to a Vagrant VM
- Every Vagrant VM has metadata and install files, which will often be the same for many revisions
- Sometimes I have to change the metadata and I need to support branches of my project, so I wanted to use Git branches for every revision
- My application will keep track of project revisions and Git metadata
- My application will check out the relevant files for every given project version
- With the metadata it is possible to aromatically create a VM for every project revision
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一般来说，git 处理分支非常有效。您可以非常快速地在分支之间来回切换，并且它们的占用空间很小，因为每个分支仅存储增量（而不是整个副本）。
您计划开设多少家分行？我认为更多关于您的用例的背景可能有助于回答这个问题。
In general, git handles branching very efficiently. You can switch back and forth between branches very quickly, and they have a small footprint because each branch only stores the delta (not an entire copy).
How many branches are you planning to have? I think a little more background about your use case might be helpful in answering this question.
我不是专家，但根据我的理解，Git 的工作原理是详细说明每个分支中的更改，因此每个分支不是主干或另一个分支的副本，它只是差异的详细信息，因此在您的示例中，每个分支都会非常就数据而言较小。
我一直被告知 Git 是为高分支使用率而设计的（我认为这是它的主要卖点），所以是的，它应该可以扩展。
HTH
保罗·
I'm not an expert but from my understanding Git works by detailing the changes in each branch so each branch is not a copy of the Trunk or another branch, it simply the details of the differences, so in your example each branch would be very small in terms of data.
I have always been told that Git is designed for high branch usage (it's main selling point IMO) so yes it should scale.
HTH
Paul
你在这里所追求的并不是真正偏离正常的 git 使用。分支对于保存您想要单独跟踪的内容的不同变体非常有用，而每个分支还包含可追溯的历史编辑。
与其他（通常是集中式）vcs 包不同，git 鼓励并允许您设计适合您特定需求的工作流程。你必须适应SVN。您可以围绕自己的流程和需求塑造 git。
我怀疑您会发现最方便的工作流程是拥有一个发生通用更改的中央“主”分支，然后从主分支定期更新各个分支。这样，您就可以在所有子分支中推送重大的基本错误修复或其他任何内容，同时保持每个子分支的独特之处。
What you're after here isn't really a deviation from normal git usage. Branches are useful for holding different variations on the content that you want to track separately, while each branch also contains historical edits going back through time.
Unlike other (usually centralized) vcs packages, git encourages and empowers you to design workflows that fit your specific needs. You have to adapt to SVN. You can mold git around your own processes and needs.
I suspect you'll find the most handy workflow will be to have a central "master" branch where universal changes happen, and then individual branches that are periodically updated from the master. That way you can push big fundamental bugfixes or whatever through all your child branches, while maintaining whatever's unique about each of them.