こちらのUdemyの講座を受講している際、タイトルのようなエラーに遭遇しました。 https://www.udemy.com/course/intro_git/learn/lecture/6449730#notes （3分29秒） ys@mbp intro_git % git push origin master ↓ error: src refspec master does not match any error: failed to push some refs to 'github.com:〇〇（GitHubのユーザー名）/intro_git.git' 結論 git push origin master ではなく git push origin main を使う ys@mbp intro_git % git push origin main ↓ Enumerating objects: 19, done. Counting objects: 100% (19/19), done. Delta compression using up to 8 threads Compressing objects: 100% (14/14), done. Writing objects: 100% (17/17), 1.66 KiB | 567.00 KiB/s, done. Total 17 (delta 4), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (4/4), done. To github.com:〇〇（GitHubのユーザー名）/intro_git.git 4817446..7f3dadd main -> main 参考サイト https://deepblue-ts.co.jp/git/git-push-error/

環境 この記事は以下の環境で動いています。 項目 値 CPU Core i5-8250U Windows 10 unity 2020.3(LTS) 概要 ROS講座でUnityのプログラムが出てきます。Unityのプログラムをgitで管理する方法を記します。またサンプルProjectをgitでダウンロードして使用する方法も解説します。 Unityのgit管理 github for unityのインストール Asset Storeで「github for unity」をダウンロードします。 PackageManagerで上記をImport 設定をする メニューバーの「Window」->「GitHub」をクリック 「setting」タブに移り、出てくるページの「Name」と「Email」に適当な値を入れます。この情報はcommitメッセージに入るだけで、githubの登録アドレスと違っても、実在しなくても大丈夫です。 初期化をする 「Initialize」タブに移り、「Initialize a git repository for this project」というボタンを押す。ここで.gitignoreなどが自動で作られて、それらのファイルのみのInitial commitが作られます。 「Assets」などのフォルダはまだコミットされていません。「Changes」タブに移って、一覧からcommitしたいファイル（全部チェックで大丈夫です）をチェックして、画面下部の「Commit Summary」と「Commit Description」を埋めて「commit to [master]」を押しましょう githubと連携する remote repositoryを作る githubの使用するアカウントで新たにリポジトリを作ります。 sshキーの登録 どうやらPCの「/c/Users/[user名]/.ssh/」にssh鍵が必要な見たいです。今回はgitbashを使いました。 gitbashを起動 ディレクトリ移動：cd ~/.ssh/ 鍵の作成： ssh-keygen.exe -t rsa（あとは指示に従って） ~/.ssh/id_rsa.pubをgithubに登録 リモートリポジトリの設定&ログインをする&Push Unityに戻ります リモートリポジトリの設定 メニューバーの「Window」->「GitHub」をクリック 出てくるウィンドウで「Setting」タブを開く 「Remote: origin」の欄にリポジトリのアドレスを入れる（例：git@github.com:project-srs/ros_lecture_unity_app.git） ログイン 画面右上の「Log In」を押す 出てくる画面で「Sign in with your blowser」を押す。 出てくる画面でgithubの連携のために認証をする pushをする ウィンドウ上部の「Push」を押します。 githubからcloneしたProjectを使用する 例えば当プロジェクトの「https://github.com/project-srs/ros_lecture_unity_app」を使用する場合の手順です。 リポジトリのclose 外部ツールでcloseする必要があります。今回はgitbashで~/に移動して「git clone git@github.com:project-srs/ros_lecture_unity_app.git」します。 Unity hubで開く Unity Hubを開き「リストに追加」を押して上記のディレクトリを開きます。 コメント Unity Teamを使って構成管理をするのがUnityの正式のようです。 昔はmetaファイルが隠しファイルかそうでないかの選択があったそうですが、今はなくなっています（.metaファイルが普通のファイルとして出来ます）またバイナリ形式かテキスト形式かを選択できるのですが、現在はデフォルトがテキスト形式のようです。 最初のコミット時点で500kBほどでした。最初に.gitattributeが設定されているのでgit LFSに対応していているようです（未確認ですが）。 参考 https://qiita.com/toRisouP/items/97c4cddcb735acde2f03 目次ページへのリンク ROS講座の目次へのリンク

