git stashスタックはリモートリポジトリにプッシュされますか？
私のstashスタックはremote repoにプッシュされますか？それとも完全に無視されますか？
サーバーのスペースを節約するために時々それをいくつか落とす傾向があるかどうかだけ私は興味があります。
いいえ。シシはローカルです。
$ man git stash：
作業ディレクトリとインデックスの現在の状態を記録したいが、クリーンな作業ディレクトリに戻りたい場合は、git stashを使用してください。このコマンドは、ローカルの変更を保存して、作業ディレクトリをHEADコミットに一致するように戻します。
しかし、私はそれらの多くをローカルに置いておきません。時間の経過とともにそれらを追跡できなくなり、やや役に立たなくなります。
原則として、いいえ。あなたcould必要に応じてプッシュします。
ここでは、プッシュ（および、さらに言えば、フェッチ）について説明します。これらは、「refspecs」に基づいて機能します。ここで、ローカル参照名、またはプッシュおよび特定のケースでは、未加工のコミットIDに名前を付け、さらにリモート参照にも名前を付けます。参照名。
では、参照名とは一体何なのでしょうか。
ほとんどの場合、masterなどのブランチ参照、またはOrigin/masterなどの「リモートブランチ」に名前を付けます。紛らわしいことに、gitが「リモートブランチ」と呼ぶのは、実際にはローカルエンティティであり、ブランチonリモートではなく、特別な名前のyourリポジトリ内のブランチです。
ブランチは実際にはrefs/heads/で始まる名前の単なる参照です。それは本当にほとんどすべてのブランチです。 （ブランチには他に1つ特別なことがあります。ブランチ自動移動で新しいコミットを作成したとき。つまり、masterブランチにいて、新しいコミットを作成した場合、gitは新しいコミットを指すようにrefs/heads/masterを更新します。）
「リモートブランチ」は、名前がrefs/remotes/で始まり、リモートの名前（通常はOrigin）を含む参照にすぎません。したがって、refs/remotes/Origin/masterは「リモートブランチ」です。ローカルエンティティ、your repo内の名前、gitが「masterがどこにあったかOrigin」を追跡するために使用します前回gitがOrigin "でチェックインしたとき。 Originをフェッチまたはプッシュするときはいつでも、1 gitは、 "向こう"にあるものに基づいてOrigin/branch名を更新します。
タグは単にrefs/tags/で始まる参照です。
通常、これらの接頭辞はすべて省略し、masterと書くだけで、refs/heads/masterのマスターブランチを意味し、Origin/masterはrefs/remotes/Origin/masterを意味し、v2.3はrefs/tags/v2.3を意味します。 Gitは自明なため、どちらが自動的かを判断します。正確なルールは gitrevisions で説明されています。 （厄介なことに、git checkoutとgit branchは常に gitrevisions ルールに正確に従うとは限りません。何かがブランチ名であることを知っているとき、彼らはただassumerefs/heads/の部分です。- その他 gitコマンドは説明どおりに機能します。）
stashスクリプトは、単にrefs/stashと綴られる参照を使用します。したがって、stash;と書いて、この参照に名前を付けることができます。 gitはそれがブランチでもリモートブランチでもタグでもないことを見つけ、最後にrefs/stashを使用して名前を解決します。2
...つまり、何を意味しますか？
これは、あなたが書いた場合、
$ git Push Origin stash:ssss
gitはstash（1つだけのstash）を見つけて、ssssという名前のリモート参照にプッシュしようとします。これはおそらく失敗します。ここで私がそれを試したときに何が起こったかです：
error: unable to Push to unqualified destination: ssss
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to Push some refs to 'ssh://[redacted]/tmp/t'
ちょうど楽しみのために、私は次のコマンドを試してみましたが、別のエラーが発生しました：
$ git Push Origin stash:refs/ssss
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 485 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: error: refusing to create funny ref 'refs/ssss' remotely
To ssh://[redacted]/tmp/t
! [remote rejected] stash -> refs/ssss (funny refname)
error: failed to Push some refs to 'ssh://[redacted]/tmp/t'
しかし、これはうまくいきました：
$ git Push Origin stash:refs/heads/ssss
今回は、リモートにssssという名前の新しいブランチを作成しました。リモートタグ（refs/tags/tagname）にプッシュすることもできます。
スタッシュはブランチやタグとしてはあまり意味がありませんが、1つであるかのようにプッシュできます。一度これを試してみると、リモートが知っているのは、いくつかのコミットオブジェクトとそれに関連するツリー、BLOBなどを送信していること、および「完全な」名前で「最も先端的な」コミットを格納する必要があることです。あなたが供給します。３ これが、たとえばリモートでタグを作成するために、生のコミットIDをプッシュできる理由です。
$ git Push af7ec93:refs/tags/foo
（もちろん、IDがaf7ec93で始まるコミットがあると仮定します）。
「スタッシュスタック」に関するもう1つの注意事項
「スタック」は、refs/stash参照の参照ログを使用して作成されます。 stash@{1}を記述する場合、これは同じ gitrevisions ルールを使用してcommit-IDに解決します。 git Pushを使用すると、有効なIDに解決されるすべてのものを使用できるため、これらをリモート名にプッシュすることもできます。しかし、おそらくそうすべきではありません。 refs/stashの下の最上位のstashアイテムと同じように、これらは通常のコミットとしてはあまり意味がありません。 （スタッシュはマージコミットとして内部的に保存されますが、その内容は奇妙にパッケージ化されており、通常のコミットとして使用しようとすると、あまり役に立たない結果になります。）
1これは1.8.2以降のgitでは文字通り当てはまります。ただし、古いバージョンのgitは、フェッチ時にリモートブランチの更新をスキップすることがあります。特に、git fetchがgit pullによって呼び出された場合はそうです。
2gitrevisions を参照すると、これも正確ではないことがわかります。stashがrefs/stashとして検出されますbeforeブランチ名を探します。
３git Pushは通常、フルネームを自動的に作成します。master、つまりrefs/heads/masterをプッシュする場合、これはブランチであることを認識しているため、git Push master:newbranchはリモート上にrefs/heads/newbranchを作成します。ただし、たとえばリモートでタグを作成するために、完全な名前を入力することもできます。空のローカル参照をプッシュしてremote-refを削除する場合、これは削除操作でも機能します（例：git Push :refs/tags/delete_me）。
bcmcfcはすでに言った のように、大量のスタッシュを保管することは悪い考えになる傾向があります。私が代わりに行うのは、大量のブランチを保持することです（いくつかのリモートで本当に保存したくない限り、プッシュを避けます）。これらには名前が付いているため、もう少し扱いやすくなっています（ただし、ほんの少しです）。 stashとブランチはどちらも単にコミット（特別なstashマージコミットまたは通常のコミット）を含む役割を果たしているだけなので、効率に違いはありません。ただし、スタッシュの代わりにブランチを使用する場合は、Push.defaultがすべてのブランチをプッシュしないように構成されていることを確認する必要があります。