1

私はバージョン管理は初めてですが、Git が自分の著作のコレクションを管理する優れた方法であることにすぐに気付きました。これは少し変わった使用例なので、Git のどの機能が「収集された」書き込み (つまり、セット全体) を管理し、「選択された」書き込み (つまり、コレクションのサブセット) を管理するのに最適かについて質問があります。 ）。

たとえば、200 個の .txt ファイルを含むリポジトリがあります。それぞれが詩のテキストです。では、たとえば原稿を作成するために、それらのファイルを 20 個取っておきたいと思います。これらの 20 個のファイルをグループとして考えながら作業している間に、それらに変更を加えることがあります。もちろん、これらの変更が 200 ファイルすべての「マスター」リポジトリに反映されることを望みます。

これに役立つ可能性のあるさまざまなアプローチを見てきましたが、混乱しています。

  1. 私が最初に試したのは、シンボリックリンクでいっぱいのサブフォルダーでした。Windows 上の Git がシンボリック リンクをうまく処理できないことに気付くまでは、これは素晴らしいことでした。
  2. のbranch助けを借りて、これを適切に処理できます。merge --strategy ours
  3. submoduleただし、原稿プロジェクトの問題を個別に追跡し、関連する wiki を bitbucket 上のプロジェクトとして、またはどこにでも保持できるため、私はそれを好むかもしれません。また、今後のコラボレーションが少し楽になるかもしれません。ただし、サブモジュールには落とし穴があると聞きます。それらは私にとって問題になるでしょうか？
  4. 次にありsubtreeます。それは私が考えていることにとってより良い方法でしょうか？サブツリーまたはサブモジュールは、ブランチで気に入っているのと同じマージ戦略を使用できますか?
  5. 考慮すべき他の、潜在的により良い方法はありますか?
4

1 に答える 1

0

私はポイントを逃しているかもしれません。git の存在理由は、分岐が簡単なことです。これにより、基本的に並行作業ラインを非常に簡単に作成できます。

ただし、マスターからブランチを作成するだけの場合は、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 に答える