What's New Qiita

20210106のGitに関する記事は9件です。

  • 投稿日：2021-01-06T23:47:14+09:00

git-flowとGitHub Flow

※私的メモ
git-flow,GitHub Flowは「Gir/GitHubのワークフロー」であり、厳密な規則ではない。
開発規模や人数によって適切なワークフローを用いることで、複数人でのバージョン管理システムの運用を円滑にすることができる。

git-flow

「git-flow」はVincent Driessen氏の「A successful Git branching model」を基にしたワークフロー。
他のワークフローと比べると大規模で複雑な構成になっている。
開発者が4人以上の場合に適している。

ブランチの種類と用途

メインブランチ

メインブランチには「master」と「develop」の2つのブランチがある。
これらのブランチは常に存在する。

  • master(main)

リリース済みのソースコードを管理する

  • develop

開発中のソースコードを管理する

サポートブランチ

タスクごとに「feature」「release」「hotfix」のいずれかのブランチを作成し、作業を行う。

  • feature
    機能実装や開発作業を行う

  • release
    リリース準備作業を行う

  • hotfix
    緊急の修正やバグ修正を行う

開発フローの例

at-it-git-15-002.jpg
1,developブランチを作成
master(main)ブランチからdevelopブランチを作成

2,機能を実装する
developブランチから、featureブランチを作成
機能実装後、コミットはfeatureブランチに対して行う

3,機能実装を完了する
featureブランチでの作業が完了したら、featureブランチをdevelopブランチにマージする
マージ完了後にfeatureブランチを削除する

4,リリース準備を始める
機能実装が終わりリリースできる状態になったら、developブランチからreleaseブランチを作成する

5,リリース準備を完了する
リリースブランチでの作業が完了したら、releaseブランチをmasterとdevelopブランチにマージする
マージ完了後にreleaseブランチを削除

6,緊急の修正作業を開始する
リリース後に緊急の修正作業が発生した場合は、masterブランチからhotfixブランチを作成し、修正作業を行う
マージ完了後にhotfixブランチを削除する

GitHub Flow

「GitHub Flow」は「GitHub」の開発で使用されているワークフローであり、「git-flow」に比べてシンプルな構成になっている。

開発人数が1~3人で1日に複数回デプロイを行うようなWebアプリケーションの開発に適している。

6つのルール

  • masterブランチは常にデプロイ可能である
  • 作業用ブランチをmasterから作成する
  • 作業用ブランチを定期的にプッシュする
  • プルリクエストを活用する
  • プルリクエストが承認されたらmasterへマージする
  • masterへのマージが完了したら直ちにデプロイを行う

開発フローの例

at-it-git-15-009.jpg
1,開発作業を行う
GitHub Flowでは、全てのブランチをmasterブランチから作成する
ブランチ名は、何の作業を行っているかが分かる名前にする。また、作業用ブランチは定期的にリモートリポジトリにプッシュするようにする。これによって、他の開発者の作業状況を把握できるようになる

2,Pull Requestを行う
作業用ブランチをmasterブランチへマージできる状態になったら、プルリクエストを作成して他の開発者にコードレビューを依頼する。そして、プルリクエストが承認されたらmasterへマージする

GitHub Flowを使用した開発では、プルリクエストを積極的に活用する。作業完了後のコードレビューだけではなく、作業途中の実装への助言を求める場合などにも使える

3,デプロイする
masterへのマージが完了したら直ちにデプロイを行う

まとめ

git-flowは4人以上での開発の際に用いる
GitHub Flowは1~3人での開発に用いる
マージの際はPull Requestをする(GitHub Flowの場合は作業途中でも有用なため積極的にする)

  • master(main)・・・ユーザーが使う製品
  • hotfix・・・バグ修正用ブランチ、masterからクローンしてくる
  • release・・・リリース用
  • develop・・・featureブランチの集まり
  • feature・・・作業ブランチ

参考

https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html#02

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T23:37:52+09:00

【GitHub】GitHubデスクトップに頼らずにリポジトリを作ってみただけ。

GitHubデスクトップって非常に便利ですよね。
某有名プログラミングスクールも一押しの逸品です。

しまいには、VSCodeですべて片付けられることも知ってしまったので
ますますgitコマンドから逃げまくっていた私。

でも、コマンドぶち込んで操作できた方がかっこいいじゃないですか。
というより、あらゆることにおいてそうなんですけど、GUIに頼り切っていると
今何が起こっているのか がまるで理解することができないんですよね。
しまいには、「あー大体Gitはコマンドで処理しますねー楽だし」と言われてしまったので
勉強せねば、ということでメモ。

