0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【原因gitじゃなかった】gitの挙動がなんか色々変になった〜修復までの話

Last updated at Posted at 2021-01-05

gitの操作に少し慣れてきた頃起こった、理解不能な挙動に関する記録です。

【環境】
・macOS Big Sur(ver11.1)
・ローカル上で仮想OSを起動、そこでコンテナを起動しルート直下にプロジェクトファイルを配置
・Vagrant 2.2.10

それは突然やってきた

ある日の作業中、gitやエディタ、動作確認中のwebアプリでこれまでできていた事ができなくなる、等の問題が次々に問題が発生。
色々起こりすぎてパニック状態の為、まずは状況をまとめることにしました。

起こった事一覧

####エディタのエクスプローラーと実際のプロジェクトが連動していない
ターミナルでファイルやフォルダを追加してもエディタのエクスプローラーに反映しない。
複数エディタで起こり、むしろFinderでも同じ状況。
特定のローカルリポジトリでのみ発生していて、それ以外のローカルリポジトリでは異常なし。
という事で環境起因ではない事はわかっている、、

<状況>
ローカルで作成したファイル→仮想環境→×コンテナ
ローカル×←仮想環境←コンテナで作成したファイル
※仮想環境でファイルを削除→コンテナはOK

仮想環境に問題があるのでは、と思いきや仮想環境作成の手順については何も変更していない。

####gitのログが消える
git logでさっきまで出力できていたコミットログが出なくなった。
5分前にgit logと叩いた時と今とでは結果が違う、的な。
もちろんその間ログ操作などは一切行っていない。
1度消えた後は同じような挙動は再現できなかった。

####ブランチが勝手に切り替わる
git checkout していないのにブランチが変わってしまう
事象を確認した時は、git logを叩く前とではブランチが違った。
もちろんその間ブランチ移動などは一切行っていない。
これも常に発生するわけではなくたまにそんな挙動をしていたのを見つけたので、意図的に再現するのが難しい。

前日までにやったこと

####ブランチの作成
作成した後そこでは実際に作業はせず、すぐにチェックアウト。

####OSのアップグレード
しばらく様子を見ていたmacOS Big Surのアップグレードを行った
その後特にエディタ編集に異常はなかったはず

今回の事象とは関係なさそう、、

直前にやったこと

####エディタのバージョンアップデート
phpstormを使用しているがOSのアップデートを行った為かアップデートのお知らせが走った為、実行。

####.ideaフォルダのgit管理削除
gitから削除しただけでローカルにあるファイルは触っていない。あやしい。

####プロジェクトファイルの整理
以前作成したブランチにチェックアウトしそこのファイルを一部削除、リポジトリ外から移動させてきた。あやしい。

上記のようにあやしい作業はいくつかあるが、ローカルとコンテナが同期しなくなってしまった事は、あやしい作業には関係なさそう。
となると原因がそれぞれ別にあるかも?

gitのブランチ移動やログについて調査

まずはこちらから。

####.gitディレクトリが削除やコピーで入れ替わった可能性がある
隠しファイルなので基本的に触っていないはずだけど、可能性の一つとして。
エディタのアップデート直前か直後にローカルリポジトリのディレクトリをリポジトリ外へバックアップしていたので、そこから.gitディレクトリを置換する。

結果改善しない。

####ローカルリポジトリが破損した?
参考:http://psychedelicnekopunch.com/archives/1009

この情報以外にも、ネット上には「リポジトリが壊れた」報告が多数。
リポジトリってそんなよく壊れるの?

壊れた際の対応としては、.gitディレクトリ内の各種ファイルの破損した箇所を修復がベストらしいが、git初心者的には.gitディレクトリの内容を一から学習しなければならないためちょっとそんな時間がない。
という事で参考urlに記載の通り、今あるローカルリポジトリを退避して、リモートリポジトリから作業中だったブランチをクローン。

git clone -b ブランチ名 git@github.com:リモートリポジトリ名.git ローカルリポジトリ名

これでgitのおかしい挙動は一掃できたはず、、ローカル上のコミットは消えてしまったけど、正常に動くようになったらまたやればいいので問題ない!

、、ローカルとコンテナの同期が改善してない、、、、、。

ローカルとコンテナ同期について調査

