5

私たちの会社では、SvNからGitに移行しています（ええ、これまでよりも遅くなりました）。これにより、バージョン管理プロセスの合理化も試みます。そのために、興味深い記事を見つけました。VincentDriessenによるSuccessful GitBranchingModelです。

私が記事から読むことができる限り、開発者は線形リリースを想定しています。明確にするために：

v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc

古いリリースのサポートについては触れられていません。例：一部のクライアントはアップグレードを望まないため、最大3つのメジャーバージョンをサポートしています。したがって、次のバージョンがあると想像してください。

v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0

のリリースv8.0.0 後に重大なバグが見つかった場合は、v9.0.0タグをチェックアウトし、バグを修正して、ブランチv8.0.0にマージします。マージしてgetsタグを取得します。developmastermasterv8.0.1

2つの理由で、私にはどういうわけか奇妙に思えます。

  1. masterタイムラインは次のようになりますv7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0。私はそれが可能であることを完全に承知していますが、それも受け入れられますか？
  2. からにマージしhotfixてmaster（そしてmasterその時点でv9.0.0）タグを付けると、との間にv8.0.1機能が導入されますか？v8.0.0v9.0.0

前もって感謝します！

4

1 に答える 1

4

私にとって、タグv8.0.1はマージ前のコミットである必要がありmasterます。新しいバージョンにパッチを適用する場合は、他のタグもそこでマージします。

v8.0.0 --> v9.0.0 --> v10.0.0
   \          \           \
  v8.0.1 --> v9.0.1 --> v10.0.1/master
于 2013-01-07T10:47:37.223 に答える