「リモートリポジトリもCLIで作る」のは別に推奨ではないです。
GitHub公式が「とりあえずGihHubのwebページ上でリポジトリ作りなよ！」って言うので。

開発環境

MacOS Catalina 10.15.7
（他の要素は直接関係ないのですべて割愛）

今回の到達点

  • ローカルリポジトリをコマンドを駆使して作る
  • リモートリポジトリもコマンドを駆使して作り、ローカルリポジトリをpushする

なぜ、こんなことをしようと思ったか

GitHubデスクトップを使ったことがある人ならよくお分かりだと思いますが
たとえば、Railsでアプリを立ち上げた場合を例にとると

  1. Rails newでアプリを立ち上げる
  2. GitHubデスクトップのCurrent RepositoryからAdd Existing Repository〜で立ち上げたアプリを追加する
  3. Publish repositoryすると、勝手にリモートリポジトリも出来上がる

はずです。
そうすると、どうしても説明がつかないのが
「とりあえずGihHubのwebページ上でリポジトリ作りなよ！」の部分。

GitHubデスクトップを駆使すれば、この作業を行うことなくリモートリポジトリも生成されます。
ということは、Publish repositoryの裏では何かしらのコマンドが走っているはず。
それを解明したいと思いました。
何度も言いますが、別に参考にはなりません。趣味の世界です。

Mission1:ローカルリポジトリを作る

適当にディレクトリを作ってみる。ついでに、申し訳程度にREADME.mdを作る。

$ mkdir hogehoge
$ cd hogehoge
$ echo "# hogehoge" >> README.md

動作確認的なものを兼ねてGitHubデスクトップに反映させようと
いつも通りにAdd Existing Repositoryでリポジトリを追加しようとしたところ
Can't find hogehogeと、怒られてしまった。今までこんなのなかったじゃん…

理由：「ローカルリポジトリ」を作っていないから

簡単な話である。
Add Existing Repositoryは、直訳すれば「存在しているリポジトリを追加する」なので
ローカルリポジトリは既にできているはず。
そもそも、hogehogeディレクトリにはローカルディレクトリがなかった。

前述の通り、Rails等のフレームワーク経由でしかGitHubを使ったことがなかったので
気が付かなかったが、フレームワークでアプリを作成するときに、勝手にローカルリポジトリを作成してくれていた。

$ rails new sampleapp
　　　 create  
      create  README.md
      create  Rakefile
      create  .ruby-version
      create  config.ru
      create  .gitignore
      create  Gemfile
         run  git init from "."
Initialized empty Git repository in /Users/<ユーザー名>/projects/sampleapp/.git/
//以下略

フレームワークは偉大でした。

作ればいいんでしょ、作れば。

$ git init
Initialized empty Git repository in /Users/<ユーザー名>/hogehoge/.git/

はい、.gitっていうディレクトリができました。
さっきのRails newのときと同じようにInitialized empty Git repositoryってなりました。
これで、ローカルリポジトリの完成です。

Mission2:リモートリポジトリを作る

今回のメインディッシュ。
ここを進めることができれば、きっと当初の疑問「GitHubデスクトップが何してくれてるのか」が分かるような気がする。

とりあえず通例儀式。

$ git add .
$ git commit -m "first commit"
[master (root-commit) 89c1b84] first-commit
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

ここで、そもそも今の時点でリモートリポジトリって存在するの？たぶんしないよね？を確認。

$ git remote -v
//しかし何も起こらない。やっぱり何もないようだ。

$git remote add origin git@github.com:<GitHubのユーザー名>/hogehoge.git

リモートリポジトリはgithub上に設定するよって宣言。
originは、リポジトリの場所を表すワード。

念のため、リモートリポジトリの所在を確認。

$ git remote -v
origin  git@github.com:<ユーザー名>/hogehoge.git (fetch)
origin  git@github.com:<ユーザー名>/hogehoge.git (push)

あとはpushすれば完全勝利。楽勝。

$ git push -u origin main
ERROR: Repository not found.
fatal: Could not read from remote repository.

!?
リポジトリがない…だと…？事は単純ではなかった。

GitHub CLIの導入

GitHub CLIという、GitHuｂのコマンドラインツールが存在するようだ。（gitCLIとは別物）
GitHub CLI公式
ここに書いてある通り、Homebrewで導入。

初めて使うときには

$ gh auth login