下記で確認。

docker inspect コンテナ名

仮想環境とコンテナは問題なくマウントできている。

        "Mounts": [
            {
                "Type": "bind",
                "Source": "/home/vagrant/share/app",
                "Destination": "/app",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }

では次に、仮想環境とローカルのマウントを確認、、、!?

%vagrant status
Current machine states:

web_app                  poweroff (virtualbox)

起動していないと。
でもコンテナ起動しているのに。今どういう状態?
起動しようとするとこう表示される。

%vagrant up
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 12345 is already in use
on the host machine.

To fix this, modify your current project's Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 22, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding. You could
try 'vagrant reload' (equivalent of running a halt followed by an up)
so vagrant can attempt to auto-correct this upon booting. Be warned
that any unsaved work might be lost.

翻訳

Vagrantは、このVMで指定されたポートを転送できません。
すでにリッスンしている他のアプリケーションと衝突します
これらのポートで。 12345への転送ポートはすでに使用されています
ホストマシン上。

これを修正するには、現在のプロジェクトのVagrantfileを変更して別のプロジェクトを使用します
港。例。「1234」は一意のホストポートに置き換えられます。

  config.vm.network:forwarded_port、ゲスト:22、ホスト:1234

時々、Vagrantはあなたのためにこれを自動修正しようとします。これで
ケースでは、Vagrantはできませんでした。これは通常、ゲストマシンが原因です
ポート転送の変更を許可しない状態にあります。あなたは出来る
'vagrant reload'を試してください(停止してからアップするのと同じです)
そのため、vagrantは起動時にこれを自動修正しようとすることができます。注意してください
保存されていない作業は失われる可能性があります。

VirtualBoxのコンソール上では電源オンと電源オフの状態のVMがひとつずつある。

####共有フォルダの状態を確認
公式よりコマンドを確認:
https://www.vagrantup.com/docs/cli/rsync-auto.html

VirtualBoxのコンソール上ではVM両方とも「共有フォルダ:1」になっていたけど、コマンドだとこう。

%vagrant rsync-auto
There are no paths to watch! This is either because you have no
synced folders using rsync, or any rsync synced folders you have
have specified `rsync_auto` to be false.

VirtualBoxとVagrantの状態が同期していない様子。
ん?

Vagrantfileを変更または移動した場合は、rsync-autoコマンドを再起動する必要があります。たとえば、同期されたフォルダをVagrantfileに追加したり、Vagrantfileを含むディレクトリを移動したりすると、rsync-auto コマンドは変更を取得しないか、奇妙な動作を開始する可能性があります。

これやったな

同期されたフォルダをVagrantfileに追加したり

結果のこれか。

奇妙な動作を開始する可能性があります。

####修正方法は?

このような変更を行う前に、オフrsync-autoにしてから再起動することをお勧めします 。

今回はもはや遅いけど、オフにする方法は下記が参考になった
https://qiita.com/ringo0321/items/aec4c543cce63e60a529

Vagrantfileのコードのフォルダ共有の箇所に、下記オプションを付けるとオフになるらしい。

disabled: true

####VirtualBoxで起動しているVMについて

vagrant upする前に整理しておこう。
今のリポジトリのVM(電源オフ状態)は下記で削除

vagrant destroy

するとVirtualBox上では電源オン状態だったVMの方が消えていった、、

もう一つの電源オフ状態のVMは、該当するリポジトリはすでに存在しない為、VirtualBox上で除去。

これで謎のVMたちの整理完了。
改めてVMとコンテナの起動を行い、ローカル→コンテナのファイル同期ができている事を確認し、そのファイルをgit add,commit後、ログもきちんと反映されている事を確認。やったー。

まとめ

vagrantのディレクトリ同期サービスの仕様にそぐわないディレクトリ移動を行ったことによって動作が不安定になってしまった。
(存在しないDockerfileによるVMがローカル上に存在してしまい、別のVMとディレクトリ共有する結果となりマウントが不安定な状態になったと思われる)
その状態でブランチを行き来したりコミットしたおかげで、.gitやコミットしたファイルが正しく同期されなかった可能性があり、その影響でgitの挙動がおかしくなっていた様子。
VM関連の問題があったディレクトリやインスタンスを整理した結果無事解決。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?