はじめに 本記事は、GitHubにてLGTMにならず、修正となった場合の対処方法となります。 私が理解していなかった部分で、そのためかなりの時間の要してしまいましたので アウトプット、備忘録として記録いたします。 何を理解していなかったのか レビュアーからLGTMが貰えず、こちらで修正し、 再度レビュアーに確認依頼する流れです。 そもそものGitHubのルールに沿った開発の流れ ①masterブランチから`ブランチを切る`。 ②コードを記述し、都度`commit`する。 ③commit後、`push`する。 ④`pull requestを作成`する。 ⑤レビュアーへ`確認`依頼する。 ⑥レビュアーが作業者に対して`修正`依頼をする。 `⑦作業者にてコードを修正する。` ⑧修正後、無事に`LGTM`となる。 ⑨`merge`する。 ⑩リモートリポジトリからローカルリポジトリへ`pull`する。 何を理解していなかったか 当時の私の話です。 ⑦にてLGTMとならなかったため、修正が必要になりました。 その際に、修正後はどうやってレビュアーに確認依頼すればいいのか、 全くわからず、再度①から実行しなければならないと勘違いしており、 レビュアーに確認依頼するところまで辿り着けず、 モヤモヤしていました。 結論 【⑦にて修正となった場合】 ①コードを`修正` ②修正箇所について、`再度commit`する。 この時、commit名は「修正」などと分かり易く。 ③`再度push`する。 ④`再度確認依頼`をする。 これで以上です。 pull requestは既に作成されているため、 再度pull requestを作成する必要があるという認識が全くできていなかったことが原因でした。 こんなことに何度もエラーが出てしまったりしていました。 終わり 私含めて初学者の方は、 GitHubを使いこなすのに少々手こずってしまい、 同じような悩みを抱えてしまう方もいると感じています。 しかし、GitHubという機能は、 働く上で、必ず身につけなければならないものだと確信しています。 今、失敗できたことをプラスに捉え、 引き続き頑張りましょう！！

My Profile プログラミング学習歴②ヶ月目のアカウントです！ プログラミングスクールで学んだ内容や自分が躓いた箇所等のアウトプットの為に発信しています。 また、プログラミング初学者の方にわかりやすく、簡潔にまとめて情報共有できればと考えています。 もし、投稿した記事の中に誤り等ございましたら、コメント欄でご教授いただけると幸いです。　 対象者 チーム開発でのGitの使い方を学びたい方 Branchの作成に関して知りたい方 目的 Branch作成をして作業場を分けて開発できるようにすること 実際の手順と実例 0.前回までの流れ 1.Branchって、、、？ Branchとは木の枝のこと。ブランチをうまく使って異なる作業を並行して進めることができます。 機能の追加やバグ修正を本番の環境ではなく、作業場となるBranchを準備して作業することで、不具合等をなくしていきます。 2.実際のTerminalでのコマンド mainBranchから新しいBranchを作ります $ git 　checkout -b develop $ git branch master *develop *がついている方が現在作業しているBranchになります。 上記のように本番環境になるmainでの作業は行わずに、作業後の変更点やバグ修正をpushするdevelopブランチを用意しました。 ⚠ブランチは機能・タスク・バグごとに切る（作成する）こと！！ 3.作成したBranchをからコミットする 空コミットとは.... 新規ファイルや修正ファイルがなくともコミットできる 下記ではまだ何も変更してない上に、チームメンバーがBranchを確認するために空コミットします git add =A これはオプション:-A = git add . + git add -uのあわせ技 新規作成、編集、削除したファイルの変更を追加する $ git commit --allow-empty -m "コミットメッセージ" --allow-emptyが空コミット部分です。 リモートリポジトリにpushする $ git push origin develop 4.統合Branch　をメンバーに反映する ここから下はチーム開発のための作業です。 上記までを代表が実施し、下記をメンバーが実施します. 今回のdevelopのような立ち位置のBranchを統合ブランチといいます。いつも最新の状態に保っておくためのブランチで、安定した状態を保って置くことが鉄則です。 機能追加やバグ修正といったあるタスクを行うブランチをトピックブランチといいます。ここでは(maseterやdevelop)から分岐させ、ブランチ名をはっきりとどんな作業を実施したかわかるようにします。 $ cd アプリケーション $ git checkout -b develop $ git pull origin develop 筆者ははじめてのチーム開発でトピックブランチを使わないで実装を行ったのですが、結論としてタスクごとに分けるべきです。理由としては上記にある通り、名前で判断できず、メンバーがやっていることがブラックボックス化してしまいました。。。 必ずこの作業を実施すべきです！

