Q&A
＞ 以前こちらのコマンド使用時に、「unstage」状態が取り除かれるだけでなく、ファイル自体も削除されてしまうといった問題が起きてしまいました。
改めて正しい箇所をcheckoutすれば問題ないのではないでしょうか？（それとも、Gitに一切コミットしていないファイルがあって、それは維持する必要がある、という状況でしょうか）
リモートリポジトリから、プルした際に、大量の変更履歴が取り込まれてしまいました。
PULLの直後に、git statusとすると、緑色の文字でファイルがかなりの数表示されておりました為、こちらは既にステージング状態であると判断しました。
その為、このまま、addしcommitすると大量の変更履歴のコミットができてしまうと判断し、一度unstageの状態にする為、git reset HEADとしました。
そうしますと、unstageに大量の変更履歴が追加されました。
この状態で、変更されたファイルはそのままに、「unstage」になっている大量の変更履歴を削除したいと考えています。
調べた限りですと、 git clean -f.こちらを行うと可能なようなのですが、実は、以前こちらのコマンド使用時に、「unstage」状態が取り除かれるだけでなく、ファイル自体も削除されてしまうといった問題が起きてしまいました。
今の状態ですと、リモートリポジトリにプッシュを行うと、大量の変更履歴がプッシュされてしまう為、なんとしても避けたいと考えています。
こちらの問題を解決する為、どなたかご助言頂けましたら幸いです。
回答1件
0
ベストアンサー
この状態で、変更されたファイルはそのままに、「unstage」になっている大量の変更履歴を削除したいと考えています。
このやりたいことそのものが矛盾しているようにも思えるのですが…
「他のコミットに同じ変更が存在する」というのでなければ、いまあるファイルの変更部分＝unstagedな変更履歴です。変更された箇所はそのまま、unstagedだけ消す、なんていう芸当はできません。
実現できることは、
- ローカルの変更をすべて破棄して、どこかのコミットと状態を揃える（ちょうど実現したい状態を持ったコミットがあるなら、そこに揃えることが可能です）
- 現在の状態をすべてステージ、コミットする
- 現在の状態を取捨選択して、必要分だけコミットする
のどれかです。
投稿2020/08/31 13:25
総合スコア145184
いちおうは、「コミットとファイルの状態が違っても無視させる」という手段も存在はするのですが、それをやるとGit管理から外れるのに等しくなるので、環境ごとに違えないといけない設定ファイルなどを除いて通常は用いません。
ご回答ありがとうございます。
前々から疑問であった点ではあるのですが、リモートの変更をローカルに取り込むということをした際に、ローカル側ではadd,commitを行わなければならないかと思います。
それを、また別の人が同じようにローカルに取り込むと同じようにコミット履歴が出来上がり、プッシュした際には、そのコミット履歴までリモートリポジトリに残ってしまいます。
こちらは、同じコミット履歴がリモートに残ったとしても問題はないのでしょうか?
> リモートの変更をローカルに取り込むということをした際に、ローカル側ではadd,commitを行わなければならないかと思います。
理解か間違っています。pullあるいはfetch＋（mergeまたはrebase）で取り込むものです。
（どのような手順で「リモートの変更をローカルに取り込む」作業を行っているのでしょうか？）
あ、勿論「git pull origin master」で変更履歴は取り込んでいます。
この状態で、「git status」とすると、取り込んだ変更履歴が、ステージング環境に存在しているといった状態になっています。
pullした際にコンフリクトしたのではありませんか？
（コンフリクトした場合は、辻褄が合うように修正してコミットする必要があります。この場合は、コミット履歴は増えてしかるべきものです）
（通常、pullの際に「add,commitを行」う必要はないです）
> pullした際にコンフリクトしたのではありませんか？
あ、なるほどです...
コンフリクトを修正した場合の変更履歴を、コミットするということですね...
仮にコンフリクトが起きなかった場合は、まぁその時は深く考えずコンフリクトがおきなかったんだなと、普通にコミットすれば良いですよね...
>(通常、pullの際に「add,commitを行」う必要はないです）
こちらですが、pullした際には、変更履歴が取り込まれて、「git status 」した際に、ステージングにファイルが追加されていたりしませんでしょうか?
> 仮にコンフリクトが起きなかった場合は、まぁその時は深く考えずコンフリクトがおきなかったんだなと、普通にコミットすれば良いですよね...
pull操作でコミットまで行われます。
うーん、何故か、「git pull origin master」を実行すると決まって、「git status」した際に、リモートの変更されたファイルがステージングに追加されているんですよね。。
必要なファイルをgitignoreし忘れているとか、ビルド成果をコミットしているために必ずそのファイルが違ってくるとか、そういう事はありませんか？
そして、「git commit -m ""」をすると、ステージングに追加されていたファイルが表示され、コミットされます。。
> 必要なファイルをgitignoreし忘れているとか、ビルド成果をコミットしているために必ずそのファイルが違ってくるとか、そういう事はありませんか？
実は今回、Djangoで開発していたのですが、local用の仮想環境の為の「env」フォルダを管理下にいれてしまっていたのですが、そこは関係しているのかもしれませんね。。
ただ、envフォルダ以外の普通のファイルもステージングに入っているので、正直もう良く分からない状態です。。。
とりあえずは、このまま止まっていたも仕方がないので、全て、add、commitし開発を続けたいと思います。
> ただ、envフォルダ以外の普通のファイルもステージングに入っているので、正直もう良く分からない状態です。。。
1つコンフリクトすれば、残りのファイルもステージングに位置することになります。
長々とご親切にご助言頂き、ありがとうございました。
>1つコンフリクトすれば、残りのファイルもステージングに位置することになります。
もしかしたら、最初のgitで管理するべきフォルダなどを間違えてしまったことが問題だったのかもしれませんね。。
あなたの回答
tips
プレビュー