とコマンドを叩き、GitHubの認証を通さないといけない。
その際に、いくつか質問されるので、適当に回答すれば良い。
? What account do you want to log into?（何のアカウントをログインさせたいの？）
→私は、GitHub.comにログインしたいんです。
? How would you like to authenticate?（どうやって認証通したい？）
→よく分からないのでLogin with a web browserでいいです。

! First copy your one-time code: 0E7C-xxxx
- Press Enter to open github.com in your browser...
（Enterキー押したらブラウザ開くから、このワンタイムパスワード入力してね）
→はい分かりましたGitHub様。

指示通りに認証を通した後に、HTTPSかSSHのどちらをデフォルトのプロトコルにするかを問われます。
私はSSHを設定しました。

これで、ようやくGitHub CLIを使えるようになりました。

Mission2':リモートリポジトリを作る（再）

$ gh repo create

リポジトリ名がカレントディレクトリであれば、これだけ。
リポジトリ名はカレントディレクトリと同じ名前でいいですか？って丁寧に聞いてくれる。

$ gh repo create hogehoge

のように、明示的にリポジトリ名を付けることも可能。
このとき、webページで作成する時と同じように、公開設定も選択できます。

Mission2'-2:リモートリポジトリにpushする

先人たちが散々情報を出してくださっているので特筆すべきことはありません。

$ git push -u origin main
To github.com:<ユーザー名>/hogehoge.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.

ようやくできた〜

まとめ

素直にGitHubのwebページでリモートリポジトリを作って
ローカルリポジトリをpushする方が楽。

参考文献

GitHub CLI公式
ucan-lab様【超入門】20分でLaravel開発環境を爆速構築するDockerハンズオン
↑git作業をコマンドで行うことを前提としたハンズオンの為、今回の記事作成のきっかけを与えてくださった記事です。
Gitコマンド関連は、星の数ほど記事があるので各々ご参照ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T16:48:54+09:00

Gitでpushしてしまったcommitを削除するための方法

きっかけ

gitを使い始めて一ヶ月ほど経った日に、ふとcommitした情報を消すためにはどうしたら良いのだろう、と思い立ったのがきっかけ。今までは、間違えてPushした時は、その上から上書きしていたが、消す方法も知るためにメモ。

結論

revertをする。（任意でDiscardもすべし。）

過程

git hub desctop内の左上にあるHistoryをクリック。
そして、消したいコミットを選択し、右クリックをする。
すると　Revert Changes in Commit　という文章が一番上に出てくるので、ポチッとクリック。
そして、Pushをすれば終了。

注意すべき点

RevertをしてもHistoryには履歴としては残るため、ぱっと見には、本当に削除できたのかが分からない。
完全に削除したいときには、Pushした後に、右クリックをして、discard　をクリックすれば完全に消える。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T16:18:38+09:00

cloneしてきたファイルを自分のリポジトリにpushする際のエラー解決法

起きたこと

他の人のgitリポジトリからクローンしたものを編集し、自分のリポジトリにpushしようとしたところ、以下のエラーが出ました。

error: src refspec master does not match any
error: failed to push some refs to 'git@github.com:~~~'

原因

以下のコマンドで原因が分かりました。

ターミナル
$ git remote -v

↓

origin  git@github.com:クローンしてきたリポジトリ (fetch)
origin  git@github.com:クローンしてきたリポジトリ (push)

リモートリポジトリがクローンしたところのままになっていました。
クローンしたままのファイルをそのままpushしようとすると、push先が自分のリポジトリではなく、元々のリポジトリにpushしようとするためエラーが発生します。

解決法

自分のリポジトリのURLを指定してpushすれば良い

ターミナル
$ git push （自分のリポジトリのURL） main
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T09:48:29+09:00

機密データをリポジトリから削除する

Git リポジトリへのパスワードや SSH キーといった機密データをコミットする場合、そのデータを履歴から削除することができます。 不要なファイルをリポジトリの履歴から完全に削除するには、git filter-branch コマンドと BFG Repo-Cleaner は、リポジトリの履歴を書き換えます。

ここにはgit filter-branchを使ってすべてのbranchesとtagsの履歴を削除するスクリプトです。

#!/bin/bash

branches=(master 1.0.0 1.0.1 ...)
key_file="file or path will be deleted"
for br in "${branches[@]}"; do
    echo $br
    git checkout "$br"
    git filter-branch --force --index-filter "git rm --cached --ignore-unmatch $key_file" --prune-empty --tag-name-filter cat
    git add . && git commit -m "delete Sensitive Data" && git push origin --force --all
done

git push origin --force --tags

