1

私は開発プロセスにgitflowアプローチを適用しようとしていますが、理論的には気に入っています。しかし、どこにもカバーされていないことが1つあります...

develop誰もが結果をブランチにプッシュします。計画では、実行してベータ版にリリースしてから本番環境にリリースする必要がある10の問題があります。10の問題のうち2つは最終的に修正されていませんが、開発者がうまくやったと思ったため、部分的にはすでに開発ブランチにありますが、テスト後にバグが再び発生します。そして今、2つの問題が修正されるまで待つ必要はなく、アップロードを行う必要があります。つまり、releaseブランチを作成してベータ版でテストする必要があります。

元のgitflowの記事には次のように書かれています。

開発から新しいリリースブランチを分岐する重要な瞬間は、開発が（ほぼ）新しいリリースの望ましい状態を反映するときです。この時点で開発するには、少なくとも、ビルド予定のリリースの対象となるすべての機能をマージする必要があります

developしかし、ブランチ履歴でカップルが不要なマージを確認できる場合はどうすればよいでしょうか。どういうわけかカットする必要がありますか？または他に何かしますか？

ありがとう。

4

1 に答える 1

2

このような状況で行う最も安全な方法は、gitrevertを使用してコミットを元に戻すことです。これにより、問題のコミットを正確に逆にするコミットが作成されます。したがってgit revert 1234567、SHAidを使用してコミットを逆にする新しいコミットをブランチに作成します1234567。

これを行うことについてのいくつかのポイント：

  • git revertを実行した後、ブランチを再度マージしても、元に戻されたコミットからの変更は戻されません。元に戻すコミットを元に戻す必要があります。したがって、この例ではgit revert 1234567、この作成されたrevertcommitを想定しています09876。これで、開発者は彼の機能を適切に実装し、それをマージしたいと考えています。復帰によって変更を削除するには、git revert 09876今度は彼の更新されたブランチをマージする必要があります。
  • 自分で物事を簡単にするために、コミットを最新のものから最新のものの順に戻します。したがって、コミット1, 2, 3がある場合はどこに1ありHEADますかgit revert 1, git revert 2, git revert 3。次に、これらの復帰が変更を再導入するためのコミット8, 9, 10を作成する場合、最も新しいものから最も新しいものの順にそれらを復帰させます。
  • マージコミットを元に戻すことも可能ですが、それはもう少し複雑です。manページで説明されています。git help revert
  • これを行う必要がある場合は、Linusによるこの記事を読む必要があります。彼は、あなたが考える必要のある多くのことを説明しています。
于 2012-12-03T14:18:54.057 に答える