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

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

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

# 環境
- MacOS Big Sur v11.2.1
- VSCode
- GitHubの登録・SSH接続済み


## 手順

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

```terminal
$ brew update
```

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

```terminal
$ brew install rbenv
```

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

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

```terminal:sample_app
$ rbenv install 2.6.5
```

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

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

```ruby:sample_app/Gemfile
# frozen_string_literal: true

source "https://rubygems.org"

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

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

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

```terminal:sample_app
$ bundle install --path vendor/bundle
```

参考: [bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみよう](https://qiita.com/jnchito/items/99b1dbea1767a5095d85)

## Railsプロジェクトの開始
インストール出来るRailsを確認してみます。

```terminal:sample_app
$ gem list rails

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

```terminal:sample_app
$ gem install -v 5.2.4.2 rails
・・・
$ gem list rails

*** LOCAL GEMS ***

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

```terminal: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'```としてあげることで勝手に他のバージョンならないように固定する。

```ruby:sample_app/Gemfile
・・・

ruby '2.6.5'

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

・・・
```

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


```terminal: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が インストールできない](https://www.webcyou.com/?p=9606)で解決できました。

```terminal
$ 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にアクセス、、、

<img width="617" alt="スクリーンショット 2020-06-20 13.25.58.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/67e14813-f7c8-a972-7f47-e92f0ffe34b0.png">

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


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

## やってみる

[GitHub](https://github.com/)のRepositoriesのNewから新しくプロジェクトを開始します。
Repository nameには好きな名前を、Privateにチェックを入れてほかはスルー。
<img width="776" alt="スクリーンショット 2020-06-20 16.20.40.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/99e2077a-c09a-062e-6ceb-6fe84526688d.png">

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

```terminal: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を確認することができます。
<img width="1578" alt="スクリーンショット 2020-06-20 17.08.13.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/06c83735-36b0-e2bf-1d27-d350a7922ea8.png">

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

### master と topic

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

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

```terminal:sample_app
$ git status
On branch topic
nothing to commit, working tree clean
```
トピック(topic)ブランチにいるよ、コミットするものはないよ、作業スペースもキレイといっています。

###  addしてみる

開発用のtopicブランチにいることを確認したら少しファイルを弄ってみます。```gitignore```を設定し直し```README.md```も少し変えてみました。サイドバーのGitマークをクリックし中身を見てみると先程の２つのファイルが作業スペースにあるので、＋ボタンをクリックしてステージング環境に移動させてやります。
これはターミナルでいう```$ git add```と同じことをしています。
<img width="458" alt="スクリーンショット 2020-06-20 17.38.33.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/81729026-4fd9-2286-b1f6-b35c317d9d4e.png">

ステージング済みになりコミットする準備が整いましたね。そしたらその上のテキストボックスにコミット内容を記述し、更に上のチェックボタンを押して変更をコミットします。
これもまたターミナルでいう```$ git commit -m "動作確認"```と同等です。
<img width="458" alt="スクリーンショット 2020-06-20 17.40.25.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/d33db270-2cc5-7459-81ca-63bee6297986.png">

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

<img width="314" alt="スクリーンショット 2020-06-20 18.19.14.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/a3de6e39-f0a6-6acd-f7cf-479119c41950.png">

さて、このまま変更をローカルのmasterブランチに反映させても問題なさそうなのでマージしたいと思います。まず左下のtopicを押してmasterブランチを選び、移動したこと確認します。
<img width="314" alt="スクリーンショット 2020-06-20 18.16.49.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/d4f7c6c3-8ed2-6837-94ed-e29e7eb7a3bf.png">

緑色のtopicの真下にあるMoreをクリックしてMerge thisを選びます。
topicを選択し、最終確認を済ませると...
<img width="1168" alt="スクリーンショット 2020-06-20 17.55.26.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/4597b0e5-3679-28dc-2d5e-8be219d09e2c.png">

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

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

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

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

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

### やり方
topicブランチで開発を進め、３つのファイルの変更があったとします。＋ボタンでステージングにaddをしてコミットメッセージを適当につけます。
<img width="246" alt="スクリーンショット 2020-06-20 19.00.11.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/f15685c0-8546-d830-feb9-1b5bcec1d3b1.png">

コミットもして、先程の通りmasterブランチに切り替えてtopicブランチをマージします。
<img width="916" alt="スクリーンショット 2020-06-20 19.02.18.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/66c42c7f-4952-c20e-07a3-e648d2ae06a9.png">
うん、予想通り。
ここからリモートリポジトリにプッシュをしていくのですが流れとしては次の通りです。

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

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


```terminal: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```を選ぶと現れるはず。
<img width="992" alt="スクリーンショット 2020-06-21 10.03.07.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/2fee26ef-7e5a-a373-ac65-5dd75c523e49.png">

上の枠には、topicからmasterへのプルリクを比較していてそれがマージ可能であることを示しています。
確認できたらタイトルとメッセージを書きます。タイトルにはコミットした際のメッセージが最初から当てられていると思います。
<img width="748" alt="スクリーンショット 2020-06-21 10.08.16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/df2d79fe-05b7-efc6-6839-2db31163d0f3.png">

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

メッセージも書けたら'Create pull request' します。
今回は個人開発でリポジトリの管理者も自分だけな為すぐにマージできますが、せっかくなので色々触ってみます。タブからFile changedをクリックします。
<img width="655" alt="スクリーンショット 2020-06-21 10.32.41.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/89284f97-ab68-4c03-e85b-01cb44fffe6f.png">

ここでは変更のあったファイルをレビューすることが出来ます。疑問や提案、称賛のコメントを積極的に残しましょう。
一通り書いたら右上部の'Review changes'から'Submit review'でレビューをします。
<img width="1056" alt="スクリーンショット 2020-06-21 10.30.40.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/e9afd5ee-93d5-27a6-8f1c-8e7de7773a8b.png">

'Conversion'タブへ戻るとレビュー等が反映されています。
<img width="757" alt="スクリーンショット 2020-06-21 10.42.34.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/1dc35ba2-553f-c57e-51ef-fdc09935ddaa.png">

最終確認を済ませたら'Merge pull request'から'Confirm merge'でマージを完了。
<img width="757" alt="スクリーンショット 2020-06-21 10.46.02.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/bd846afb-61f1-c586-e52b-c8192b13a023.png">

トップページへ戻ってみると先程のマージが反映されてますね！
<img width="999" alt="スクリーンショット 2020-06-21 10.51.24.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/597061/b2f2a7d4-e244-70a7-2dbb-f830f3581b90.png">

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

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

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

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

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


## 参考記事
- [新規Railsプロジェクトの作成手順まとめ](https://qiita.com/yuitnnn/items/b45bba658d86eabdbb26)
- [bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみよう](https://qiita.com/jnchito/items/99b1dbea1767a5095d85)
- [VSCodeでのGitの基本操作まとめ](https://qiita.com/y-tsutsu/items/2ba96b16b220fb5913be)