これは私がこれを観て試みてきたワークフローですGit/TFS ビデオ。
そこで開発ブランチからブランチを作成します
$ git checkout -b my-feature-branch development
次に、変更を加え、ステージングし、コミットし、変更を TFS サーバーにプッシュします。
TFS Web インターフェイスにアクセスすると、サーバー上に「my-feature-branch」が表示されます。
「新しいプル リクエスト」をクリックして開発に PR を作成し、この PR を承認します。このプロセスにより、TFS サーバー上の「my-feature-branch」は削除されますが、ローカル マシンには残ります。
この時点ではすべて順調です。
ローカル マシンに戻り、機能ブランチから切り替えます。
git checkout development
ローカルブランチを削除する
git branch -d my-feature-branch
warning: deleting branch 'my-feature-branch' that has been merged to
'refs/remotes/origin/test-pr', but not yet merged to HEAD. Deleted branch my-feature-branch (was d525adc).
最新情報を入手 -
git pull -p
場合によっては、削除の前にプルを実行しているにもかかわらず、削除が失敗し、強制的に削除しなければならないことがあります。
git branch -D my-feature-branch
私のワークフローは間違っていますか? 削除する前に何らかのマージを行う必要がありますか? プル後に機能ブランチがプル リクエストとしてマージされたことを git が認識せず、エラーなしで削除できないのはなぜですか?
答え1
git は、プル後に機能ブランチがプル リクエストとしてマージされたことを認識せず、エラーなしで削除できないのはなぜですか?
提供された情報から判断するのは難しいですが、2 つの推測があります。
ローカル機能ブランチを削除する前にプルしていることを確認していますか? そうでない場合、もちろんメインブランチには新しいコミットが含まれません。
フィーチャーブランチをどのようにマージしますか?通常のマージですか、それともスカッシュマージですか?通常のマージでは、フィーチャーブランチのコミットをメインブランチに組み込むため、Gitはすべてがそこにあると認識します。一方、スカッシュマージでは、コンテンツ機能ブランチからではなく、新しいコミットを作成することによってこれを実行し、Git は新しい圧縮されたコミットが機能ブランチのコミットから生成されたという事実を追跡しないため、機能ブランチがマージされたとは考えません。
(強くお勧めしますないスカッシュ マージを使用します。標準のマージと同様に元のコミットを保持すると、Git の動作が向上します。