はじめに 本投稿は、投稿者本人の知識定着を目的として学んだことをアウトプットしているものです Rails インストールからHerokuへのデプロイまで 開発環境→AWS Cloud9 1.Railsのインストール手順 ①インストール時間を短縮するため、Rubyドキュメントの設定を追加 $ echo "gem: --no-document" >> ~/.gemrc ②バージョンを指定してRailsをインストール $ gem install rails -v 6.0.3 ③インストール及びバージョンの確認 $ rails -v Rails 6.0.3 ④JavaScriptソフトウェアの依存関係を管理するYarnをインストール 今回はCloudIDEなので下記コードを入力し実行でOK $ source <(curl -sL https://cdn.learnenough.com/yarn_install) 2.アプリケーションの作成〜実行 ①下記のようにrailsのバージョンを合わせてアプリを作成 $ rails _6.0.3_ new hello_app ②アプリに必要なgemのインストール Gemfileにコードを書き込むが中身は別途学ぶ Gemのバージョンを制限する方法 ex:) gem 'rails', '~> 6.0.3' ~>:マイナーアップデート済みのgemをインストール 6.0.4はインストールするけど、6.1.0はインストールしない ex:) gem 'rails', '>= 6.0.3' 　>=常に最新版がインストールされる Gemfileへの記述を終えたら下記実行 $ bundle install ③ローカルWebサーバーへの接続を許可 Railsには開発マシンでのみブラウズできるローカルWebサーバーを起動するためのコマンドラインプログラム（スクリプト）が付属しているので、rails serverというコマンドを実行するだけでRailsアプリケーションを簡単に起動できる が、システムによっては（クラウドIDEであっても）、ローカルWebサーバーへの接続を許可する必要が生じることがあるので下記を記述 config/environments/development.rb Rails.application.configure do . . . # Cloud9 への接続を許可する config.hosts.clear end ④実行 下記を実行し、Railsページが表示されればクリア $ rails server Gitの管理 ※クラウドIDEではGitインストール済み ①systemセットアップ（コンピュータ1台につき1回だけ行う） $ git config --global user.name "自分の名前" $ git config --global user.email your.email@example.com クラウドIDEでデフォルトのエディタを設定する $ sudo ln -sf `which nano` /usr/bin ②初回リポジトリセットアップ 1. $ cd ~/environment/hello_app # Just in case you weren't already there $ git init Reinitialized existing Git repository in /home/ubuntu/environment/hello_app/.git/ Rails 6以降ではrails newコマンドを実行すると自動的にGitリポジトリも生成されるため、技術的にはgit initを必ずしも実行する必要はないと言えるが他の一般的なGitリポジトリはそうではないので、常にgit initを実行する癖をつけておく 2. 次は下記を実行して、プロジェクトの全ファイルをリポジトリに追加 $ git add -A このコマンドを実行すると、現在のディレクトリにあるファイルがすべてステージング（Staging）という一種の待機用リポジトリに置かれ、コミット(反映)を待つ。安全のため、いきなりコミットしないようになっている。ステージングの状態を知るには git status コマンドを使う。 3. ステージングエリアで控えている変更を本格的にリポジトリにコメント付き(-m)で反映（コミット）する $ git commit -m "Initialize repository" <重要> Gitにおけるコミット操作は、あくまでローカルマシン上にしか記録されないことに注意 ③Gitのメリット 重要なapp/controllers/ディレクトリを削除してしまった場合 $ ls app/controllers/ application_controller.rb concerns/ $ rm -rf app/controllers/ $ ls app/controllers/ ls: app/controllers/: No such file or directory ここでは、Unixコマンドのlsでapp/controllers/ディレクトリの中身を表示した後、rmコマンドをうっかり実行してしまい、このディレクトリを削除してしまった。 rfフラグは、「recursive」（サブディレクトリやその中のファイルもすべて削除する）と「force」（削除して良いかどうかをユーザーに確認しない）を指定するオプション 現在の状態を確認。 $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: app/controllers/application_controller.rb deleted: app/controllers/concerns/.keep no changes added to commit (use "git add" and/or "git commit -a") ファイルがいくつか削除されたが、この変更が行われたのは現在の「作業ツリー」内のみのため、まだコミット（保存）されない。つまり、以前のコミットをcheckoutコマンド（と、現在までの変更を強制的に上書きして元に戻すための-fフラグ）でチェックアウトすれば、簡単に削除前の状態に戻すことができる。 $ git checkout -f $ git status On branch master nothing to commit, working tree clean $ ls app/controllers/ application_controller.rb concerns/ ④Git Hub 1.GitHubをリモートoriginに追加してそのリポジトリにpushする $ git remote add origin https://github.com/<あなたのGitHubアカウント名>/hello_app.git $ git push -u origin master 最初のコマンドは、GitHubをリポジトリのoriginとしてGitの設定ファイルに追加するためのもの。次のコマンドでは、ローカルのリポジトリをリモートのoriginにプッシュ（push）。すると、hello_appのリポジトリのページがGitHub上に作成され、ファイルの参照、全コミット履歴などさまざまな機能を利用できる 2.Branch ブランチはリポジトリのコピーで、ブランチ上では元のファイルを触らずに新しいコードを書くなど、自由に変更や実験を試すことができる。親リポジトリはmaster(main)ブランチと呼ばれ、トピックブランチ（短期間だけ使う一時的なブランチ）はcheckoutと-bフラグを使って作成。　 3.Edit ex:)トピックブランチを作ったら、READMEを編集してカスタムコンテンツを追加 4.Commit 変更が終わったら、git status でブランチの状態を確認 次に下記を実行 $ git commit -a -m "Improve the README file" <注意> -aフラグは慎重に扱う。最後のコミット後に新しいファイルを追加した場合は、まずgit addを実行してバージョン管理下に置く 5.Merge ファイルの変更が終わったので、masterブランチにこの変更をマージ（merge） $ git checkout master Switched to branch 'master' $ git merge modify-README Updating b981e57..015008c Fast-forward README.md | 27 +++++---------------------- 1 file changed, 5 insertions(+), 22 deletions(-) 6.Push READMEファイルの更新が終わったので、GitHubに変更をプッシュして結果を見確認。既に一度プッシュを行ったので、大抵のシステムではgit pushを実行するときにorigin masterを省略できる。 $ git push Herokuへデプロイする Herokuとは Railsを含むRuby Webアプリ用のホスティングプラットフォーム (デプロイ方法は割愛します） 終わりに アプリケーションの作成、管理、デプロイまで学んだ。 次回以降、技術面について学習し力をつけたい。

プライベートメモ 環境 リモートリポジトリ: GitHub git version 2.32.0.windows.2 図

はじめに チーム開発において、現在いるfeatureブランチに他のメンバーが更新したdevelopブランチをマージしようとしたとき、以下のようなコンフリクトが発生した。 $ git merge develop warning: Cannot merge binary files: .DS_Store (HEAD vs. develop) Auto-merging .DS_Store CONFLICT (content): Merge conflict in .DS_Store Automatic merge failed; fix conflicts and then commit the result. ソースコードが書いてあるファイルの場合、手動で修正し、コミットすればいいが、.DS_Storeのようなバイナリファイルの場合、コンフリクトをどのように修正するのか調べてみた。 方法 「マージされるブランチもしくはマージするブランチどちらか片方のブランチにあるファイルを全面的に採用する」というコマンドを使う。 マージされるブランチ（= 現在いるブランチ）にあるファイルを採用したい時 git checkout --ours 対象ファイル マージするブランチにあるファイルを採用したい時 git checkout --theirs 対象ファイル その後はいつも通りaddしてcommitすればコンフリクトが解消される。 追記 バイナリファイル等の手動で修正することができないファイルが複数あり、ブランチ単位で指定したい場合は以下のコマンドを使う マージされるブランチ（= 現在いるブランチ）を採用したい時 git merge -Xours ブランチ名 マージするブランチを採用したい時 git merge -Xtheirs ブランチ名 参考 [git]マージ時のコンフリクトで片側の変更だけ適用する方法 マージでバイナリファイルがコンフリクトした場合のGitの動作と対処方法

はじめに この記事は、独学開始から約３ヶ月の実務未経験者が作成したものです。 よって、スキルは非常に未熟なため、決して本記事の内容を鵜呑みにされないよう、ご注意ください。 （未熟な私が記事投稿を行なっている背景については、本文の最後にお伝えします。） Githubを復習しようと思った理由 私が初めて自作Webアプリを開発した時にGitも使用いたしました。 しかし、全くと言っていいほどに使いこなせておりませんでした。 具体的には、【git add .】と【git commit -m”　”】、 【git push origin master】のコマンドしか使っておりませんでした。 ショボいアプリを１人で開発するのであれば、お粗末なコマンド操作で問題ありません（多分・・・）。 しかし、エンジニアとして就職したい私にとって、Gitの技術は必要不可欠です。 よって今回、Gitについての復習を行い、操作方法の基礎を学ぼうと決意しました。 参考資料 今回参考にした動画を下記に添付いたします。 https://www.youtube.com/watch?v=f4BRgGAXyek Gitの流れが動画で解説されており、また図でも示されているため、非常に分かりやすいです。 まずはこの動画を視聴されることをおすすめいたします。 そして、復習のために、下記の稚拙な記事を読み、記載内容の不備を探しながら知識の定着に繋げていただければと思います。 （記事の内容については、不備のないように全力は尽くしております。） よろしければコメント等でご指摘いただければ、嬉しいです。 ローカルの基本操作；情報の輸送 　Gitは、ワークツリー➡︎ステージ➡︎リポジトリと３つの段階に分けて情報を輸送していきます。 ①ワークツリー➡︎ステージへ情報を輸送する際、以下のコマンドをターミナルに入力します。 git add "ファイル名、あるいはディレクトリ名（フォルダ名）" ちなみに【git add .】とコマンドすると、ワークツリーで修正した全てのファイルをステージへ輸送されます。 ②下記コマンドを入力すると、現時点でステージ内にある全ての情報が、リポジトリへ輸送します。 git commit また、以下のコードに変更すると、ステージの情報をリポジトリに輸送する際に、コメントを残すことができます。 git commit -m”２０２１/１０/１０ 村人Aがh1→pに修正” 修正理由が分かりやすいコメントを残すことにより、第三者が確認しても理解することができます。 注意すべきポイント ①では、ワークツリー➡︎ステージへ情報を輸送する際、ファイルやディレクトリを指定することができるとお伝えいたしました。 しかし、ステージ➡︎リポジトリへ情報を輸送する際は、ステージにある情報全てがリポジトリへ輸送されてしまいます。 よって、任意で情報を小分けし、コメントを添付してリポジトリへと輸送したい場合、①でその処理を完了しておかなければなりません。 ローカルの基本操作；変更の確認 続いては、ファイルの変更点を確認する方法について、解説します。 ①修正したファイル名を確認する ワークツリーでファイルの内容を修正し、その修正内容をステージへ輸送したと仮定します。 上記のような修正サイクルを何度か繰り返すと、ふと「どのファイルの内容を修正して、ステージへ輸送したのか？」と疑問が湧きます。 その際に使うのが、下記のコマンドです。 git status このコマンドを入力することにより、ワークツリーからステージへ情報を輸送したファイル名を確認することができます。 ただし【git status】では、修正したファイル名を確認することができますが、修正した内容を確認することはできません。 修正した内容を確認するためには、下記のコマンドを利用します。 ②ファイル内容の差分を確認する リポジトリとワークツリーの内容の差分をターミナル内で確認する場合、以下をコマンド入力します。 git diff また、ステージとワークツリーの内容の差分を確認する場合、以下をコマンド入力します。 gie diff --staged ローカルの基本操作；履歴の確認 次にリポジトリ内の変更履歴を確認するためのコマンドをお伝えします。 git log 上記を打ち込むことにより、リポジトリ内の変更履歴がターミナル上に表示されます。 コメントが記載された状態でリポジトリ内に輸送された情報については、そのコメントとともに履歴が表示されます。 また、【git log】には、様々なオプションが備わっております。 そのオプションを使用すれば、履歴の確認を効率的に行うことができます。 【git log】のオプションについてまとめてくれている記事を下記に添付いたしましたので、興味のある方はご確認ください。 https://qiita.com/take4s5i/items/15d8648405f4e7ea3039 ローカルの基本操作；元に戻す コードの修正途中でエラーが発生することは多々あります。 そんな時、全てを無にして、１からやり直したい場面もあります。 その場合、ステージやリポジトリでセーブしてあるデータをワークツリーに戻すことができるコマンドを紹介します。 まず、ステージでセーブしているデータをワークツリーへ戻すコマンドは以下の通りです。 git restore　--staged "ファイル名" 次にリポジトリでセーブされているデータをワークツリーへ戻すコマンドは以下の通りです。 git restore "ファイル名" Gitコマンドの基礎理解は以上で終了です。 最後に 上記でもお伝えいたしましたが、私は独学開始から約３ヶ月の実務未経験者です。 そんな未熟な私が記事を投稿しようと決意した理由は、以下の通りです。 ・初学者の記事が多く出回るほどに、プログラミングの学習を検討している方の背中を押せると考えたから（私自身、学習を開始するまでに初学者の記事を読み漁っておりました） ・周りに同じ境遇の仲間がいない、孤独な初学者さんの競争心を掻き立てられるのではと考えたから（学習効率を上げるためにはライバルの存在は重要） ・あるいはこのような稚拙な記事を読んだ初学者さんが「自分のレベルはこいつよりも上」と優越感を与えられるのではと考えたから（学習効率を上げるためには自信を持つことも重要） プロのエンジニア同様、初学者にもそれなりの努めがあると、私は思います。 今後も、下手くそながらも【初学者ページ】を上げ続けて参ります。 最後まで読んでいただき、誠にありがとうございました。

はじめに この記事は、独学開始から約３ヶ月の実務未経験者が作成したものです。 よって、スキルは非常に未熟なため、決して本記事の内容を鵜呑みにされないよう、ご注意ください。 （未熟な私が記事投稿を行なっている背景については、本文の最後にお伝えします。） Gitを復習しようと思った理由 私が初めて自作Webアプリを開発した時にGit(Github)を使用いたしました。 しかし、どのような仕組みで動いているかをしっかりと理解せぬままに、使用しておりました。 ショボいアプリを１人で開発するのであれば、お粗末なコマンド操作で問題ありません（多分・・・）。 しかし、エンジニアとして就職したい私にとって、Gitの技術は必要不可欠です。 よって今回、私が個人開発した時に使用したGitコマンドを中心に復習します。 参考資料 今回参考にした動画を下記に添付いたします。 https://www.youtube.com/watch?v=f4BRgGAXyek Gitの流れが動画で解説されており、また図でも示されているため、非常に分かりやすいです。 まずはこの動画を視聴されることをおすすめいたします。 そして、復習のために、下記の稚拙な記事を読み、記載内容の不備を探しながら知識の定着に繋げていただければと思います。 （記事の内容については、不備のないように全力は尽くしております。） よろしければコメント等でご指摘いただければ、嬉しいです。 ローカルの基本操作；情報の輸送 　Gitは、ワークツリー➡︎ステージ➡︎リポジトリと３つの段階に分けて情報を輸送していきます。 ①ワークツリー➡︎ステージへ情報を輸送する際、以下のコマンドをターミナルに入力します。 git add "ファイル名、あるいはディレクトリ名（フォルダ名）" ちなみに【git add .】とコマンドすると、ワークツリーで修正した全てのファイルをステージへ輸送されます。 ②下記コマンドを入力すると、現時点でステージ内にある全ての情報が、リポジトリへ輸送します。 git commit また、以下のコードに変更すると、ステージの情報をリポジトリに輸送する際に、コメントを残すことができます。 git commit -m”２０２１/１０/１０ 村人Aがh1→pに修正” 修正理由が分かりやすいコメントを残すことにより、第三者が確認しても理解することができます。 注意すべきポイント ①では、ワークツリー➡︎ステージへ情報を輸送する際、ファイルやディレクトリを指定することができるとお伝えいたしました。 しかし、ステージ➡︎リポジトリへ情報を輸送する際は、ステージにある情報全てがリポジトリへ輸送されてしまいます。 よって、任意で情報を小分けし、コメントを添付してリポジトリへと輸送したい場合、①でその処理を完了しておかなければなりません。 ローカルの基本操作；変更の確認 続いては、ファイルの変更点を確認する方法について、解説します。 ①修正したファイル名を確認する ワークツリーでファイルの内容を修正し、その修正内容をステージへ輸送したと仮定します。 上記のような修正サイクルを何度か繰り返すと、ふと「どのファイルの内容を修正して、ステージへ輸送したのか？」と疑問が湧きます。 その際に使うのが、下記のコマンドです。 git status このコマンドを入力することにより、ワークツリーからステージへ情報を輸送したファイル名を確認することができます。 ただし【git status】では、修正したファイル名を確認することができますが、修正した内容を確認することはできません。 修正した内容を確認するためには、下記のコマンドを利用します。 ②ファイル内容の差分を確認する リポジトリとワークツリーの内容の差分をターミナル内で確認する場合、以下をコマンド入力します。 git diff また、ステージとワークツリーの内容の差分を確認する場合、以下をコマンド入力します。 gie diff --staged ローカルの基本操作；履歴の確認 次にリポジトリ内の変更履歴を確認するためのコマンドをお伝えします。 git log 上記を打ち込むことにより、リポジトリ内の変更履歴がターミナル上に表示されます。 コメントが記載された状態でリポジトリ内に輸送された情報については、そのコメントとともに履歴が表示されます。 また、【git log】には、様々なオプションが備わっております。 そのオプションを使用すれば、履歴の確認を効率的に行うことができます。 【git log】のオプションについてまとめてくれている記事を下記に添付いたしましたので、興味のある方はご確認ください。 https://qiita.com/take4s5i/items/15d8648405f4e7ea3039 ローカルの基本操作；元に戻す コードの修正途中でエラーが発生することは多々あります。 そんな時、全てを無にして、１からやり直したい場面もあります。 その場合、ステージやリポジトリでセーブしてあるデータをワークツリーに戻すことができるコマンドを紹介します。 まず、ステージでセーブしているデータをワークツリーへ戻すコマンドは以下の通りです。 git restore　--staged "ファイル名" 次にリポジトリでセーブされているデータをワークツリーへ戻すコマンドは以下の通りです。 git restore "ファイル名" Gitコマンドの基礎理解は以上で終了です。 最後に 上記でもお伝えいたしましたが、私は独学開始から約３ヶ月の実務未経験者です。 そんな未熟な私が記事を投稿しようと決意した理由は、以下の通りです。 ・初学者の記事が多く出回るほどに、プログラミングの学習を検討している方の背中を押せると考えたから（私自身、学習を開始するまでに初学者の記事を読み漁っておりました） ・周りに同じ境遇の仲間がいない、孤独な初学者さんの競争心を掻き立てられるのではと考えたから（学習効率を上げるためにはライバルの存在は重要） ・あるいはこのような稚拙な記事を読んだ初学者さんが「自分のレベルはこいつよりも上」と優越感を与えられるのではと考えたから（学習効率を上げるためには自信を持つことも重要） プロのエンジニア同様、初学者にもそれなりの努めがあると、私は思います。 今後も、下手くそながらも【初学者ページ】を上げ続けて参ります。 最後まで読んでいただき、誠にありがとうございました。

はじめに Github上で開発をしている際に開発しているmoduleとは別のRepositoryのmoduleを利用したい場合があります． そのようなときにsubmoduleを利用します．一方で，単純にsubmoduleを加えるだけだとpip installをした際にsubmoduleが追加されないという問題が発生します．その対処法について簡単に説明します． 参考：How to write setup.py to include a Git repository as a dependency 問題設定 Sphere関数という関数を作成し，それをsubmoduleとして利用したいケースを想定します． 例としてsubmodule_practice_parentというrepositoryを用意しました． submodule_practice_parent/ 　├ submodule_practice_parent/ 　│　　└ __init__.py 　│　　└ func.py <=== これを使いたい 　├ requirements.txt 　└ setup.py submodule_practice_parent.func.sphereという関数が実際に利用したい関数です． 次にsubmodule_practice_childというrepositoryを用意します．この run.py の中から submodule_practice_parent.func.sphereを呼び出せるようにします． submodule_practice_child/ 　├ submodule_practice_parent/ <== submodule 　├ submodule_practice_child/ 　│　　└ __init__.py 　│　　└ run.py 　├ .gitmodules 　├ requirements.txt 　└ setup.py submodule_practice_parentは以下のコマンドによってsubmodule_practice_childのsubmoduleになっていると仮定します． git submodule add https://github.com/nabenabe0928/submodule_practice_parent submodule_practice_parent 対処法 解決の手順を順番に書いていきます． 1. submodule_practice_parent の中に setup.pyがなければ作る 2. submodule_practice_child の setup() の引数である install_requires にsubmoduleを指定する コード例は以下の通り． import setuptools requirements = [] with open("requirements.txt", "r") as f: for line in f: requirements.append(line.strip()) requirements.append( "submodule_practice_parent " "@ git+ssh://git@" "github.com/nabenabe0928/submodule_practice_parent" # "@v0.0.1#egg=submodule_practice_parent" <== versionがあるなら指定する "#egg=submodule_practice_parent" ) setuptools.setup( name="submodule_practice_child", version="0.0.1", author="nabenabe0928", author_email="user@gmail.com", url="https://github.com/nabenabe0928/submodule_practice_child", packages=setuptools.find_packages(), python_requires='>=3.8', platforms=['Linux'], install_requires=requirements, include_package_data=True ) テスト 実際にうまくいくかどうか試してみます． 今回はmoduleがpublicになっていないので，Localにcloneしてからうまくいくか試します． # テスト用の新しい環境を作成 $ conda create -n package_checker python=3.8 # pipのパスを確認 (今回は `package_checker` のpipか確認) $ which pip /home/user/anaconda3/envs/package_checker/bin/pip $ git clone https://github.com/nabenabe0928/submodule_practice_child $ cd submodule_practice_child/ # submodule_practice_child を install $ pip install . # 念の為，別のディレクトリに移動 $ cd <適当なディレクトリ> $ python >>> from submodule_practice_child.run import start >>> start() 55 module not foundなしにうまく実行されました．