114

マニュアルページから：

Deletes all stale tracking branches under <name>.
These stale branches have already been removed from the remote repository
referenced by <name>, but are still locally available in "remotes/<name>".

だから私は使用して枝の束を削除しました

git push origin :staleStuff

そして走った

git remote prune origin

ただし、プルーニングされたローカルブランチは1つだけでした。これらのブランチのいくつかは私によって作成され、いくつかは同僚によって作成されました。これは、そもそもこれらのブランチを正しく追跡していなかったことを示していますか？

4

1 に答える 1

191

を使用するgit push origin :staleStuffと、自動的に削除origin/staleStuffされるため、を実行するgit remote prune originと、他の誰かによって削除されたブランチが削除されました。git prune削除したブランチを削除するために、同僚が実行する必要がある可能性が高くなります。

では、正確には何をするのgit remote pruneでしょうか？主なアイデア：ローカルブランチ（トラッキングブランチではない）はgit remote pruneコマンドによって変更されないため、手動で削除する必要があります。

ここで、理解を深めるための実際の例を示します。

2つのブランチを持つリモートリポジトリがあります：masterとfeature。両方のブランチで作業していると仮定します。その結果、ローカルリポジトリにこれらの参照があります（混乱を避けるために完全な参照名が付けられています）。

  • refs/heads/master（短縮名master）
  • refs/heads/feature（短縮名feature）
  • refs/remotes/origin/master（短縮名origin/master）
  • refs/remotes/origin/feature（短縮名origin/feature）

さて、典型的なシナリオ：

  1. 他の開発者は、のすべての作業を終了し、それをリモートリポジトリfeatureにマージして、リモートリポジトリからブランチmasterを削除します。feature
  2. デフォルトでは、実行git fetch（またはgit pull）すると、ローカルリポジトリから参照が削除されないため、これら4つの参照すべてが引き続き保持されます。
  3. それらをクリーンアップして実行することにしましたgit remote prune origin。
  4. gitはfeatureブランチが存在しないことを検出するため、削除する必要refs/remotes/origin/featureのある古いブランチも検出します。
  5. これで、参照が削除されないrefs/heads/featureため、を含む3つの参照があります。git remote prunerefs/heads/*

branch.<branch_name>.merge設定パラメータにより、リモートトラッキングブランチに関連付けられているローカルブランチを識別することができます。このパラメーターは、（おそらくを除いてgit pull）何かが機能するために実際には必要ないため、欠落している可能性があります。

（コメントからの例と有用な情報で更新されました）

于 2010-10-28T08:27:42.683 に答える