SVN、Branchの使用方法鬼ごっこ？トランク？
私は少しうろついていて、 SVN の良い「初心者」ガイドを見つけることができませんでした。むしろ、「コマンドの使い方」という意味ではありません。ソースコードを制御するにはどうすればよいですか？
解決したいのは、次のトピックです。
- どのくらいの頻度でコミットしますか？押すたびに Ctrl + s？
- ブランチとは何ですか？タグとは何ですか？また、それらをどのように制御しますか？
- SVNには何が入りますか？ソースコードのみ、または他のファイルもここで共有しますか？ （バージョン管理されたファイルとは見なされません。）
ブランチとタグが何であるかわからないので、目的はわかりませんが、私の推測では、トランクにものをアップロードし、メジャービルドを行うときにブランチに移動しますか？それでは、この場合の主要なビルドとは何ですか？
ここにSubversionを実装するために来たとき、私は自分自身に同じ質問をしました。4〜6プロジェクトにまたがる約20人の開発者。 「答え」の良いソースは見つかりませんでした。過去3年間に私たちの答えがどのように発展したかを以下に示します。
-有用な頻度でコミットします。私たちの経験則では、変更が失われた場合にやり直さなければならない問題になるほど十分な作業を行ったときはいつでもコミットします。時には15分ごとにコミットすることもあれば、数日かかることもあります（はい、1行のコードを書くのに1日かかることがあります）
-以前の回答の1つが示したように、さまざまな開発パスにブランチを使用します。現在、プログラムの1つについて、3つのアクティブなブランチがあります。1つはメイン開発用、1つはプログラムを並列化する未完成の取り組み、1つはXML入力および出力ファイルを使用するように修正する取り組みです。
-タグはほとんど使用しませんが、本番環境へのリリースを識別するためにタグを使用する必要があると考えています。
単一のパスに沿って開発を進めることを考えてください。開発マーケティングのある時点または状態で、製品の最初のバージョンをリリースすることを決定したため、「1」（または「1.0」または何を持っているか）というラベルの付いたパスにフラグを立てます。他の時間には、明るいsparkがプログラムを並列化することを決定しますが、それには数週間かかり、人々はその間メインパスを続けたいと判断します。そのため、パスにフォークを構築し、さまざまな人々がさまざまなフォークをさまよう。
道路の旗は「タグ」と呼ばれ、道路の分岐点は「枝」が分かれている場所です。時には、枝が一緒に戻ってくることもあります。
-実行可能ファイル（またはシステム）をビルドするために必要なすべてのマテリアルをリポジトリに配置します。つまり、少なくともソースコードとメイクファイル（またはVisual Studioのプロジェクトファイル）です。しかし、アイコンや設定ファイル、その他すべてのものがあると、リポジトリに格納されます。いくつかのドキュメントがレポへの道を見つけています。確かに、プログラムに不可欠なヘルプファイルなどのドキュメントは、開発者ドキュメントを置くのに便利な場所です。
ソフトウェアを探している人に単一の場所を提供するために、製品リリース用のWindows実行可能ファイルもそこに入れています。Linuxリリースはサーバーに移動するため、保存する必要はありません。
-リポジトリが常にビルドおよび実行する最新バージョンを提供できる必要はありません。一部のプロジェクトはそのように機能し、一部のプロジェクトは機能しません。決定はプロジェクトマネージャーに委ねられ、多くの要因に依存しますが、プログラムに大きな変更を加えると崩れると思います。
* How often do you commit? As often as one would press ctrl + s?
できるだけ頻繁に。ソース管理下にない限り、コードは存在しません:)
頻繁なコミット（その後、より小さな変更セット）を使用すると、変更を簡単に統合し、何かを壊さない可能性を高めることができます。
他の人々は、機能的なコードを作成したらコミットする必要があると指摘しましたが、少し頻繁にコミットする方が便利だと思います。簡単な元に戻す/やり直しのメカニズムとしてソース管理を使用していることに気付きました。
自分のブランチで作業するときは、可能な限りコミットすることを好みます（文字通り、ctrl + sを押すたびに）。
* What is a Branch and what is a Tag and how do you control them?
読む SVNブック -SVNを学習する際に開始すべき場所です：
* What goes into the SVN?
ドキュメント、ビルドに必要な小さなバイナリ、その他の価値のあるものはソース管理に送られます。
コミット頻度、コミットメッセージ、プロジェクト構造、ソース管理下に置くもの、その他の一般的なガイドラインに関するリソースを次に示します。
- バージョン管理のベストプラクティス（自分のブログ）
- 早期チェックイン、頻繁にチェックイン（コーディングホラー） （ここのコメントには多くの良いアドバイスが含まれています）
- KDEのコミットポリシー
これらのStack Overflowの質問には、興味深い可能性のある有用な情報も含まれています。
- 2つ以上の言語（JavaとC++など）を混在させる場合のソースコードベースの整理
- 適切なコミットメッセージの提案：format/guideline？
- 変更をソース管理にコミットする頻度
- バージョン管理を学習し、それをうまく学習する
分岐やタグ付けなどのSubversionの基本的な概念については、これは The Subversion book で非常によく説明されていると思います。
主題についてもう少し読んだ後に気付くかもしれませんが、この分野でのベストプラクティスについての人々の意見は、しばしば異なり、時には矛盾します。あなたにとって最良の選択肢は、他の人が何をしているかを読み、あなたにとって最も意味のあるガイドラインと実践を選ぶことだと思います。
あなたがその目的を理解していないか、その背後にある理論的根拠に同意しない場合、それを実践することは良い考えではないと思います。そのため、盲目的にアドバイスに従うのではなく、自分に最適だと思うことについて自分で決めてください。また、物事のさまざまな方法で実験することは、あなたがどのように仕事をしたいのかを学び、見つけるための良い方法です。これの良い例は、リポジトリの構成方法です。それを行うための正しい方法や間違った方法はありません。実際にそれらを実際に試してみるまで、どの方法を好むかを知るのは難しい場合があります。
コミット頻度は、プロジェクト管理のスタイルによって異なります。多くの人は、ビルド（または機能）が壊れるとコミットすることを控えます。
ブランチは2つの方法のいずれかで使用できます。通常は、1）開発用の1つのアクティブなブランチ（およびトランクは安定したまま）、または2）代替開発パス用のブランチです。
通常、タグはリリースを識別するために使用されるため、ミックスで失われることはありません。 「リリース」の定義はあなた次第です。
主な問題は、ソース管理の考え方が混乱していることだと思います。通常、トランクとブランチがありますが、タグ/リリースまたはそれに影響を与える何かの無関係なアイデアが得られます。
ツリーの考え方をより完全に使用すると、少なくとも私にとっては明確になります。
トランクを取得->ブランチを形成->フルーツ（タグ/リリース）を生成します。
トランクからプロジェクトを成長させ、トランクがブランチを保持するのに十分安定したらブランチを作成するという考え方です。次に、ブランチがフルーツを生成したら、ブランチからそれを摘み取り、タグとしてリリースします。
タグは基本的に成果物です。一方、トランクとブランチはそれらを生成します。
他の人が言ったように、 SVN Book は開始するのに最適な場所であり、海の足を手に入れたらすぐに参照できます。さて、あなたの質問に...
どのくらいの頻度でコミットしますか？ ctrl + sを押すのと同じくらい頻繁に？
多くの場合、ctrl + sを押すほど頻繁ではありません。それは個人的な好みやチームポリシーの問題です。個人的には、小さなコードでも機能的なコードを完成したときにコミットすると言います。
ブランチとは何ですか？タグとは何ですか？それらをどのように制御しますか？
まず、trunkはあなたが積極的に開発を行う場所です。これがコードのメインラインです。ブランチはメインラインからの逸脱です。以前のリリースのように大きな逸脱である場合もあれば、試してみたい微調整である場合もあります。タグは、コードのスナップショットです。これは、ラベルまたはブックマークを特定のリビジョンに添付する方法です。
Subversionでは、トランク、ブランチ、およびタグは単なる慣習にすぎないことにも言及する価値があります。タグでの作業を行ったり、メインラインであるブランチを作成したり、タグブランチブランチスキームをすべて無視したりすることを妨げるものは何もありません。しかし、非常に正当な理由がない限り、慣習に従うことをお勧めします。
SVNには何が入りますか？ソースコードのみ、または他のファイルもここで共有しますか？
また、個人またはチームの選択。ビルドに関連するものはすべてリポジトリに保存することを好みます。これには、構成ファイル、ビルドスクリプト、関連メディアファイル、ドキュメントなどが含まれます。各開発者のマシンで異なる必要があるファイルをnotチェックインする必要があります。また、コードの副産物をチェックインする必要もありません。私は主にビルドフォルダ、オブジェクトファイルなどを考えています。
2009年1月にSO podcast＃36に登場したEric Sinkは、タイトル Source Control How-to の下で優れたシリーズの記事を書きました。
（Ericは SourceGear の創始者で、プラグイン互換バージョンのSourceSafeを販売していますが、恐ろしいことはありません。）
別の答えを追加するだけです：
- 仕事を終えるたびにコミットします。場合によっては、1行変更しただけで2分かかる小さなバグ修正でした。それ以外の場合は、2週間分の汗です。また、経験則として、ビルドを壊すものは何もコミットしません。したがって、何かをするのに時間がかかった場合は、コミットする前に最新バージョンを使用し、変更がビルドを壊すかどうかを確認してください。もちろん、コミットせずに長時間行くと、その仕事を失いたくないので不安になります。 TFSでは、この素敵なものを「シェルフセット」として使用します。 SVNでは、別の方法で回避する必要があります。おそらく、独自のブランチを作成するか、これらのファイルを手動で別のマシンにバックアップしてください。
- ブランチは、プロジェクト全体のコピーです。それらの使用に最適な例は、おそらく製品のバージョン管理です。大規模なプロジェクト（Linuxカーネルなど）で作業していると想像してください。汗を流してから、ようやくバージョン1.0に到達し、一般に公開されました。その後、製品のバージョン2.0の作業を開始します。しかし、当面はバージョン1.0を使用している人も大勢います。そして、これらの人々はあなたが修正しなければならないバグを見つけます。現在、次の2.0バージョンのバグを修正してクライアントに出荷することはできません-まだ準備ができていません。代わりに、1.0ソースの古いコピーを取り出し、そこでバグを修正し、それを人々に出荷する必要があります。これがブランチの目的です。 1.0バージョンをリリースしたとき、SVNにブランチを作成し、その時点でソースコードのコピーを作成しました。このブランチの名前は「1.0」です。その後、メインのソースコピーで次のバージョンの作業を続けましたが、1.0のコピーはリリース時の状態のままでした。そして、そこでバグの修正を続けることができます。タグは、使いやすいように特定のリビジョンに付けられた単なる名前です。 「ソースコードの改訂2342」と言うこともできますが、「最初の安定した改訂」と呼ぶ方が簡単です。 :)
- 私は通常、プログラミングに直接関係するすべてをソース管理に入れます。たとえば、私はWebページを作成しているので、構成ファイルなどは言うまでもなく、ソース管理にも画像とCSSファイルを配置します。プロジェクトのドキュメントはそこには入りませんが、実際は好みの問題です。
他の人は、それはあなたのスタイルに依存すると述べています。
あなたにとっての大きな疑問は、あなたがどれくらいの頻度でソフトウェアを「統合する」かということです。テスト駆動開発、アジャイルおよびスクラム（および他の多くの多く）は、小さな変更と継続的な統合に依存しています。彼らは小さな変更が行われ、誰もが休憩を見つけて、それを常に修正することを説きます。
ただし、大規模なプロジェクト（政府、防衛、100k + LOCなど）では、継続的インテグレーションは不可能であるため使用できません。これらの状況では、多くの小さなコミットを行うためにブランチを使用する方がよいかもしれませんが、動作するものだけをビルドに統合する準備ができているものだけをトランクに戻します。
ただし、分岐の注意点は、適切に管理されていない場合、トランクのさまざまな場所から開発しているため、リポジトリ内で作業を行うのは悪夢である可能性があることです（これは、継続的インテグレーション）。
この質問に対する決定的な答えはありません。最善の方法は、チームと協力して最良の妥協ソリューションを考案することです。
Subversionを使用したバージョン管理 は、初心者と高齢者向けのガイドです。
少なくとも最初の数章を読むことなくSubversionを効果的に使用できるとは思いません。
コミットするには、次の戦略を使用します。
できるだけ頻繁にコミットします。
各機能変更/バグ修正は、独自のコミットを取得する必要があります（一度に多くのファイルをコミットしないでください。そのため、そのファイルの履歴が不明瞭になります。たとえば、ロギングモジュールとGUIモジュールを個別に変更し、両方を同時にコミットすると、両方の変更が両方のファイル履歴に表示されます。これにより、ファイル履歴の読み取りが困難になります）、
コミット時にビルドを中断しないでください。リポジトリのどのバージョンでも取得してビルドできるはずです。
アプリのビルドと実行に必要なすべてのファイルはSVNにある必要があります。テストファイルなどは、単体テストの一部でない限り、そうすべきではありません。
私たちの仕事でのポリシーは次のようになります（複数の開発者チームがオブジェクト指向フレームワークに取り組んでいます）：
前日の変更を取得するために毎日SVNから更新する
翌日病気になったり欠席したりした場合、中断したところから他の人が簡単に引き継ぐことができるように、毎日コミットしてください。
他の開発者に影響を与えるため、何かを壊すコードをコミットしないでください。
小さなチャンクで作業し、意味のあるコメントで毎日コミットしてください！
チームとして：開発ブランチを維持し、プレリリースコード（QA用）を本番ブランチに移動します。このブランチには、完全に機能するコードのみが含まれている必要があります。
ここには多くの良いコメントがありますが、言及されていないのはコミットメッセージです。これらは必須で意味のあるものでなければなりません。特に分岐/マージの場合。これにより、どの変更がどのバグ機能に関連しているかを追跡できます。
たとえば、svn commit . -m 'bug #201 fixed y2k bug in code'は、そのリビジョンが何であったかを履歴を見ている人に通知します。
一部のバグ追跡システム（tracなど）は、これらのメッセージのリポジトリを調べて、それらをチケットに関連付けることができます。これにより、各チケットにどの変更が関連付けられているかが非常に簡単になります。
TortoiseSVN TSVNマニュアル は Subversion book に基づいていますが、より多くの言語で利用できます。
頻度のコミットには2つの方法があると思います。
- 実装された各メソッド、コードのごく一部など、非常に頻繁にコミットします。
- モジュールなど、完成したコード部分のみをコミットします。
私は最初のものを好む-ソース管理システムを使用することは、プロジェクトや会社だけでなく開発者にとっても非常に有用であるからです。私にとって最良の機能は、割り当てられた最適なタスク実装を検索しながら、すべてのコードをロールバックすることです。