はじめに gitのコマンドについて、自分の理解度を確認する意味も含めて、まとめたいと思います。 git初心者のため、内容に誤りや補足事項等ございましたら、お気軽にご指摘お願いします。 リポジトリ作成からコミットするまで 1. リポジトリを初期化する リポジトリ(repository)とは、ソースコードや変更履歴、コメントなどを一括して保管する場所のこと。 リポジトリには、自分のPC上に作る「ローカルリポジトリ」と、GithubなどのWebサービス上に作る「リモートリポジトリ」がある。 まず、ローカルリポジトリを初期化(initialize)する。 必ずとも実行が必須ではないが、実行する癖をつけておくと良い。 $git init 2. プロジェクトのファイルをステージングエリアに追加する。 ファイルに何かしらの変更を加えたら、まずはそのファイルをステージングエリアへ追加する。 ステージングエリアとは、リポジトリにコミットするファイルを、一時的に置いておくためのエリアのこと。 基本的に、git addするときは常に-Aオプションをつけるようにする。 -A : untracked状態のファイルをすべてステージングエリアに追加するオプション ただし、.gitignoreに記載されているパターンにファイル名がマッチする場合、 そのファイルは追加されない。 $git add -A 3.　ステージングエリアのファイルをローカルリポジトリに反映させる（コミットする） 変更したファイルを一旦ステージングエリアに追加後、自身のローカルリポジトリに変更を反映させる。 -mフラグを使うと、コミットメッセージをコマンドラインで直接指定できる。 $git commit -m "コメント” 4.　リモートレポジトリ(github)に変更を反映させる 自身のローカルリポジトリの変更を、リモートリポジトリへ反映させる。 最初のコマンドは、GithubをリポジトリのoriginとしてGitの設定ファイルに追加するためのもの。 実行する前に、予めGithubでリポジトリを作成しておく必要があり、 リポジトリを作成した後、最初の１回のみ、このコマンドを実行する必要がある。 次のコマンドで、ローカルのリポジトリをリモートのoriginにプッシュしている。 ２回目以降は、git pushでコミットできる。 git remote add origin https://github.com/<Githubのアカウント名>/<リポジトリ名>.git git push -u origin master 以上がローカルリポジトリを作成してから、リモートリポジトリにプッシュするまでの一連の流れとなる。 ２回目以降は、git add -Aから始めればよい。 branchを作成してからプッシュするまで 1. branch(ブランチ)を作成する branchとは、元のリポジトリのコピーを作成し、元のファイルを変更せず、プログラムの編集や追加を行うことができる機能のこと。 ここでは、ローカルリポジトリのmasterブランチからtestブランチを作成し、 リモートリポジトリにプッシュするまでをやってみる。 方法1では、最初のコマンドで指定の名前のブランチを作成する。その後、指定したブランチに移動する。 方法２では、git checkout -b ブランチ名を用いることで、新しくブランチを作成し、そのブランチへ移動することを同時に行う。 方法１ $git branch test $git checkout test 方法２ $git checkout -b test 2. 全てのローカルブランチを一覧表示する 現在のローカルリポジトリの全てのブランチを表示させる。 *がついているブランチが、現在使用中のブランチであることを表します。 $git branch * test master ブランチが切り替わっていることを確認したので、作業を実施する。 今回は、testブランチでREADME.mdを変更してみました。 3. ブランチの状態を確認する 変更が加えられたファイルを表示する。 $git status On branch test Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: README.md no changes added to commit (use "git add" and/or "git commit -a") 4. 変更点を確認する 編集した箇所と直前にコミットした内容の差分を表示する。 $git diff diff --git a/README.md b/README.md index 7f6ced6..c20cc1c 100644 --- a/README.md +++ b/README.md ~途中省略~ （END） 5. 変更点をローカルリポジトリにコミットする 変更に問題なければ、コミットする。 その際、git add -A＆git commit -m "コメント"でコミットしても良いが、 git commitには、現存する全てのファイルの変更点を一括でコミットする-aオプションがある。 今回はこれを使って、コミットしてみる。 ただし、最後にコミットした後に新しくファイルを追加した場合は、 git addでバージョン管理下に置く必要がある。 $git commit -a -m "Improve the README file" 6. リモートリポジトリにプッシュする コミットした内容を、Githubへプッシュする。 共同開発の場合、masterを不用意に変更しない方がいいため、 リモートリポジトリのtestブランチへプッシュします。 $git push origin test 以上がローカルリポジトリでブランチを作成し、リモートリポジトリにプッシュするまで一連の流れになる。 リモートリポジトリのmasterへプッシュするまで 1. リモートリポジトとローカルリポジトリを同期する 共同開発している場合、リモートリポジトリが共通で使われるため、 自分が作業中に他の人がリモートリポジトリのmasterブランチを更新している可能性がある。 そのため、リモートリポジトリのmasterブランチとローカルリポジトリのmasterブランチを同期し、 ローカルリポジトリのmasterを最新の状態にしておく必要がある。 方法１では、git fetchでリモートリポジトリのmasterブランチの最新状態を取得して、 git mergeで取得した状態をローカルリポジトリのmasterブランチに反映させる。 なお、方法２のgit pullは、git fetchとgit mergeを同時に行ってくれるが、 予期せぬ動作をする可能性もあるため、初心者は分けて行うのが良いかも。 $git checkout master 方法1 $git fetch origin master $git merge origin/master 方法２ $git pull origin master 2. ブランチで変更した内容を、masterに反映させる ブランチで変更した内容をmasterブランチにmergeする。 $git merge test 3. ブランチを削除する mergeした後、ブランチが不要になった場合には、ブランチを削除する。削除が必須ではない。 また、ブランチの変更を保存せず、ブランチごと削除するには、git branch -D ブランチ名を用いる。 $git branch -d test 4. リモートリポジトリへプッシュする ローカルリポジトリのmasterブランチの内容をリモートブランチにプッシュする。 $git push 以上、リモートリポジトリのmasterへプッシュするまでの一連の流れになります。 参考 Ruby on Rails チュートリアル https://qiita.com/yukibe/items/9ef9d54f2e7d53cfb51c https://git-scm.com/book/ja/v2

