私のチームは最近、ClearCase から Git に移行しました。一部のチーム メンバーは、ファイルのハイジャックに慣れています。これは、ClearCase では、追跡対象のファイルにプライベートな変更を加えることを意味し、誰とも共有するつもりのない変更を加えることを意味します。
ClearCase は、基本的に、Git の追加/コミットと同等の処理を実行するときにそのようなファイルを無視し、Git のプルと同等の処理を実行するときにそれらのファイルを上書きしません。
Gitに同等のものはありますか?
ClearCase の世界でも、これが良いワークフローだと言っているわけではないことに注意してください。「なぜそうしたいのか」に対する答えは、彼らが慣れ親しんでいるということです。
「 hijacked」に最も近いのは、無視する必要があるファイルを git インデックスに指定した場合
です:
git update-index --assume-unchanged -- afile.
ファイルはまだバージョン管理されていますが、ファイルに加えた変更は に表示されgit statusず、コミットされません (もちろん、プッシュされません)。
いつでも変更を加えてからコミットしないことができます。プル/マージ/コミット/チェックアウトすると、変更が「浮かび上がり」ます。それらを上書きするようなことをしようとすると (たとえば、同じファイルに触れる変更をマージする)、拒否されます。この時点でgit stash、変更を行い、操作を実行してgit stash (apply|pop)から、変更を復元できます。
これらの変更を実際にローカルにコミットし、他の誰とも共有したくない場合は、「実際の開発」が行われるブランチにリベースする (またはマージし続ける) ローカル ブランチでそれらを維持するのが最善の策だと思います。ローカルの変更を含むコミットを実際にプッシュしないように注意してください。