【初学者向け】Railsでポートフォリオ用の成果物を作る一連の流れ

状況

Railsアプリを作成中にミスを犯し、Gitによる管理もままならない状況で全てがお釈迦に。
丁度いい機会だと思い、Gitによるソース管理・環境構築の2つをしっかり理解した上で開発を行おうということに。

こんな方へ

• Railsでアプリ開発したいけど環境構築面でつまずく方
• Git・GitHubをあまり使いこなせていない方

環境

• MacOS Big Sur v11.2.1
• VSCode
• GitHubの登録・SSH接続済み

手順

Homebrewはインストール済の前提で進めます。
初めに、Homebrewをアップデートして綺麗にします。

$ brew update

そして、rubyのインストーラであるrbenvをインストールします！

$ brew install rbenv

プロジェクト用のフォルダを作成して移動します。

次にrubyのインストールですが、今回はバージョン2.6.5をインストールします。
$ rbenv install --listと打つとインストール可能なバージョンが表示されるので、適宜コマンドを叩いてインストールします！

sample_app

$ rbenv install 2.6.5

インストールが済んだら$ rbenv local 2.6.5で環境に適用させます。
（localで、現在のディレクトリにのみこのバージョンを適応することができます。逆に、コマンドを叩いたディレクトリ以外にもバージョンを適用した場合にはglobalを指定しましょう）

sample_app

$ bundle init

生成されたGemfileをvimでもFinderから直接でもいいので開く。
一番下に記述されている# gem "rails"の#をはずしgem "rails"にする。

sample_app/Gemfile

# frozen_string_literal: true

source "https://rubygems.org"

git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }

gem "rails" # コメントアウトを外す

できたらターミナルに戻って次のコマンドでrailsをインストールする。

sample_app

$ bundle install --path vendor/bundle

参考: bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみよう

Railsプロジェクトの開始

インストール出来るRailsを確認してみます。

sample_app

$ gem list rails

*** LOCAL GEMS ***

使いたいバージョンのrailsがなければバージョンを指定してgemをインストールします。
指定しないと６系がインストールされると思います。６系はまだ互換性の面で不安定なとこがあるし、新しいせいで情報が少ないこともあるため初学者は避けたほうが良さげ。

sample_app

$ gem install -v 5.2.4.2 rails
・・・
$ gem list rails

*** LOCAL GEMS ***

rails (5.2.4.2)
...

gemがインストールされたのでようやくプロジェクトを開始できそうです。

Portfolio

$ rails _5.2.4.2_ new . -d mysql --skip-turbolinks --skip-test --skip-bundle
create
      create  README.md
      create  Rakefile
・・・

new .としてあげることで今いるsample_appにRailsプロジェクトを展開することが出来ます。
コマンドの解説は次の通り。場合によって追加したり削除したりしてください。

• rails _○.○.○.○_
  • バージョンを指定してインストール
• -d mysql
  • データベースをデフォルトのSQLiteから高速で安定性のあるMySQLに変更。
• --skip-turbolinks
  • ターボリンクをオフに。ページの遷移が早くなるらしい。
• --skip-test
  • RSpecを使う予定のためデフォルトのminitestをスキップします。
• --skip-bundle
  • 勝手にbundle installされるとRailsのバージョンが上書きされちゃうことがあるため。でも実はもっと深い意味があるそう。

---

終わったらプロジェクト名のディレクトリの中にあるGemfileに必要なgemを記述していきます。
'= 5.2.4.2'としてあげることで勝手に他のバージョンならないように固定する。

sample_app/Gemfile

・・・

ruby '2.6.5'

gem 'rails', '= 5.2.4.2'
gem 'mysql2', '>= 0.4.4', '< 0.6.0'

・・・

必要なgemを書いたら$ bundle install

sample_app

$ bundle install
・・・

An error occurred while installing mysql2 (0.5.3), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.5.3' --source 'https://rubygems.org/'` succeeds before bundling.

なにやらmysql2でエラーが発生。
色々試してみましたがウェブ帳さんのRails5 gemでmysql2が インストールできないで解決できました。

$ bundle config --local build.mysql2 "--with-cppflags=-I/usr/local/opt/openssl/include"
$ bundle config --local build.mysql2 "--with-ldflags=-L/usr/local/opt/openssl/lib"