はじめに push するときにパスワードを求められるのは面倒くさい・・。 もし同じような挙動が起きている方は簡単に改善できるのでお試しください。 対象読者 Git, GitHub, GitLab 利用者 Git操作に慣れていない方 目次 はじめに 対象読者 目次 原因 解決策 確認方法 解決方法 ※URLってどれ？ 設定の確認 参考文献 原因 HTTPS通信だと毎回求められるようです。 全然意識していなかった・・。 解決策 確認方法 出力結果でoriginのあとに続くものが ssh なら大丈夫。 https から始まっていると Https通信 を使用している。 ターミナル # コマンド git remote -v # 出力結果 origin https://git.xxx.xxx.git (fetch) origin https://git.xxx.xxx.git (push) 解決方法 下記のコマンドでURLの変更をすることができる。 git remote set-url origin [※URL] ※URLってどれ？ 確認方法は以下です。（画像も添付いたしましたので参考にしていただけたら幸いです。） ①任意の　GitHub　のページにアクセスする ②Code　をクリック ③URL をコピー(※) ※　HTTPS, SSH, GitHub CLI とありますが今回コピーしたいのは　SSH　です。 設定の確認 ssh からはじまっていればokです。 ターミナル # コマンド git remote -v # 出力結果 origin ssh://git@xxx.xxx.xxx.xxx.git (fetch) origin ssh://git@xxx.xxx.xxx.xxx.git (push) 参考文献 gitのremote urlを変更する(レポジトリ移行時) gitでパスワードを毎回聞かれる問題の解決方法 Git が常にパスワードを要求するのはなぜですか？