この記事は新卒1年目 Advent Calendar 2021の2日目です。 概要 先輩から教えていただいた git rebase -i コマンドが非常に便利で、日頃から多用しています。 仕事で実際にやったことのあるケースをもとに、自分の使い方をご紹介します。 この記事で扱うコマンドは、以下の3つです。 edit reword fixup 対象読者 この記事は、以下のような方を対象読者と想定しています。 git rebase -i を完全に理解したい方 gitを使った開発の経験が浅い方 自分同様まだ開発の実務経験が浅い方 この記事の特徴 新卒1年目のアドカレで投稿する記事ということで、主に自分同様まだ実務経験の浅い方へ向けて書きました。 このコマンドを知らない頃の自分でも理解できるように、丁寧に書いてみたつもりです。 誰かの git rebase -i コマンドの理解を深めるお役に立てれば幸いです。 ケース別 git rebase -i この記事では、以下3つのケースで git rebase -i をどう使うかをご紹介します。 以前のコミットの内容を編集したい 以前のコミットのコミットメッセージのみ変更したい 複数のコミットをまとめたい 以前のコミットの内容を編集したい 実際にあったのは、以下のようなケースです。 「あ、さっきのコミットに、この内容も含めたいな」 「やべ、さっきのコミット、自分用のコメント残したままだった」 こんなときは edit を使います。 結論 git rebase -i HEAD^ pick → edit に変更して保存 1つ前のコミットに戻るので、そこで編集する git add (1つ前のコミットに含めたいもの) + git commit --amend git rebase --continue 具体例 コミット: add hoge hoge.txt + hoge + fuga 「hogeだけを入れたかったが、間違えてfugaも入れてしまった。fugaを消したい」 手順1. git rebase -i HEAD^ $ git rebase -i HEAD^ 手順2. pick → edit に変更して保存 - pick xxxxxxx add hoge + edit xxxxxxx add hoge # Rebase xxxxxx..xxxxxx onto xxxxxx (2 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # 手順3. 編集する hoge.txt hoge - fuga 手順4. git add + git commit --amend $ git add hoge.txt $ git commit --amend 手順5. git rebase --continue $ git rebase --continue これで完了です。 以前のコミットのコミットメッセージのみ変更したい 実際にあったのは、以下のようなケースです。 「さっきのコミットメッセージ、やっぱり違う表現の方がいいか」 「prefixを間違えてしまった、正しくせねば」 こんなときは reword を使います。 結論 git rebase -i HEAD^ pick → reword に変更して保存 コミットメッセージを変更して保存 具体例 コミット: add fuga hoge.txt + hoge 「hogeを追加したのに、間違えて、fugaを追加したというコミットメッセージにしてしまった」 手順1. git rebase -i HEAD^ $ git rebase -i HEAD^ 手順2. pick → reword に変更して保存 - pick xxxxxxx add fuga + reword xxxxxxx add fuga # Rebase xxxxxx..xxxxxx onto xxxxxx (2 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # 手順3. コミットメッセージを変更して保存 - add fuga + add hoge # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: xxxxxxxxxxxx # # interactive rebase in progress; onto xxxxxx # Last command done (1 command done): # reword xxxxxx add fuga # No commands remaining. # You are currently editing a commit while rebasing branch 'xxxxxxx' on 'xxxxxx'. # # Changes to be committed: # modified: hoge.txt # これで完了です。 複数のコミットをまとめたい 実際にあったのは、以下のようなケースです。 「細かくコミットしすぎたな、ちゃんと意味のある単位でまとめたい」 「ペア・モブプロやってて、ドライバーを交代するために無意味なコミット&プッシュをしまくった。作業が完了したので、PRを出すためキレイにまとめないとな」 こんなときは fixup を使います。 結論 git rebase -i HEAD~2 pick → fixup に変更して保存 具体例 コミット1: add hoge hoge.txt + hoge コミット2: add hoge_spec hoge_spec.txt + hoge test 「hogeのテスト追加は、hogeを追加したコミットにまとめて良さそうだ」 手順1. git rebase -i HEAD~2 $ git rebase -i HEAD~2 手順2. pick → fixup に変更して保存 pick xxxxxxx add hoge - pick xxxxxxx add hoge_spec + fixup xxxxxxx add hoge_spec # Rebase xxxxxx..xxxxxx onto xxxxxx (2 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # これで完了です。 コミット add hoge_spec の内容が add hoge に入ります。 なお、コミットメッセージは add hoge となります。 ちなみに fixup ではなく squash を使うと、コミットメッセージの編集もできます。 おわりに git rebase -i コマンドは非常に便利です。 この中でも、今回ご紹介した edit , reword , fixup は特に便利なコマンドです。 まだ使ったことのない方は、ぜひ一度お試しで使っていただき、その便利さを知っていただきたいです。