参照

  1. 機密データをリポジトリから削除する
  2. ファイルをリポジトリの履歴から削除する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T01:36:41+09:00

openframeworkプロジェクトがバグった時の最終手段案

何があったのか

openframeworksでアプリの開発を進めていたのですが、その際にずっと普通にデバッグできていたのに、ある時から急に

/usr/bin/codesign failed with exit code 1

と言うエラーが出て、ビルドできなくなるようになりました。最初はDebugは無理だけどReleaseなら以前と同じようにビルドできる状態だったのですが、またしばらくするとReleaseの方もビルドできないようになってしまって、開発が進められないようになりました。

ネット上で検索したところいろいろな解決策が見つかりました。主には解決策は以下のような感じらしいです。

  • キーチェーンアクセスのログインチェーンのロック→アンロックを繰り返し行う
  • /Users/hoge/Library/Developer/Xcode/DerivedData/のデータを削除する
  • xcodeでサインインしてプロファイルを更新
  • シンプルに再起動

など色々見つかりましたが、結局僕はどれもうまくいきませんでした。キーチェーンアクセスアプリを開くこと自体初めてで（俺は後でちゃんと調べます...）、ここで何が行われているのかもよくわかっていなかったので、もしかしたら惜しいところまで行ってたのかもしれません。
が、どちらにせよ1時間ほど調べても解決に至らず、僕のフラストレーションがMaxに達してしまったので、僕的強行突破に出たところうまく行ったので解決策の一つとして共有します。

Githubからコードをクローンしてくる

僕はこのプロジェクトをGit管理していたので、対応するGithubからプロジェクトがバグる直前の状態をダウンロードし、そのプロジェクトをopenframeworksのappsフォルダに配置し、ビルドしたところ、なんとうまくいきました！！でもなんで？？

どこに問題があったのだろう。openframeworksもxcodeもついこの間触り始めたばかりで、内部のカラクリが全くわかっていないので、、結局原因がわからなかった。。わかる人いたら教えてください。

結論

Git管理は絶対しましょう

参考リンク

https://qiita.com/b_a_a_d_o/items/859fc91e45835773ca71

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T00:41:54+09:00

[備忘録] iCloud上で作業すると痛い目にあう話

絶対にiCloud上でコードを管理するな！！！

iCloud上のディレクトリをgit管理していると，以下のようにバージョンファイルが勝手に作成されてしまうことがある．これは，iCloud上で作業することで発生するので，iCloud上では作業しないようにしよう．

この問題の解決方法

もうすでに，バージョンファイルが作成されてしまっていることに気づかずにコミットしてしまった場合は，バージョンファイルをgitの管理対象から外す必要がある．そして，ついでにバージョンファイルも消す．

手順

  1. iCloudからローカル環境に作業ディレクトリを移す．
  2. ローカルに移動した作業ディレクトリでバージョンファイルを管理対象から消し，存在自体も消す．
  3. コミットしてプッシュ

バージョンファイルの削除について

インデックスにキャッシュされている（管理対象となっている）ファイル一覧は以下で取得できる．この中にバージョンファイルが入っていることを確認する．

git ls-files

上記のコマンドで出力されたファイルを一旦ファイル出力する．例えば以下のように．

git ls-files > ls-files.txt

出力したファイルの中から，バージョンファイルを抜き出し，バージョンファイルとオリジナルファイルの内容が同じであればバージョンファイルは心置きなく消していいことになる．内容が異なっている場合のみ，中身を確認して消すべきかそうでないかを確認する必要がある．
そのため，消しても良いファイル一覧を取得するプログラムを作成する．例えば以下のように．
（バージョンファイルは間にスペースがあるため少し面倒．ファイル出力するときに，一つのファイルとして表現するためにクォーティングする必要がある．）

grouping.py
import re
from typing import Optional, Tuple
import filecmp

with open("ls-files.txt") as f:
    files = f.readlines()

pattern = r"(^.+)(\s[0-9]+)(.*$)"
pattern = re.compile(pattern)

def split_file_name(filename: str) -> Optional[Tuple[str, str, str]]:
    m = pattern.match(filename)
    if m is None:
        return None
    prefix, version, suffix = m.groups()
    return prefix, version, suffix

splited = [split_file_name(file) for file in files]

versioned = list(filter(lambda s: s is not None, splited))

versioned_dict = {}
for file in versioned:
    key = (file[0],file[2])
    if key not in versioned_dict:
        versioned_dict[key] = []
    versioned_dict[key].append(file)

