web-dev-qa-db-ja.com

git remote Prune –思ったほど枝刈りされたブランチを表示しませんでした

Manページから：

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つだけです。これらのブランチの一部は私によって作成され、一部は同僚によって作成されました。これは、そもそもこれらのブランチを正しく追跡していなかったことを示していますか？

gitversion-controlbranchgit-branchgit-remote
112
Felixyz

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

では、正確にgit remote Pruneは何をしますか？主なアイデア：ローカルブランチ（トラッキングブランチではない）はgit remote Pruneコマンドの影響を受けないため、手動で削除する必要があります。

さて、理解を深めるための実際の例：

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

  • 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はstaleブランチであり、削除する必要があります。
  5. refs/heads/featureはgit remote Pruneの参照を削除しないため、refs/heads/*を含む3つの参照があります。

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

（例とコメントからの有用な情報で更新）

187
max