GitHubに公開鍵を設定しよう $ ssh-keygen -t rsa -b 4096 -C "メールアドレス" # -t 暗号化方式を指定 # -b 暗号化強度を指定 # -C コメントを設定 ・パスワード２回入力 公開鍵をクリップボードにコピーする $ pbcopy < pbcopy < /Users/yuya/.ssh/id_rsa.pub gitgubの設定画面を表示する 確認コマンドを入力　$ ssh -T git@github.com ※それでもできない場合は、cat ~/.ssh/id_rsa.pub をターミナルで実行して公開キーを貼り付ける。

はじめに SVNを最近使用しているが、Gitにも慣れておく必要があると常々感じている。今まではSourceTreeやTortoiseGitなどのGUIを使用していたが、そろそろCUIへの苦手意識を克服したい！！！ そこでここでは、(自分用に)ローカルリポジトリの作成からリモートリポジトリへのプッシュまでの基本的な流れについてまとめる。 学習目的 Git CUI苦手意識を取り除く コマンド操作になれる バージョン管理システムを用いた開発に慣れる（今後を意識して） 環境 MacOS BigSur ver11.6 Git:2.29.2 ターミナルを使用 Gitに慣れよう！！！ ここでは、以下のサイトを参考に進めていく 1.ローカルリポジトリの作成 ローカルリポジトリを作りたいディレクトリまで移動して、以下のコマンドを実行 //ディレクトリ作成 mkdir study //作成したディレクトリに移動 cd stduy //ローカルリポジトリの作成 git init Initialized empty Git repository in ディレクトリパス のようなメッセージが表示され、ディレクトリ内に.gitというディレクトリが作成されていればOK 2.ローカルリポジトリにコミットをする 1.で作成したディレクトリ内で適当にファイルを作成します。 例）index.html ここで一回git statusで現在の状況を確認します。 //git statusコマンドで状況を確認 git status //コマンド実行結果 $ git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) index.html nothing added to commit but untracked files present (use "git add" to track) Untraced filesのところに、index.htmlがあることがわかる。これはまだ追跡されていないファイルということである。 状況がわかったため、インデックスへ追加しコミットをする。 ※インデックスとは、コミット前に変更内容を一時的に保存する領域のこと。インデックスに追加されたファイルがコミットの対象となる。 //インデックスへ追加(追加するファイルを指定する場合) git add ファイル名 例）git add index.html //インデックスへ追加(カレントディレクトリにある全てのファイルを追加する場合) git add . //-mオプションで、コミットメッセージをつけることができる。 git commit -m コミットメッセージ 例）git commit -m "Add:first commit" コミットできているか確認するには、git logコマンドで確認できる。 $ git log commit コミットハッシュ (HEAD -> master) Author: ユーザー名　<メールアドレス> Date: Sat Nov 27 14:15:59 2021 +0900 Add:first commit 3.リモートリポジトリの作成とプッシュ ローカルリポジトリの変更をリモートリポジトリに反映させる。 まずは、リモートリポジトリを作成する。 Github上で作成する。作成したら、ローカルリポジトリとリモートリポジトリを紐づける。 Github上のリポジトリのページにある「Code>HTTPS」に記載のURL(https://github.com/ユーザ/○○.git)　 をコピーする。そして以下のコマンドを実行することで紐付けができる。 //ローカルとリモートのリポジトリを紐づける git remote add origin https://github.com/ユーザ/rakus.git //ローカルの内容をリモートリポジトリに反映させる git push origin master git push を行うとGithubのユーザー名とパスワードが求められる。 しかし、2021年8月よりパスワードの認証ではなくアクセストークンによる認証になった。 脆弱性防止のためとのこと。 remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. ということで、以下の記事を参考にアクセストークンを作成する。 作成できたら、再度pushを行いユーザー名と作成したアクセストークンを入力することでpush完了。 まとめ 今回は、GitCUIの初歩の初歩についてまとめた。 正直自宅でのちょっとした開発であれば、自分だけしか見ないのでバージョン管理するまでもないといえばそうである。ただ、いきなり業務で使うにはハードルが高いので、こういった間違えても問題ない自宅学習で慣れておくことが大事だと思う。 とりあえず、学習の一環でChromeの拡張機能でも作ってみようと思っているのでついでにめんどくさがらずgitで管理もしようと思います。 以上 参考