# rm_files(消しても良いファイル達), save_dict（中身を確認するファイル達）の作成
rm_files = []
save_dict = {}

keys = versioned_dict.keys()
for key in keys:
    ori_file = "".join(key)
    for sp in versioned_dict[key]:
        ver_file = "".join(sp)

        # ファイルの比較
        if filecmp.cmp(ori_file, ver_file):
            rm_files.append(ver_file)
        else:
            if key not in save_dict:
                save_dict[key] = []
            save_dict[key].append(ver_file)

# 消しても良いファイル一覧をテキストファイルとして出力
with open("rm.txt", "w") as f:
    for file in rm_files:
        f.write('\"{}\"'.format(file) + " ")

上記のようなプログラムで消しても良いファイル一覧が取得できたら，それらのファイルをgit管理対象から外し，存在自体も削除する．以下のように．

eval git rm $(cat rm.txt)

shellの解釈の順番の都合によりevalが必要.

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T00:41:54+09:00

[備忘録] iCloud上のディレクトリをgit管理すると痛い目にあう話

絶対にiCloud上でコードを管理するな！！！

iCloud上のディレクトリをgit管理していると，以下のようにバージョンファイルが勝手に作成されてしまうことがある．これは，iCloud上で作業することで発生するので，iCloud上では作業しないようにしよう．

この問題の解決方法

もうすでに，バージョンファイルが作成されてしまっていることに気づかずにコミットしてしまった場合は，バージョンファイルをgitの管理対象から外す必要がある．そして，ついでにバージョンファイルも消す．

手順

  1. iCloudからローカル環境に作業ディレクトリを移す．
  2. ローカルに移動した作業ディレクトリでバージョンファイルを管理対象から消し，存在自体も消す．
  3. コミットしてプッシュ

バージョンファイルの削除について

インデックスにキャッシュされている（管理対象となっている）ファイル一覧は以下で取得できる．この中にバージョンファイルが入っていることを確認する．

git ls-files

上記のコマンドで出力されたファイルを一旦ファイル出力する．例えば以下のように．

git ls-files > ls-files.txt

出力したファイルの中から，バージョンファイルを抜き出し，バージョンファイルとオリジナルファイルの内容が同じであればバージョンファイルは心置きなく消していいことになる．内容が異なっている場合のみ，中身を確認して消すべきかそうでないかを確認する必要がある．
そのため，消しても良いファイル一覧を取得するプログラムを作成する．例えば以下のように．
（バージョンファイルは間にスペースがあるため少し面倒．ファイル出力するときに，一つのファイルとして表現するためにクォーティングする必要がある．）

grouping.py
import re
from typing import Optional, Tuple
import filecmp

with open("ls-files.txt") as f:
    files = f.readlines()

pattern = r"(^.+)(\s[0-9]+)(.*$)"
pattern = re.compile(pattern)

def split_file_name(filename: str) -> Optional[Tuple[str, str, str]]:
    m = pattern.match(filename)
    if m is None:
        return None
    prefix, version, suffix = m.groups()
    return prefix, version, suffix

splited = [split_file_name(file) for file in files]

versioned = list(filter(lambda s: s is not None, splited))

versioned_dict = {}
for file in versioned:
    key = (file[0],file[2])
    if key not in versioned_dict:
        versioned_dict[key] = []
    versioned_dict[key].append(file)

# rm_files(消しても良いファイル達), save_dict（中身を確認するファイル達）の作成
rm_files = []
save_dict = {}

keys = versioned_dict.keys()
for key in keys:
    ori_file = "".join(key)
    for sp in versioned_dict[key]:
        ver_file = "".join(sp)

        # ファイルの比較
        if filecmp.cmp(ori_file, ver_file):
            rm_files.append(ver_file)
        else:
            if key not in save_dict:
                save_dict[key] = []
            save_dict[key].append(ver_file)

# 消しても良いファイル一覧をテキストファイルとして出力
with open("rm.txt", "w") as f:
    for file in rm_files:
        f.write('\"{}\"'.format(file) + " ")

上記のようなプログラムで消しても良いファイル一覧が取得できたら，それらのファイルをgit管理対象から外し，存在自体も削除する．以下のように．

eval git rm $(cat rm.txt)

shellの解釈の順番の都合によりevalが必要.

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-06T00:24:24+09:00

【原因gitじゃなかった】gitのローカルリポジトリで起きた理解不能な事象〜修復までの話

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両方とも「共有フォルダ：１」になっていたけど、コマンドだとこう。

%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関連の問題があったディレクトリやインスタンスを整理した結果無事解決。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