棚上げとは、変更がyo後で作業できるように取っておかれることを意味します。
チェックインとは、変更がチームの他のメンバーに利用可能になり、ビルドに含まれ、最終的に出荷されることを意味します。
とても違う。棚付けは、タスクが完了していないときにコンテキストを切り替えるためのツールと考えてください。チェックインは、完了したことを意味します（少なくともその一部）。
行った変更を保存したいが、現在作業中の更新なしで展開したい他の変更（おそらくバグ修正）を行うために前のバージョンに戻る必要がある場合は、変更を保留します。通常はかなり定期的にチェックインしているので、これはまれなケースであることがわかります。たとえば、QAボックスにデプロイしたばかりで、すぐにエラーが見つかりました。その日の変更を保留して、QA展開バージョンに戻し、更新を行ってから、変更の保留を解除します。必要に応じて2つをマージします。それより長くなると、おそらく以前のバージョンをチェックして、代わりにブランチを探すことになるでしょう。しかし、棚がより有用であることが証明された他の経験を聞いてうれしいです。
他のユーザーはシェルフセットを検索してダウンロードできるため、レビューのためにコードを渡すのに適した方法です。ただし、すでにチェックアウトしているコードファイルをアンシェルフしようとするとエラーが発生するため、クリーンな環境を用意する必要があります。
チェックインできない大きな作業をしている場合は、1日の終わりに変更を棚上げすることがよくあります。そうすれば、PCが一晩で死んだ場合でも、サーバーにバックアップがあります。
ダーシーはそれを見つけます。また、棚は、ほとんどの場合公開されていないプライベートブランチと考えることもできます。チェックインされたコードを削除するのとは異なり、シェルフセットを完全に削除することもできます。シェルフセットを削除すると、永久に失われます。
上記の誰もがとても真実を言っており、私はそれから割り当てを学びました。
私の経験を追加するために、私が間違っている場合は私を訂正してください。プロジェクトには、開発者の各PCに固有の構成ファイルmypc.jsonがあります。通常、サーバーをローカルで実行するときにオーバーライドします。他のチームメンバーは、同じファイル名で構成が異なります。同じ名前でファイルを開発ブランチにプッシュすることは誰も望んでいません。だから私は棚を使ってこれらのタイプの変更を保存します。これらの構成が必要なときはいつでも、シェルフから変更を簡単に適用でき、環境構成がプロジェクトに戻ります。