はじめに SVNを最近使用しているが、Gitにも慣れておく必要があると常々感じている。今まではSourceTreeやTortoiseGitなどのGUIを使用していたが、そろそろCUIへの苦手意識を克服したい！！！ そこでここでは、(自分用に)ローカルリポジトリの作成からリモートリポジトリへのプッシュまでの基本的な流れについてまとめる。 学習目的 Git CUI苦手意識を取り除く コマンド操作になれる バージョン管理システムを用いた開発に慣れる（今後を意識して） 環境 MacOS BigSur ver11.6 Git:2.29.2 ターミナルを使用 Gitに慣れよう！！！ ここでは、以下のサイトを参考に進めていく] Gitのインストールがまだの方はインストールを。 1.ローカルリポジトリの作成 ローカルリポジトリを作りたいディレクトリまで移動して、以下のコマンドを実行 //ディレクトリ作成 mkdir study //作成したディレクトリに移動 cd study //ローカルリポジトリの作成 git init Initialized empty Git repository in ディレクトリパス のようなメッセージが表示され、ディレクトリ内に.gitというディレクトリが作成されていればOK 2.ローカルリポジトリにコミットをする 1.で作成したディレクトリ内で適当にファイルを作成します。 例）index.html ここで一回git statusで現在の状況を確認します。 //git statusコマンドで状況を確認 git status //コマンド実行結果 $ git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) index.html nothing added to commit but untracked files present (use "git add" to track) Untraced filesのところに、index.htmlがあることがわかる。これはまだ追跡されていないファイルということである。 状況がわかったため、インデックスへ追加しコミットをする。 ※インデックスとは、コミット前に変更内容を一時的に保存する領域のこと。インデックスに追加されたファイルがコミットの対象となる。 //インデックスへ追加(追加するファイルを指定する場合) git add ファイル名 例）git add index.html //インデックスへ追加(カレントディレクトリにある全てのファイルを追加する場合) git add . //-mオプションで、コミットメッセージをつけることができる。 git commit -m コミットメッセージ 例）git commit -m "Add:first commit" コミットできているか確認するには、git logコマンドで確認できる。 $ git log commit コミットハッシュ (HEAD -> master) Author: ユーザー名　<メールアドレス> Date: Sat Nov 27 14:15:59 2021 +0900 Add:first commit 3.リモートリポジトリの作成とプッシュ ローカルリポジトリの変更をリモートリポジトリに反映させる。 まずは、リモートリポジトリを作成する。 Github上で作成する。作成したら、ローカルリポジトリとリモートリポジトリを紐づける。 Github上のリポジトリのページにある「Code>HTTPS」に記載のURL(https://github.com/ユーザ/○○.git)　 をコピーする。そして以下のコマンドを実行することで紐付けができる。 //ローカルとリモートのリポジトリを紐づける git remote add origin https://github.com/ユーザ/rakus.git //ローカルの内容をリモートリポジトリに反映させる git push origin master git push を行うとGithubのユーザー名とパスワードが求められる。 しかし、2021年8月よりパスワードの認証ではなくアクセストークンによる認証になった。 脆弱性防止のためとのこと。 remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. ということで、以下の記事を参考にアクセストークンを作成する。 作成できたら、再度pushを行いユーザー名と作成したアクセストークンを入力することでpush完了。 まとめ 今回は、GitCUIの初歩の初歩についてまとめた。 正直自宅でのちょっとした開発であれば、自分だけしか見ないのでバージョン管理するまでもないといえばそうである。ただ、いきなり業務で使うにはハードルが高いので、こういった間違えても問題ない自宅学習で慣れておくことが大事だと思う。 とりあえず、学習の一環でChromeの拡張機能でも作ってみようと思っているのでついでにめんどくさがらずgitで管理もしようと思います。 以上 参考