git clnoeとは リモートリポジトリをローカルリポジトリに複製すること 複製という意味は理解してましたが、何をどうしていたかは知らなかったのでしっかり理解すべきだと思いました。 初めてgit cloneした時のエラー文 Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. どんな問題が発生しているか。 リモートリポジトリに対してアクセス権が無く、エラーになった。 解決方法 1.プライマリーキーの作成 ssh-keygen -t rsa -C メールアドレス メールアドレスはgithub登録した時と同じものにしてください。 すると順番にこのように表示されます。 Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: 上から、 ・鍵の保存場所の指定 ・パスワードの設定 ・パスワードの再入力 入力後エンターで先に進めます。 2.作成した鍵をコピーする。 ls ~/.ssh/ id_rsaが秘密鍵 id_rsa.pubが公開鍵 3.id_rsa.pubを表示する less ~/.ssh/id_rsa.pub id_rsa.pubファイルを開いて公開鍵の確認 sshから始まる長い文字列が表示されるので末尾のメールアドレスまでをコピーしておきます。 4.githubで鍵を登録する githubのマイページで、この鍵を登録します。 右上のアイコンをクリックし、settings → SSH and GPG keysをクリックしします。 次に、右上のnew keysをクリックしてください。 すると鍵の登録画面が現れます。 Keyのところに先程コピーしたものを貼り付けます。 5.ターミナルにてconfigを設定し、疎通確認をする vim ~/.ssh/config configの内容はこちら Host github HostName github.com IdentityFile ~/.ssh/id_rsa User git git cloneを再び実行すると、パスワードを求められるので設定したパスワードを入力し、クローン完了です。 参考資料

git cloneとは リモートリポジトリをローカルリポジトリに複製すること 複製という意味は理解してましたが、何をどうしていたかは知らなかったのでしっかり理解すべきだと思いました。 初めてgit cloneした時のエラー文 Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. どんな問題が発生しているか。 リモートリポジトリに対してアクセス権が無く、エラーになった。 解決方法 1.プライマリーキーの作成 ssh-keygen -t rsa -C メールアドレス メールアドレスはgithub登録した時と同じものにしてください。 すると順番にこのように表示されます。 Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: 上から、 ・鍵の保存場所の指定 ・パスワードの設定 ・パスワードの再入力 入力後エンターで先に進めます。 2.作成した鍵をコピーする。 ls ~/.ssh/ id_rsaが秘密鍵 id_rsa.pubが公開鍵 3.id_rsa.pubを表示する less ~/.ssh/id_rsa.pub id_rsa.pubファイルを開いて公開鍵の確認 sshから始まる長い文字列が表示されるので末尾のメールアドレスまでをコピーしておきます。 4.githubで鍵を登録する githubのマイページで、この鍵を登録します。 右上のアイコンをクリックし、settings → SSH and GPG keysをクリックしします。 次に、右上のnew keysをクリックしてください。 すると鍵の登録画面が現れます。 Keyのところに先程コピーしたものを貼り付けます。 5.ターミナルにてconfigを設定し、疎通確認をする vim ~/.ssh/config configの内容はこちら Host github HostName github.com IdentityFile ~/.ssh/id_rsa User git git cloneを再び実行すると、パスワードを求められるので設定したパスワードを入力し、クローン完了です。 参考資料

