簡単な話ですが、私はアプリケーションのコードの GIT リポジトリを管理しています。アプリケーションにはテストがありません。開発者の 1 人がフィーチャー ブランチをマスターに直接マージし、Jenkins がそれをステージにデプロイしました。この機能ブランチには数週間分の変更があり、マスター ブランチに数回マージされました。そのため、休暇から戻ってきて、いくつかの機能が壊れていたり、ゴールデンタイムの準備ができていない機能が追加されていることに気付きました。マージとコミットを元に戻すことで、問題のあるコードを引き出すことができました。この修正されたコード ベースを実行し、手動でテストして問題を解決したいと考えています。PM は、Whats on live を GIT リポジトリにドロップしたいと考えています。これはとても間違っているようです。他の解決策やコメントはありますか？
質問する
55 次
1 に答える
1
首相が何をしたいのか理解できませんでした。
「よく維持された」Gitリポジトリには、修正を含む機能ごとに1つのブランチがあり、安定してテストに合格するとマージされます。
私はそれに固執することがどれほど難しいかを知っており、想像しています。だから、あなたが今持っているのは、コミットが何を表しているのかわからないレポだと思います。
それで、安定したものが欲しいですか？経験はほとんどありませんが、履歴の安定したコミットから始めることをお勧めします。そこから分岐し、それを「stable」と呼びます。これがメイン ブランチになります。新しい機能やバグを導入するコミットから連続してマージします。それぞれについて、安定するまで修正をコミットし、次の悪いコミットの前にこれらの修正が含まれるようにリベースします。
たとえば、前に：
A (安定) - B (機能 1、バグあり) - C (機能 2、さらにバグあり) - D (悪い)
後：
A - B - B1 - B2 - C - C1 - D - D1
(A、B2、C1、D1 が安定したマイルストーンになるように)。全体として、リベース、マージ、チェリーピックで遊んで、やりたいことを実行できます。この記事 : Git Cherry-pick vs Merge Workflowは、他のワークフローに慣れていない場合はマージを使用することをお勧めしますが、非常に役立つ違いはほとんどありません。
問題が解決することを願っています
于 2012-08-16T21:31:23.307 に答える