再度$ bundle installし次は成功。
$ rails db:createでデータベースも作成しておきます。

動作確認で$ rails sをしlocalhost:3000にアクセス、、、

接続できていてバージョンもバッチリ！

##Git管理とGitHub
次にGitによるプロジェクトの管理をしていきます。
VSCode上に最初からあるツールで充分過ぎるのでそれを使っていきます。
GitHistoryという拡張機能が便利なのでそちらもインストールしておきます。

やってみる

GitHubのRepositoriesのNewから新しくプロジェクトを開始します。
Repository nameには好きな名前を、Privateにチェックを入れてほかはスルー。

Create repositoryを押したらその画面は一時置いておいてVSCodeに移ります。
VSCodeを起動したら「フォルダを開く」からsample_appを開きます。
ターミナルから、先程の画面に表示される５行のコマンドを順に入力していきます。

sample_app

$ git init
$ git add .
$ git commit -m "first commit"
$ git remote add origin https://github.com/******/sample.git
$ git push -u origin master

コマンドの説明としては次の通り。よくわからなかったらスルーしてOK。

• git init
  • gitによる管理を開始
• git add .
  • 編集したファイルをコミットするためのステージング環境に追加します。.とすることで全ファイルをステージングしています。
• git commit -m "first commit"
  • "first commit"というメッセージとともにステージングにあるファイルをコミット。-m "○○"で○○というメッセージを追加しています。
• git remote add origin https...
  • リモートのサーバ(https...)にoriginという短縮名をつけてげているらしい。originなのは慣習的にそう決まっているそう。
• git push -u origin master
  • pushによりローカルの変更点をリモートリポジトリに同期する。origin masterがリモートのmasterブランチであることはもうわかりますね。

いざ開発

VSCodeのGit Historyを見ていきましょう。画像の通り１、２とクリックすると履歴を見ることができ、最初に行ったfirst commitを確認することができます。

３から現在masterというブランチにいることがわかります。ブランチ（枝）とは開発の環境を互いに影響を与えずに「修正用」とか「機能追加用」とか枝分かれさせていき柔軟に開発を進めるためのものです。

master と topic

デフォルトのmasterブランチには慣習的に安定版や完成品を置いておき、masterブランチ上で開発を行わない事が多いです。そのため新しく開発用のブランチを作成しましょう。３から新しくブランチを作成します。今回は'topic'と名前をつけました。

現在のGitの状態を見れるgit statusをターミナルで打ってみます。

sample_app

$ git status
On branch topic
nothing to commit, working tree clean

トピック(topic)ブランチにいるよ、コミットするものはないよ、作業スペースもキレイといっています。

addしてみる

開発用のtopicブランチにいることを確認したら少しファイルを弄ってみます。gitignoreを設定し直しREADME.mdも少し変えてみました。サイドバーのGitマークをクリックし中身を見てみると先程の２つのファイルが作業スペースにあるので、＋ボタンをクリックしてステージング環境に移動させてやります。
これはターミナルでいう$ git addと同じことをしています。

ステージング済みになりコミットする準備が整いましたね。そしたらその上のテキストボックスにコミット内容を記述し、更に上のチェックボタンを押して変更をコミットします。
これもまたターミナルでいう$ git commit -m "動作確認"と同等です。

再び履歴を見てみます。次の写真に注目すると、最新の状態である上段に緑色のtopicブランチ、下段（変更前）に緑色のmasterブランチと赤色のorigin/masterブランチがありますね。topicブランチで開発を進めているわけですから時系列が一番新しいのも理解できると思います。

さて、このまま変更をローカルのmasterブランチに反映させても問題なさそうなのでマージしたいと思います。まず左下のtopicを押してmasterブランチを選び、移動したこと確認します。

緑色のtopicの真下にあるMoreをクリックしてMerge thisを選びます。
topicを選択し、最終確認を済ませると...

きちんとmasterにもtopicで変更された内容が反映されました！！

プッシュとプルリクエスト

実は先程のブランチを切り替える際に押したtopicやmasterが書いてあるボタンの右に、雲マークもしくは２本の矢印が丸を描いているボタンがあると思います。それをクリックすれば簡単にリモートリポジトリへ現在の変更を同期することができます。