PostgreSQLを利用したシステム運用に際して、作業前後のスキーマ構造やデータの差分を確認したいことがあります。 いつかの方法とその注意点、自作したツールを紹介します。 \copyでダンプ psqlインタプリタ内で\copyメタコマンドを使って対象テーブルを指定ファイルに出力できます。 \copyコマンドは単一テーブルを指定するか、任意のSELECTクエリを指定することができますが、 単一テーブル指定の場合は出力はソートされません。 差分確認が目的であれば出力をソートしておくと便利ですので、SELECTクエリを利用しORDER BY句で順序を指定しておきます。 psql内でのコマンド例 -- 指定テーブルをダンプ (ソートされない) \copy テーブル名 to '出力ファイルパス' -- SELECTクエリをダンプ (ソート順を指定可能) \copy (SELECT ... FROM テーブル名 ORDER BY ...) to '出力ファイルパス' 対象テーブルがたくさんある場合は、Stack Overflowの記事で紹介されている方法 を応用すると一括で\copyコマンドを生成できます。 \copyコマンド一括生成SQL select '\copy (select * from '||r.relname||' order by '|| array_to_string(array_agg(a.attname), ',')|| ') to '''||r.relname||'.dmp'';' from pg_class r, pg_constraint c, pg_attribute a where r.oid = c.conrelid and r.oid = a.attrelid and a.attnum = ANY(conkey) and contype = 'p' and relkind = 'r' group by r.relname order by r.relname ; なお、\copyコマンドはデフォルトでタブ区切りテキストを出力します。 formatオプションでcsv(カンマ区切り)にすることもできますが、データ中の改行がエスケープされないため差分比較に不適なことが多いでしょう。 (詳細は psql ドキュメント参照) COPYでダンプ 対象テーブルが巨大な場合などは、PostgreSQLの拡張SQLコマンド COPY の利用を検討しても良いでしょう。 サーバ側でファイル生成して加工・圧縮してクライアントに持ってくる、などの応用ができます。 SQL例 -- サーバ側に出力する COPY (SELECT ... FROM テーブル名 ORDER BY ...) TO 'サーバ環境での出力ファイルパス'; 注意として、ファイルを書き出すのはサーバ側のpostgresデーモンです。 そのためファイルはサーバ側に生成され、その際にpostgresデーモン実行ユーザ(通常はpostgres)がアクセスできるファイルパスである必要があります。 またファイル出力する場合では、クエリを実行するDBユーザが(通常は)スーパーユーザ(postgres)である必要があります。 (詳細は COPY ドキュメント参照) pg_dump でダンプ ＋ ソートフィルタ pg_dump_sort PostgreSQLに付属のpg_dump, pg_dumpallクライアントプログラムを利用すると、手軽にスキーマ構造とデータの両方の情報をダンプできます。 ただし、ダンプされたテーブルの行データはソートされません。 そこで、pg_dump (pg_dumpall) のダンプ出力を解析し、全テーブルのデータ部分をそのテーブルの主キーでソートするフィルタスクリプト pg_dump_sort を書きました。 主キーが設定されていない場合は、代わりにユニークキーで、それも無ければ行を文字列的に評価してソートします。 htaketani/pg_dump_sort: Sort table rows data by primary key in pg_dump output sql. pg_dumpをソートする例 # ダンプする (`--inserts`オプションを使わない) pg_dump somedb > dump.sql # ダンプを解析し、各テーブルデータを主キーでソートする pg_dump_sort dump.sql > dump-sorted.sql 標準ライブラリのみを利用したperlスクリプトなので、どの環境でも動くと思います。 以下はインストール例です。環境に合わせて適宜chownしたりmove先を変更してください。 pg_dump_sortインストール例 curl -LO https://github.com/htaketani/pg_dump_sort/raw/main/pg_dump_sort && \ chmod +x pg_dump_sort && \ sudo mv pg_dump_sort /usr/local/bin/ タブ区切りテキストの差分を見る ソート済みのダンプデータを作成できたら、あとはお好みのdiffコマンドなどで差分確認します。 git diffはレポジトリ外のファイルの差分も取れ、--color-wordsオプションを使うと見やすくなるので重宝しています。 差分確認例 # アルファベットの塊、数字の塊をワードとし、それ以外(日本語など）は1文字単位で色付きdiff git diff --color-words=$'[A-Za-z]+|[0-9]+|[^\x80-\xbf][\x80-\xbf]*' before-sorted.dmp after-sorted.dmp よく使うのでエイリアスにしてます。 ~/.gitconfigエイリアス設定 [alias] d = diff --relative --no-prefix --color-words='[A-Za-z]+|[0-9]+|[^€-¿][€-¿]*' 参考 日本PostgreSQLユーザ会: PostgreSQL 12.4 付属ドキュメント php - Sorting postgresql database dump (pg_dump) - Stack Overflow tigra564/pgdump-sort: Sort entries of pg_dump output for the purpose of diffing database structure and contents Git Diff で日本語の文章も綺麗に差分を出す - Neo's World 厳密ではないものの、ほぼUTF-8の1文字にマッチするお手軽正規表現 [^\x80-\xbf][\x80-\xbf]* なるほどー - tmatsuu のブックマーク / はてなブックマーク

