0

Pro Gitの本（Apress 2009）で、第3章の例が次のようになっているのはなぜだろうか。

  1. 現在ブランチでコミットされているものはすべてmaster、すでに本番環境にプッシュされています
  2. iss53機能開発用のブランチを作成し、一時的な変更を追加して、コミットしました。
  3. ホットフィックスが必要なため、ブランチに切り替えてブランチmasterを作成しますhotfix
  4. バグ（テクニカルサポートの電子メールアドレスのタイプミスなど）を修正し、コミットして、本番環境にプッシュします
  5. ブランチに切り替えてブランチmasterとマージするhotfix
  6. （オプションで）hotfixブランチを削除します

この時点で、なぜ本がブランチに行き、masterブランチとマージするのだろうかと思いiss53ます。これは実際にマスターブランチを中間状態にしませんか？別のホットフィックスが必要な場合、マスターはホットフィックスを実行するのに適していないため、マージ前のコミットを手動で選択する必要があります。iss53マージは、ブランチに移動してブランチとマージするべきではありません。hotfixそうすれば、間違っていたことが将来のリリースにも組み込まれるようになりますか？

更新：実際、この本はiss53作業が完了していることを前提としており、最後のマージを実行します。しかし、作業iss53がまだ完了しておらず、ホットフィックスにマージしたい場合はどうなりますか？

4

2 に答える 2

0

@動靜エネルギー量、

その場合、次の 3 つの選択肢があります。

  1. cherry-pickへのhotfixコミットiss53
  2. masterにマージiss53
  3. iss53にリベースmaster

個人的には#3の方が好きです。それはよりクリーンな歴史を与えるからです。

ただし、開発者が多すぎる場合 (Linux のように)、#2 の方が簡単かもしれません。これはまれなはずです。その場合、master履歴が複雑になりすぎないように、安定したポイント (たとえば、ランダムなテスト状態ではなく、安定したポイントのリリース) でマージするようにしてください。

LWN には、これについて詳しく説明する記事があります。

于 2012-08-30T01:13:52.820 に答える
0

作業iss53が完了していないがホットフィックスが必要な場合は、 にマージmasterするか、(より良い)の上にiss53リベースすることができます。iss53master

マージ：

git checkout iss53
git merge --no-ff master # --no-ff keeps the master tip where it is

リベース (この章の後半で説明します):

git checkout iss53
git rebase master
于 2012-08-30T01:17:08.930 に答える