1

我是版本控制的新手，但我很快发现 Git 是管理我的作品集的好方法。这是一个稍微不寻常的用例，所以我有一个问题，关于 Git 的哪个功能最能帮助我管理“收集的”作品（即整个集合）和管理“选定的”作品（即集合的子集） ）。

例如，我有一个包含 200 个 .txt 文件的存储库。每一个都是一首诗的文本。现在，我想留出其中的 20 个文件，例如，用于创建手稿。当我处理这 20 个文件并将它们视为一个组时，我可能会对它们进行更改。当然，我希望这些更改能够反映在我所有 200 个文件的“主”存储库中。

我已经看到了多种可能适用于此的方法，但我很困惑。

  1. 我尝试的第一件事是一个充满符号链接的子文件夹。这很可爱，直到我意识到 Windows 上的 Git 不能很好地处理符号链接。
  2. abranch可以很好地处理这个问题，在merge --strategy ours
  3. 我可能更喜欢一个submodule，因为它可以让我单独跟踪手稿项目的问题，并保留一个相关的 wiki，作为 bitbucket 或任何地方的项目。它还可能使协作变得更容易。但是，我听说子模块存在缺陷。这些对我来说会是个问题吗？
  4. 然后是subtree. 对于我的想法，这会是更好的方法吗？子树或子模块可以使用我喜欢的分支合并策略吗？
  5. 还有其他可能更好的方法需要考虑吗？
4

1 回答 1

0

我可能错过了重点。git 存在的理由是它很容易分支。这实质上允许您非常简单地创建平行的工作线。

但是，如果您只是从您的 master 创建一个分支，将您的 20 首或诗歌整理到一个文件夹中，然后提交到这个新分支（维护您的 20 首诗歌的平行宇宙），然后在您想要这些更改时将其合并到 master 中在您的主分支中注册。

$ git branch manuscript
$ git checkout manuscript

$ mkdir my20poems
$ cp *.poems my20poems

$ git add my20poems
# make your changes, now commit them in my commit graph 
$ git commit -m "did some work"
# now I want these changes in master
$ git checkout master
$ git merge manuscript  #or even use the --no-ff switch if you want the branch history kept

您可以随时重新访问您之前的任何提交，以便保留所有已提交的状态。

$ git log --oneline --decorate --graph --all
于 2013-10-01T16:33:46.183 回答