2

C++ プロジェクトに Git バージョン管理システムを使い始めることにしました。私はバージョン管理が初めてです。トランクについては簡単です。所有しているすべてのプロジェクト バージョンをコミットするだけです。すぐに Git を使用することを知っていたので、各バージョンを個別のフォルダーとして保持しました。しかし、ブランチで問題が発生しました。

開発のある段階で、ブランチで開発したいクラスが 1 つあると判断しました。バージョン管理がなければ、「手動」ブランチを作成する必要がありました。そのクラスの最新のヘッダー ファイルとソース ファイルを別のフォルダーにコピーし、そこで作業を開始しました。同時に動作するようにいくつかのバージョンを作成しました。1 つのバージョンは、計画に従ったクラスの最初のプロトタイプでした (そのための「ブランチ」を作成しました)。次に、最初のファイルをコピーし、不要と思われるものを削除した別のファイルを追加しました。このようにして、2 つのバージョンがあります。1 つはすべてのアイデアと機能を備えたもので、もう 1 つはコードで実際に使用しているものだけを使用したもので、現在使用されていないものはありません。

しかし、私はさらに追加しました。開発が進むにつれて、そのクラスをテンプレートにするのは良い考えかもしれないと判断しました。そこで、2 番目のバージョンと同様の 3 番目のバージョンを追加しましたが、ポリモーフィズムを使用して実装された一部の機能は、テンプレートを使用して実装されています。そして、どのバージョンがベストかはまだわかりません。判断するには時期尚早なので、3 つすべてをまとめて使用したいと考えています。

次に、別の特別なファイルを作成しました。これは、3 番目のバージョンのヘッダー ファイルのコピーで、各行にマークを付けるかどうかを指定できます。マークされているとは、その特定のメソッドを使用しているか、すぐに使用されると確信していることを意味します。それ以外の場合、行はマークされていません。

それからしばらくして、新しいブランチを開始しました。そのブランチには、最初のブランチで開発されたそのクラスの新しいバージョンが必要でした。そのため、バージョンの 1 つを新しいブランチのフォルダーにコピーして、そこで作業を開始しました。ここでも、ある種の補助ファイルがありました。2 つのファイルがありました。1 つは使用しているクラス メソッドを削除するファイルで、もう 1 つは必要な新しいメソッドを書き込むファイルです。

今、私は Git を使い始めたいのですが、疑問に思っています: すべてのプロジェクトのテキスト ファイル、計画、図などについて、それは明らかです - 私はそれらを Git リポジトリの外に置いています。共同編集が必要なときはいつでも、wiki などを設定できます。しかし、同じヘッダー ファイルのすべてのコピーと、補助的な「マーク付き」ファイルについては、どうすればよいでしょうか。つまり、それらすべてをブランチに入れるのは問題ありませんが、ブランチをトランクにマージするとどうなりますか? これらすべてのコピー、バージョン、およびリストを保持したくはありません。私が作成した最終的なクラス ファイルを 1 つだけ保持したいと考えています。

一方では、これらはコーディング中に使用される C++ ソース ファイルです。一方、それらはソフトウェア パッケージの純粋なソース コードの一部ではなく、作業中に役立つだけで、コンパイルされることはありません。他のすべての aux ファイル、リストなどは参照用に保持されています。

どうするのが一番いいでしょうか?私の長い話を読んでくれてありがとう:)

編集:それは私のパソコンのローカルレポです

4

3 に答える 3

3

ドキュメントは常にソース コードと同じリポジトリに保管してください。そうしないと、ドキュメントが腐ります。ドキュメントはソフトウェアのあるバージョンに対して書かれているため、ソフトウェアが開発するのと同じ方法で開発する必要があります。

ドキュメントが自動的に生成されるか、別の形式にコンパイルされる場合は、ソース コードの場合と同様に、ソース データ、makefile、およびジェネレーターの構成のみをコミットします。

于 2013-01-31T12:20:04.307 に答える
2

あなたが説明するのは、ブランチの通常の使用です。マスターブランチ(「公式」、もしあれば)と、新しい機能を開発するためのブランチ(私があなたを理解していれば、実際には別のディレクトリに存在する必要はありません)があります正しく)。定期的に、機能ブランチをマスターにリベースするか、その変更をマージすることにより、機能ブランチをマスターと同期します。次に、機能に関して処理される、機能を開発するためのアプローチを試す下位ブランチを持つことができます。マスターへの敬意のようなブランチ。ただし、その場合、リベースするたびに注意する必要があります。

ソース コード、ドキュメント、デザイン スケッチなど、簡単に再作成できないデータはすべてリポジトリに保持する必要があります。再作成できるもの (オブジェクト コード、自動的にフォーマットされたドキュメントなど) は除外する必要があります (そこに変更を加えると、チェックインされる違いが生じます)。あなたのリポジトリ (特に公開されたブランチではない) は、あなた自身のワークスペースです。

git ホームページで言及されている本を見てください。

于 2013-01-31T12:20:40.510 に答える
1

これは明らかにドキュメントであり、ソース コードではないため、ソース コードから分離する必要があります。ドキュメントはブランチに依存しているように見えるため、リポジトリにチェックインする必要がありますが、別のdocディレクトリにあります。

マージについて: マージがどのように機能するかは、最終的にはあなた次第です。Git にはデフォルトのマージ戦略しかありません。これは、ほとんどの場合、ほとんどの人が望んでいるものです。しかし、メイン ブランチへのマージはドキュメントではなくコードだけを持ってくるべきだと言うなら、それで問題ありません。そのようにマージするだけです:

git merge mybranch --no-commit
rm -rf **docu-dir**
git add -A
git commit
于 2013-01-31T11:09:54.093 に答える