プロジェクトに整形ツール、静的解析ツールを導入 cd /プロジェクトのパス/ composer require --dev friendsofphp/php-cs-fixer composer require --dev phpmd/phpmd composer require --dev phpstan/phpstan composer update git commit 時に呼び出されるファイル pre-commit の用意 copy .git/hooks/pre-commit-sample .git/hooks/pre-commit pre-commit の編集 vi .git/hooks/pre-commit .git/hooks/pre-commit # 指定ブランチへのpush防止 while read local_ref local_sha1 remote_ref remote_sha1 do if [[ "${remote_ref##refs/heads/}" = "master" ]]; then echo "Do not push to master branch!!!" exit 1 fi done IS_ERROR=0 # PHPコード整形・静的解析 for FILE in `git diff-index --name-status $against -- | grep -E '^[AUM].*\.php$'| cut -c3-`; do if php -l $FILE; then # PHPコード整形 vendor/bin/php-cs-fixer fix $FILE # PHPコード静的解析 if ! vendor/bin/phpstan analyse $FILE; then IS_ERROR=1 fi # PHPコード静的解析 if ! vendor/bin/phpmd $FILE text ruleset.xml; then IS_ERROR=1 fi else IS_ERROR=1 fi done exit $IS_ERROR PHPMD 用 ruleset.xml の編集 vi ruleset.xml ruleset.xml <?xml version="1.0"?> <ruleset name="My first PHPMD rule set" xmlns="http://pmd.sf.net/ruleset/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd" xsi:noNamespaceSchemaLocation=" http://pmd.sf.net/ruleset_xml_schema.xsd"> <description>ルールセットの説明文</description> <!-- ルールの記述 --> <!-- 未使用の変数、メソッド等を検出 --> <rule ref="rulesets/unusedcode.xml" /> <!-- コードの複雑度チェック --> <rule ref="rulesets/codesize.xml/CyclomaticComplexity" /> <!-- メソッド名がキャメルケースかチェック --> <rule ref="rulesets/controversial.xml/CamelCaseMethodName" /> <!-- var_dump（）、print_r（）等を検出 --> <rule ref="rulesets/design.xml/DevelopmentCodeFragment" /> <!-- クラス/インターフェース定数名が大文字で定義されているかチェック --> <rule ref="rulesets/naming.xml/ConstantNamingConventions" /> </ruleset> ※ git commit 実行時に --no-verify をつけると呼び出されません。

1. 概要 Ruby on rails アプリ(開発環境の更新が本番環境に反映されるようGitHub Actions設定済み) にて、Gemfileに新機能を色々追加したり試したりした後 git push後にエラー発生・・時に自分が解決したやり方を記載 2.エラー内容/対処 Githubのactionsから最新ワークフローを確認した際に Deploy時エラーが発生していた 以下がエラー内容詳細 Run echo "$PRIVATE_KEY" > private_key && chmod 600 private_key Warning: Permanently added '***' (ECDSA) to the list of known hosts. From github.com:syokaturyou/sangoku * branch main -> FETCH_HEAD b1b89e5..4a8562f main -> origin/main error: Your local changes to the following files would be overwritten by merge: Gemfile.lock Please commit your changes or stash them before you merge. Aborting Error: Process completed with exit code 128. 本番環境のGemfile.lock　とpushした内容と食い違いがあるために起こったと考えられるため 本番環境(自分の場合aws EC2インスタンスを使用)のGemfile.lockを一旦削除 ※Gemfileが確認できるディレクトリに移動し以下を実行 [ec2-user@ip-〇-〇-〇-〇 アプリ名] rm Gemfile.lock →Gemfile.lock削除後には本番環境でgit pull origin main 実行 これで直ったと思い再度開発環境の更新内容をgit pushするも 今度はDeploy時エラーとして以下がgithubのactions上で発生していた。 Run echo "$PRIVATE_KEY" > private_key && chmod 600 private_key Warning: Permanently added '***' (ECDSA) to the list of known hosts. error: You have not concluded your merge (MERGE_HEAD exists). hint: Please, commit your changes before merging. fatal: Exiting because of unfinished merge. Error: Process completed with exit code 128. マージが完了しておらず、MERGE_HEADが存在しているために発生しているエラーと考えられる。 本番環境でgit pull した時には以下が発生していた。 [ec2-user@ip-〇-〇-〇-〇 アプリ名]$ git pull origin main error: You have not concluded your merge (MERGE_HEAD exists). hint: Please, commit your changes before merging. fatal: Exiting because of unfinished merge. 「hint: Please, commit your changes before merging.」の記載に従って 本番環境下で空コミット [ec2-user@ip-〇-〇-〇-〇 アプリ名]git commit --allow-empty -m "commitmessage" 空コミット後にgit pullを実行するとエラーは発生せず [ec2-user@ip-〇-〇-〇-〇 アプリ名]$ git pull origin main この状態で開発環境で修正内容をgit push すると本番環境でも正常更新された