Git、セマンティックバージョニング、およびそれが（私の）典型的な開発タイムラインにどのように適合するか？
Q＆Aシステムに取り組んでいて、現在のアプリケーションに最初の公式バージョン/タグとして「1.0.0」のタグを付けようとしています。ベータテストのために、次に限られたテスト対象者に向けてロールアウトされます。この段階で「1.0.0」は正しいですか？
また、その段階で多くのバグが見つかることは間違いありません。 「1.0.0」のままにしておきますが、リリースされるまでタグを強制的に移動します。または、バグを修正したら、新しいタグ「1.0.1」を付けますか。その後、おそらく「1.0.2」のテストを繰り返します。
したがって、拡張（たとえば、新しいメニュー、新しい検索入力フィールドなどの新機能）に取り組む場合、これらは「1.0.0」から「1.1.0」へのように小さな変更でしょうか？
セマンティックバージョニングの使用を検討していると述べたので、セマンティックバージョニング仕様を http://semver.org/ で見てみましょう。
バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。
- 互換性のないAPI変更を行った場合のメジャーバージョン
- 下位互換性のある方法で機能を追加する場合のマイナーバージョン
- 下位互換性のあるバグ修正を行う場合のパッチバージョン。
プレリリースおよびビルドメタデータの追加のラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。
そしてもう少し下：
プレリリースバージョンは、パッチバージョンの直後にハイフンと一連のドットで区切られた識別子を追加することによって示すことができます。識別子は、ASCII英数字とハイフン[0-9A-Za-z-]のみで構成する必要があります。識別子を空にすることはできません。数値識別子に先行ゼロを含めることはできません。プレリリースバージョンの優先順位は低くなります。関連付けられた通常のバージョンよりも高いです。プレリリースバージョンは、バージョンが不安定であり、関連付けられた通常のバージョンで示されているように、意図した互換性要件を満たさない可能性があることを示します。例：1.0.0-alpha、1.0.0-alpha.1、1.0 .0-0.3.7、1.0.0-x.7.z.92。
したがって、1.0リリースの真のベータ版をリリースする場合は、1.0.0-beta（または仕様に従って同様）のタグを付ける必要があります。バグを修正するときに複数のベータ版をリリースする場合は、1.0.0-beta.1、1.0.0-beta.2など。
下位互換性のある機能を追加する場合は、マイナー番号を増やす必要があります。アプリケーションの他の場所で重大な変更が発生するような多くの内部変更を行った場合、それは大きな変更です。劇的な変更をあまり行わない場合（たとえば、コードをaddだけ追加し、動作を変更しない場合既存のコードの場合）、これはマイナー変更になります。 UIの多いアプリケーションがあり、そのUIを完全に変更する場合、それもメジャーな変更であると言えます（UIはエンドユーザーのAPIと見なすことができます）。
howを使用してgitリポジトリにインジケーターを追加する場合は、最初に1.xブランチを作成することをお勧めします。これにより、マスターでのバージョン2の継続的な開発を可能にしながら、バージョン1のすべてを簡単に追跡できます。次に、ベータ版リリースに1.0.0-beta（または複数のベータ版がある場合は-beta.1）のタグを付けます。修正する必要があるすべてのバグを修正したら、実際の1.0.0リリースにタグを付けます。次に、必要に応じて各リリースにタグを付けます。
git flow や github flow のようなgitの実証済みのワークフローで、継続的なワークフローを設定する方法のアイデアを確認できます。
また、APIを使用しないプログラムのセマンティックバージョニングについてもう少し詳しく知りたい場合は、 この答え を少し詳しく説明します。
はい、それがあなたのコントロールの外に移動し、他の誰かのものになるたびに、バージョン番号を更新してください。
その理由は、彼らが何を使っていたかを知る必要があるからです。テストが戻って「バージョン1.0.0にバグが見つかりました」と言ったとき、最後に言いたいのは、「どのバージョン1.0.0か、月曜日に提供したバージョンか、金曜日に更新したバージョンですか？」 」
3番目の数値の更新はこれのために実際に設計されたものであり、1.0.0と1.0.999の間の機能的な違いは制限されるはずです。大きな新しい機能を追加した後、2番目の数値を更新します。ただし、新しい検索入力フィールドを追加しても、2番目の数値の更新を保証するのに十分なほど大きな変更とは見なされませんが、YMMVです。
個人的に、私は2番目の番号を機能の更新ではなく、「完全なリリース」、つまりテストを通過して合格したものとしてマークする傾向があります。次に、その値を更新して、devとtestの間を往復し、すべてがパスするまで3番目の数値を毎回インクリメントします。
良い答えはすでに与えられていますが、git sha1をアプリケーションに組み込む方法も見つけられるので、この特定のリリースで使用されたのはgit commit 1b5619273127398123でした。このようにして、BigCoのスミス氏が電話をかけ、アプリが正しく機能していないと不平を言った場合は、「2番目の文字列の数字と文字の長い列は、[バージョン情報]をクリックすると何ですか？」と尋ねることができ、git checkout NNNNNNそのバージョンを正確に取得するには、スミス氏と同じ手順を実行し、（うまくいけば）問題を再現します。微妙に異なるバージョンを使用しているために再現できない問題を見つけようとするよりも悪いことはありません（偶然または意図的にその特定の問題を回避している場合）。
また、ビルドシステムがバージョンに含まれていることを確認します-できればどのコンパイラバージョンなどを含めて-エンコードするか、gitリポジトリ内で製品をビルドするときに使用するビルドツールを保存します。