はじめに 学習するに至った経緯 未経験からエンジニアへの転職を目指し、プログラミングを勉強中。 Git/GitHub/GitHubDesktopの使い方を理解しているところと理解していないところが ごちゃ混ぜになっている事が判明。 自身の理解の整理と言語化による認識の深化による備忘録として記載。 Issueとは? GitHub上での課題を見える化して管理する機能である。 Issueの使用の手順 (1) Issueを作成する GitHubで、Issueを作成したいリポジトリにアクセスして『Issues』クリックする。 その後、右上の『New issue』をクリックする。 (2)Issueのタイトルと内容を入力する Issueを作成する画面で、タイトルと内容を入力する。内容はMarkdown形式で入力でき、チェックボックス、画像、リンクなども挿入可能。※ 『Preview』のタブをクリックすると、プレビューを見ることができるのでチェックする。 (3)Issueに担当者を割り振る もし、アサインしたい担当者が決まっている場合は、Assigneesの機能でIssueに担当者を割り振ることができる。右側の『Assignees』の歯車アイコンをクリックし、ユーザー名を検索、アサインしたいユーザーを選択する。 (4)Issueにラベルを付与する また、ラベルを付与することで、Issueの種類を視覚的にわかりやすくすることができる。 右側の「Labels」の歯車アイコンをクリックし、対応するラベルを1つもしくは複数選択する。 (5) Issueの作成を完了する 全ての設定が完了したら、『Submit new issue』で、新しいIssueが作成される。 リポジトリの『Issues』をクリックすることで、作成されたIssueを一覧、または開くことができる。 参考サイト GitHubプロジェクト管理入門 #01：Projectsのカンバン（KANBAN）方式でタスク管理しよう GitHubプロジェクト管理入門 #02：Issues（課題）機能で、バグを発見・修正しやすくしよう GitHubで課題を管理する便利機能Issueとその作成方法 GitHubのissueを活用した、個人アプリの開発手順を書いてみた Github issue との付き合い方 作成編

はじめに 学習するに至った経緯 未経験からエンジニアへの転職を目指し、プログラミングを勉強中。 Git/GitHub/GitHubDesktopの使い方を理解しているところと理解していないところが ごちゃ混ぜになっている事が判明。 自身の理解の整理と言語化による認識の深化による備忘録として記載。 Issueとは? GitHub上での課題を見える化して管理する機能である。 Issueの使用の手順 (1) Issueを作成する GitHubで、Issueを作成したいリポジトリにアクセスして『Issues』クリックする。 その後、右上の『New issue』をクリックする。 (2)Issueのタイトルと内容を入力する Issueを作成する画面で、タイトルと内容を入力する。内容はMarkdown形式で入力でき、チェックボックス、画像、リンクなども挿入可能。※ 『Preview』のタブをクリックすると、プレビューを見ることができるのでチェックする。 (3)Issueに担当者を割り振る もし、アサインしたい担当者が決まっている場合は、Assigneesの機能でIssueに担当者を割り振ることができる。右側の『Assignees』の歯車アイコンをクリックし、ユーザー名を検索、アサインしたいユーザーを選択する。 (4)Issueにラベルを付与する また、ラベルを付与することで、Issueの種類を視覚的にわかりやすくすることができる。 右側の「Labels」の歯車アイコンをクリックし、対応するラベルを1つもしくは複数選択する。 (5) Issueの作成を完了する 全ての設定が完了したら、『Submit new issue』で、新しいIssueが作成される。 リポジトリの『Issues』をクリックすることで、作成されたIssueを一覧、または開くことができる。 参考サイト GitHubプロジェクト管理入門 #01：Projectsのカンバン（KANBAN）方式でタスク管理しよう GitHubプロジェクト管理入門 #02：Issues（課題）機能で、バグを発見・修正しやすくしよう GitHubで課題を管理する便利機能Issueとその作成方法 GitHubのissueを活用した、個人アプリの開発手順を書いてみた

開発に関する備忘録 Gitコマンド git add -A git commit -m "コメント" Git-flowに関する参考サイト https://qiita.com/KosukeSone/items/514dd24828b485c69a05 Vimコマンド 参考サイト https://qiita.com/hide/items/5bfe5b322872c61a6896 Railsコマンド Dockerコマンド docker-compose stop docker-compose up -d その他 ローカルホストの接続先 http://localhost:3000/ figma参考サイト https://qiita.com/Hrioaki/items/d428d8318780a47f87ff VSCodeショートカット参考サイト https://qiita.com/naru0504/items/99495c4482cd158ddca8