でもこれ考えてみてください。チーム開発していたとして突然、完成品のみを扱うと決めたmasterブランチに他のメンバーから確認もなしに変更を同期されるようなものです。

プルリクエストを作れば、マージするに値するのかチームメンバーにコードをレビューしてもらい、許可が下りればマージされるみたいなことが出来事故も防げます。個人開発ではありますが慣れておいて損はないでしょう。

やり方

topicブランチで開発を進め、３つのファイルの変更があったとします。＋ボタンでステージングにaddをしてコミットメッセージを適当につけます。

コミットもして、先程の通りmasterブランチに切り替えてtopicブランチをマージします。

うん、予想通り。
ここからリモートリポジトリにプッシュをしていくのですが流れとしては次の通りです。

ローカルリポジトリのmasterブランチからリモートリポジトリのorigin/topicブランチにプッシュする（正直topic → origin/topicでいい気がする）
↓
GitHub上でリモートリポジトリのorigin/topicブランチからorigin/masterへのプルリクエストを作る
↓
リポジトリの管理者にマージしてもらう。

先程の続きからやっていきましょう。orign/topicへプッシュします。
あれ、リモートリポジトリにはまだmasterブランチしかないよ？と思った方は安心してください。ブランチがない場合は状況に応じて新しくブランチを作ってくれます。

sample_app

$ git push origin topic

・・・
remote: Create a pull request for 'topic' on GitHub by visiting:
remote:      https://github.com/******/sample/pull/new/topic
remote:
To https://github.com/******/sample.git
 * [new branch]      topic -> topic

GitHub上でtopicへのプルリクエスト作ります。
topic -> topicはtopic -> origin/topicということです〜。

疑似チーム開発

GitHubを覗きプロジェクトのトップページへ行くと'topic' Compare & pull requestとあるのでクリックしてプルリクを作成します。ない場合はBranchからtopicを選ぶと現れるはず。

上の枠には、topicからmasterへのプルリクを比較していてそれがマージ可能であることを示しています。
確認できたらタイトルとメッセージを書きます。タイトルにはコミットした際のメッセージが最初から当てられていると思います。

メッセージは自分以外の人が見ても理解できる内容を書くようにしましょう。
プルリクの書き方についてはこちらの方の記事がとても参考になりました。
→GitHub「完璧なプルリクの書き方を教えるぜ」

メッセージも書けたら'Create pull request' します。
今回は個人開発でリポジトリの管理者も自分だけな為すぐにマージできますが、せっかくなので色々触ってみます。タブからFile changedをクリックします。

ここでは変更のあったファイルをレビューすることが出来ます。疑問や提案、称賛のコメントを積極的に残しましょう。
一通り書いたら右上部の'Review changes'から'Submit review'でレビューをします。

'Conversion'タブへ戻るとレビュー等が反映されています。

最終確認を済ませたら'Merge pull request'から'Confirm merge'でマージを完了。

トップページへ戻ってみると先程のマージが反映されてますね！

これでやっと一連の流れが完了です。
このあたかも複数人で開発しているかのように見せる行為が疑似プルリクと言われる所以だと思います。

まとめ

この記事を書いてみて、理解しているようで出来ていなかったことを沢山知ることが出来ました。それでも書いていて怪しいなと思うことも多く（特にブランチの運用あたり)、まだまだ勉強が必要だなと思いました。

初めてこんなにも長い文を書いたのでおかしな部分もあると思います！
これからも現在進行系で開発を進めながら記録を書き残しています。
プロジェクトが一段落ついたり、完成したりすればまた書こうと思っています。次はRSpecかな？？

地方在住でも独学でも情報系でなくても周りにプログラミングをやっている友達がいなくてもそれなりの成果物を完成させてバックエンドエンジニアとして就職が出来ることを証明して見せます！！

学生として就活情報やインターンなど経験も記事にして発信していくつもりです。
記事のことでも記事以外のことでもどんな内容でもいいのでコメントお待ちしています！！

参考記事

• 新規Railsプロジェクトの作成手順まとめ
• bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみよう
• VSCodeでのGitの基本操作まとめ