(2020/6/1　追記)

Node.jsでWebアプリを作ろうとVSCode（Powershell）で作成、初めてGitを使ってみようと決心したものの、いくつかの壁に当たりました。

なんとか解決した経緯を書きます。

１．Gitのインストール

https://proengineer.internous.co.jp/content/columnfeature/6893#1

こちらのサイトを参考に（versionは違うっぽいですが多分大丈夫）、まずはGitをインストールしました。

2.　初期設定

無事インストールできたら、左下のスタートボタンを左クリックして、Git Bashなるものを起動してコマンドプロンプトっぽいやつを出し、

https://qiita.com/kerobot/items/78372640127771f92ee0

こちらのサイトでGitの初期設定をしました。

3.　VSCode内ターミナルでの試み

まずVSCode内のターミナル、つまりPowershellでなんとかGitHubにpushできないかと頑張ってみました。

https://qiita.com/Toshimatsu/items/f71a935612a55d6e674e

こちらのサイトを参考に、ローカルリポジトリに移す段階までは行くことができましたが、

$ git push --set-upstream origin master

git: 'remote-ps' is not a git command. See 'git --help'.
The most similar command is remote-ftps

最後の最後で必ずこうなってしまい、解決策も全く引っかからなかったので、おとなしくGit Bash上で行うことにしました。

4.　Git Bashでrejected

Git Bashを起動して、VSCodeで作業していたファイルへと移動します。

> cd (ファイル名)

3のサイトと同様に行い、またもローカルリポジトリまでは行くのですが、今度は以下のようなエラーが出てきてしまいました。

$ git push --set-upstream origin master

 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/kanprogramming/threadapp.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

ggり続けたところ、次のQiita記事を見つけました。
https://qiita.com/takanatsu/items/fc89de9bd11148da1438

どうやら、fetchやらmergeやらをしないと駄目らしい。

$ git fetch && git merge origin/master
(なんか色々出てくる)
$ git merge --allow-unrelated-histories origin/master
(なんか色々出てくる、READMEとか出てきたら成功だと思います)

これでまたpushしてみたら、僕はできました。

(6/1 追記)

なんとなく関係図を作ってみました。
どうやらorigin/masterというのが中間生成物的な扱いで、ここを経由してリモートとローカルのやりとりをしてるみたいです。(あってますかね？)

コンフリクトした時の解消法を今調べてます。

エラー内容

$ git push origin master
Permission denied (publickey). fatal: Could not read from remote repository.  Please make sure you have the correct access rights and the repository exists.

解決策

vagrant 環境でgitの秘密鍵が設定されていないから。

まず、ローカルで

cd .ssh
cp id_rsa ~/Document/work/vagrant

仮想環境で

mv id_rsa ~/.ssh

これでOK!

リポジトリ追加の際のcommandの操作について
いつも忘れてしまうのでメモです。

環境

• 作成済みのリポジトリを用意
• ローカルに新しくディレクトリを作成してgit init後の操作

リポジトリ追加コマンド

$git remote add origin 追加したいリポジトリ

リポジトリ消去コマンド

$ git remote rm origin

git pullを実行するとエラーが出る

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> master

どのブランチにマージしていいかわからないという意味なので以下のコマンドを実行します。

$ git pull リポジトリurl master

これでマージできました。

gitでよく使うコマンド

gitリポジトリを作成する

$ git init

gitの状態を確認

$ git status

選択したファイルをステージングする

$ git add ファイル名

カレントディレクトリのrbファイルをステージングする

$ git add *.rb

カレントディレクトリ以下の全ての変更のあったファイルをステージングする

$ git add .

変更のあったファイルをすべてステージングする

$ git add -A

gitにコメントをつけて保存する

$ git commit -m 'コメント'

変更履歴を確認

$ git log

github

githubをリポジトリのoriginとしてgitの設定ファイルに追加（githubでリポジトリを作ったときに自動で作成されていたので、コピペして使用）

$ git remote add origin https://github.com/XXXX/XXXXXX.git

githubのmasterにアップロードする

$ git push origin master

リモートリポジトリからローカルに最新のリポジトリをダウンロード

$ git pull origin

ブランチの作成

masterからdevelopブランチを作成し、developブランチに切り替える

$ git checkout -b develop master

masterにブランチを切り替える

$ git checkout master

今どのブランチで作業しているか確認

$ git branch

developをmasterにマージ

$ git merge develop

(例)developブランチをmasterにマージする場合

$ git branch
$ git checkout master
$ git branch
$ git merge develop
$ git push origin master

# キーの作成
ssh-keygen -t ed25519 -C email@example.com -f id_ed25519_email
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_email

### この時点で、作成した公開キーをgithub側に登録する

# sshで使う時のキーの設定
tee -a ~/.ssh/config <<'EOF' >/dev/null
Host github_email
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_email
IdentitiesOnly yes
AddKeysToAgent yes
EOF

# connect check!!
ssh -T -i ~/.ssh/id_ed25519_email github_email

# git clone
### git clone git@github:daijinload/test.git
git clone github_email:daijinload/test.git

# local account設定
git config --local user.name email
git config --local user.email email@example.com

### optional
# alias git-change-account-email='git config --local user.name email && git config --local user.email email@example.com'

一応、こんな感じでいける。

会社のアカウントと、個人アカウントを切り替えたい時などに使うと良いかと。

他にも色々と手があるみたいだが、この方法だと、

• cloneするときだけ意識すれば良い
• そこまで面倒なセットアップじゃない

ので、このくらいで良いかと。

切り替えたいaccountを、aliasにでも登録しておけば、clone時にセットするのが多少楽になるかと。

Gitバージョンの確認

　MacでGitを久しぶりに使うことになり、Gitの場所とバージョンを確認すると、バージョン2.3.5でした。

$ which git
/usr/local/git/bin/git

$ git --version
git version 2.3.5

　う〜ん。いつインストールしたか思い出せない。どうやらGitインストーラーでインストールしているようだ。
（参考）Gitインストール方法の違いによるGitパスは、以下のとおり

（標準のパス）
　　/usr/bin/git
（インストーラーでのGitのパス）
　　/usr/local/git/bin/git
（Home-brewでのGitのパス）
　　/usr/local/Cellar/git/(バージョン番号)/bin/git

Gitのアンインストール

　「Git アンインストール」でググると、「/usr/local/git」にある削除用スクリプト「uninstall.sh」で削除できると出てくるが、自分の環境にはありませんでした。（最近のインストーラーはあるのかも。確認していません。）
　このため、GitのＨＰからインストールされているバージョンのインストーラーのアーカイブをダウンロードして、dmg ファイルを開くと、その中に「uninstall.sh」があるので、以下のように実行します。

$ cd /Volumes/Git\ 2.3.5\ Mavericks\ Intel\ Universal 
$ sh ./uninstall.sh

　すると、

This will uninstall git by removing /usr/local/git/**/*, /etc/paths.d/git, /etc/manpaths.d/git
Type 'yes' if you are sure you wish to continue: yes
Password:
Forgot package 'GitOSX.Installer.git235Universal.git.pkg' on '/'.
Forgot package 'GitOSX.Installer.git235Universal.etc.pkg' on '/'.
Uninstalled

　アンインストールできました。

"No such file or directory"の対応

　ところが、バージョンを確認すると、

$ git --version
-bash: /usr/local/git/bin/git: No such file or directory

　「そんなものは無いよ」と言われてしまったので、which と type でファイルパスを確認するとズレている。このため、hash -r する。

$ which git
/usr/bin/git

$ type git
git is hashed (/usr/local/git/bin/git)

$ hash -r
$ git --version
git version 2.24.2 (Apple Git-127)

　最近のMacOS標準のGitは、新しいのか・・・（XcodeのアップデートでGitもアップデートされていたようだ）

「Git」に複数の脆弱性(2019.12.10)

　今回、ググっていると、こんなニュースがありました。
　「・・・2月10日にGit 2.24およびそれ以前のバージョンで複数の脆弱性が存在することが明らかに。最新バージョンにしましょう・・・」

最後に(home-brew)

　今後は、バージョン管理が面倒なので、home-brewでインストールして管理しようかと考えています。（home-brewでのGitインストール方法は、色々な方々が分かりやすく詳しく紹介されていますので、ここまでとします。）

Gitバージョンの確認

　MacでGitを久しぶりに使うことになり、Gitの場所とバージョンを確認すると、バージョン2.3.5でした。

$ which git
/usr/local/git/bin/git

$ git --version
git version 2.3.5

　う〜ん。いつインストールしたか思い出せない。どうやらGitインストーラーでインストールしているようだ。
（参考）Gitインストール方法の違いによるGitパスは、以下のとおり

（標準のパス）
　　/usr/bin/git
（インストーラーでのGitのパス）
　　/usr/local/git/bin/git
（Home-brewでのGitのパス）
　　/usr/local/Cellar/git/(バージョン番号)/bin/git

Gitのアンインストール

　「Git アンインストール」でググると、「/usr/local/git」にある削除用スクリプト「uninstall.sh」で削除できると出てくるが、自分の環境にはありませんでした。（最近のインストーラーはあるのかも。確認していません。）
　このため、GitのＨＰからインストールされているバージョンのインストーラーのアーカイブをダウンロードして、dmg ファイルを開くと、その中に「uninstall.sh」があるので、以下のように実行します。

$ cd /Volumes/Git\ 2.3.5\ Mavericks\ Intel\ Universal 
$ sh ./uninstall.sh

　すると、

This will uninstall git by removing /usr/local/git/**/*, /etc/paths.d/git, /etc/manpaths.d/git
Type 'yes' if you are sure you wish to continue: yes
Password:
Forgot package 'GitOSX.Installer.git235Universal.git.pkg' on '/'.
Forgot package 'GitOSX.Installer.git235Universal.etc.pkg' on '/'.
Uninstalled

　アンインストールできました。

"No such file or directory"の対応

　ところが、バージョンを確認すると、

$ git --version
-bash: /usr/local/git/bin/git: No such file or directory

　「そんなものは無いよ」と言われてしまったので、which と type でファイルパスを確認するとズレている。このため、hash -r する。

$ which git
/usr/bin/git

$ type git
git is hashed (/usr/local/git/bin/git)

$ hash -r
$ git --version
git version 2.24.2 (Apple Git-127)

　最近のMacOS標準のGitは、新しいのか・・・（XcodeのアップデートでGitもアップデートされていたようだ）

最後に(home-brew)

　今後は、バージョン管理が面倒なので、home-brewでインストールして管理しようかと考えています。（home-brewでのGitインストール方法は、色々な方々が詳しく紹介されていますので、ここまでとします。）

Gitバージョンの確認

　MacでGitを久しぶりに使うことになり、Gitの場所とバージョンを確認すると、バージョン2.3.5でした。

$ which git
/usr/local/git/bin/git

$ git --version
git version 2.3.5

　う〜ん。いつインストールしたか思い出せない。どうやらGitインストーラーでインストールしているようだ。
（参考）Gitのパスは、以下のとおり

（標準のパス）
　　/usr/bin/git
（インストーラーでのGitのパス）
　　/usr/local/git/bin/git
（Home-brewでのGitのパス）
　　/usr/local/Cellar/git/(バージョン番号)/bin/git

Gitのアンインストール

　「Git アンインストール」でググると、「/usr/local/git」にある削除用スクリプト「uninstall.sh」で削除できると出てくるが、自分の環境にはありませんでした。（最近のインストーラーはあるのかも。確認していません。）
　このため、GitのＨＰからインストールされているバージョンのインストーラーのアーカイブをダウンロードして、dmg ファイルを開くと、その中に「uninstall.sh」があるので、以下のように実行します。

$ cd /Volumes/Git\ 2.3.5\ Mavericks\ Intel\ Universal 
$ sh ./uninstall.sh

　すると、

This will uninstall git by removing /usr/local/git/**/*, /etc/paths.d/git, /etc/manpaths.d/git
Type 'yes' if you are sure you wish to continue: yes
Password:
Forgot package 'GitOSX.Installer.git235Universal.git.pkg' on '/'.
Forgot package 'GitOSX.Installer.git235Universal.etc.pkg' on '/'.
Uninstalled

　アンインストールできました。

"No such file or directory"の対応

　ところが、バージョンを確認すると、

$ git --version
-bash: /usr/local/git/bin/git: No such file or directory

　「そんなものは無いよ」と言われてしまったので、which と type でファイルパスを確認するとズレている。このため、hash -r する。

$ which git
/usr/bin/git

$ type git
git is hashed (/usr/local/git/bin/git)

$ hash -r
$ git --version
git version 2.24.2 (Apple Git-127)

　最近のMacOS標準のGitは、新しいのか・・・

「Git」に複数の脆弱性(2019.12.10)

　今回、ググっていると、こんなニュースがありました。
　「・・・2月10日にGit 2.24およびそれ以前のバージョンで複数の脆弱性が存在することが明らかに。最新バージョンにしましょう・・・」

最後に(home-brew)

　今後は、バージョン管理が面倒なので、home-brewでインストールして管理しようかと考えています。（home-brewでのGitインストール方法は、色々な方々が分かりやすく詳しく紹介されていますので、ここまでとします。）

はじめに

この記事では
バージョン管理システムのGitを
職場で使うことを想定して
Gitの使い方についてまとめた記事です。

今回はGit関連のサービスは使えないけど
リモートリポジトリは作成できる人向けに書きます。

ベストプラクティスや間違いがあれば
それなりに良い方法で書き直していきます。

---

あざやかにバージョン管理をキメたい

前回の内容に加えて
もしかするとこういうコマンドもあると
やりやすくなるのではというのがあったのでその続き

正直なところ職場だったら
Gitを操作できるGUIをクライアントを
導入すれば解決なんじゃないかと思われry

効率を最優先にとっても
ソフトを導入することは
あまり良い選択肢ではないと思います。

---

なにゆゑそう思うか

効率を最優先にとっても
ソフトを導入することは
あまり良い選択肢ではないと思います。

これは私の持論ですが主に理由は２つ

・ソフトを扱えることでその技術が扱えると勘違いする人が登場すること
・ソフトのサポート終了した瞬間その技術が使えなくなること

簡単に言えば
「GUIのソフトウェアがなければその技術を扱えない」

というハンデキャップをわざわざ負いに行くことはないんじゃないかな
ということと
ニッチな技術でとんがるより
みんなが愛してやまない技術を使ったほうが
自身の市場価値は測りやすいとも思うからです。

---

今回登場するコマンドー

$ git clone [リポジトリURL]
$ git push origin [ブランチ名]
$ git merge [ブランチ名]
$ git branch -D
$ git branch -d

---

想定される環境

客先常駐
GitHub使用不可
Windows10 Pro 64bit
Git 2.26.2.windows.1

---

想定される利用者

研修中のエンジニア（例えば、業務未経験者など）
初学者を教えるベテラン、中堅エンジニア

---

リポジトリのコピー(git clone)

リポジトリのURLと書きましたが
.gitフォルダのあるリポジトリのフォルダパスでも使えます。
たとえば、clone元のリポジトリ（test）が
別のディスクドライブ（仮にF:）にあるとき
以下のように入力することリポジトリをcloneできます。

$ git clone F:\test

---

cloneしたあと

clone後に
内容を変更してaddして
commitすると
変更されるリポジトリはどこでしょうか。

答えは簡単です。
clone先のリポジトリです。
このときclone元のリポジトリは変更されません。

---

clone元を更新したい

clone元を更新したいときはpushを使います。

例えば、clone元のリポジトリのmasterブランチを更新したいときは
カレントのリポジトリをcommitしたあと
以下のように入力すること更新できます。

$ git push origin master

---

改修とレビューのサイクルを作りたい

実際に作業する人とレビューする人に
分かれて作業するときのことを考えてみた。

---

作業者側

1.git clone
2.git branch -b test
3.コード改修
4.git add
5.git commit
6.git push

こうすることでclone元リポジトリには
testブランチという草が生える。

間違ってもmergeしないように！！！

---

レビュー者側

何をレビューするかについての議論が先かとは
思いますがこれについては
次回以降まとめます。

作業者側の作業が終わったと仮定して話を進めると

1.git clone
2.git merge
3.レビュー
4.git branch -d test
5.git push origin master

工程の3で問題がなければ4と5に進む
レビューNGならば作業者にもう一度、同じ手順を踏んでpushしてもらう。

---

この運用の問題点

・作業者がtestブランチを切り忘れたままcommitしてしまう可能性
・レビュー者がマージ完了後のtestブランチを削除し忘れる可能性

---

問題点その１

作業者がtestブランチを切り忘れたままcommitしてしまう可能性

これについては
作業者のフローである工程2の後に
git branchを叩くことで
ポカを回避できそう。

---

問題点その２

レビュー者がマージ完了後のtestブランチを削除し忘れる可能性

これについてはレビュー後か
merge後に
git branchを叩くことで
ポカを回避できそう。

---

まとめ

git branch めっちゃ大事なコマンドでは？？？

来月あたりから実際にこれで運用してみようと思います。

---

おわり

Git

gitとは、ソースコードを始めとするファイルの変更履歴を管理するためのシステム。
変更履歴を記録するシステムのことをバージョン管理システムと言う。
ファイルの変更履歴を管理することで、
何か問題があったときに過去のファイルに戻れるようにしておくことが利点。

Github

gitの仕組みを利用したwebサービスのこと。
gitの機能に対してチーム開発に便利な機能と付け加え、gitにおけるリモートリポジトリの役割も担っている。
github上にチームで共有のプロダクト（ソースコード）を配置し、開発者はgithub上からソースコードをコピーしたり、
ソースコードをgithub上のリポジトリに反映させることが出来る。

Github Desktop

gitを扱うためのGUIツールの一つです。
GUIツールとは、グラフィカルユーザインターフェースのことで、gitを扱う際に直感的な操作が出来るツールのことです。
github desktopは、githubが提供しているGUIツールです。

リポジトリ

リポジトリとは、変更履歴を管理しておくための入れ物。
このリポジトリにファイルやディレクトリの変更履歴を記録しておく。

ローカルリポジトリ

ローカルリポジトリとは、自分のPC上（ローカル環境）に置くリポジトリのこと。
自分のPC上にあるファイルやディレクトリのバージョン管理を行いたいときに使う。

リモートリポジトリ

外部のサーバーなどのネットワーク上に置くリポジトリのこと。
ネットワーク上に置くことで、複数人で管理下のファイルやディレクトリを共有することが出来る。
ローカル環境下で問題が起こったとしても、またリモートリポジトリからダウンロードを行うことで元に戻すことが出来る。

クローン

リモートリポジトリを複製してローカルリポジトリを作成すること。
クローンを行うとリモートリポジトリの内容をそのままダウンロードすることが出来る。

インデックス

インデックスとは、コミットをするファイルを登録するための場所。
ファイルをコミットすると、インデックスに登録されているファイル群の変更が記録される。
一度に多くのファイルを変更した際に、どのファイル単位でコミットするかを選択するために使用する。
インデックスに登録したファイル単位が一つのコミットとなるために、どのファイルをインデックスに登録するかを決める必要がある。

コミット

ディレクトリやファイルの状態を記録するための操作。
コミットすることで現在の状態が、日時や変更を加えた人の情報を含めて一緒に保存することが出来る。

コミットメッセージ

コミットメッセージとは、一つのコミットに対してつけるコメントのこと。
そのコミットでどのような作業をしたのかということを記録しておくために記述する。

プッシュ

ローカルリポジトリで加えた変更とリモートリポジトリに同期させること。
ローカルでコミットが終わり、リモートに変更を同期させたい場合には必ずプッシュを行う必要がある。

ブランチ

リポジトリで管理をしているプロジェクトの履歴の1つ。
自分の作業をしている場所のこと。
ブランチ同士は独立しているため、それぞれのブランチが干渉していない。
開発者ごとに担当する機能を明確に分けることが出来る
完成途中や問題のあるソースコードをリリースしないで済む。

プル

リモートリポジトリの変更履歴をローカルリポジトリに反映させる操作のこと。
他の開発者による変更がリモートリポジトリに反映された後や、自分でマージを行った際には必ずこのプルの作業を行う必要がある。

プルリクエスト

作成したブランチをmasterブランチにマージをするときの確認作業のこと。
ブランチ間の差分を他の開発者から確認やレビューを貰うということを行います。
そのコードに問題が無いかどうかを他の開発者や上司に確認を行うためにプルリクエストを見て貰います。

マージ

ブランチとブランチを結合すること。
結合する側のブランチを結合される側のブランチにマージを行うと、結合する側のブランチの内容が結合される側のブランチに反映される。

.gitignore

gitの管理対象から管理を外すためのファイルやディレクトリを指定するためのファイルです。
.gitignoreにファイルやディレクトリを指定すると、管理対象から外すことができます。
管理対象から外れるということは、githubにコードやファイルを同期させ無くて済むということです。
- アプリケーションのlogファイル
- 画像ファイル pulic/uploads 以下
- secrets.yml 等のセキュリティ上問題があるファイル
上記にあげたようなファイルを主にgitignoreに指定します。
これ以外にも、自分でgithubで公開したくないファイルも自分で指定をすることができます。

なぜaddしてcommitするのか

インデックスの概念が無い場合では、コードを書く作業とGitの操作とを行ったり来たりする必要がありそうです。これでは効率のいい仕事はできません。

インデックスの概念があれば、一気にコードを書いて、後からバージョンごとに選別する（インデックスに登録する）という流れが可能になります。コードを書く作業とGitの操作を行ったり来たりすることはなくなり、効率の良い仕事ができそうです。

自分のGitの使い方を公開します。
Gitを使った開発経験は現時点ではトータル1年未満です。
参考にしてほしいというより、こうしたほうがいいってアドバイスもらったりしたいです。
自分のレベル感としてはGitでプッシュする・プルするといった言葉の意味はわかりますが、お世辞にも使いこなせてるとは言えないです。

Sourcetree

https://www.sourcetreeapp.com/
やっぱりGUI環境はあったほうがいいよね？ってことで入れています。
リリースとかマージするとき（ミスできない作業をするとき）使うことが多いように思います。
コマンドラインで更新作業をするのは少し怖いです。

VSCode

開発作業（コーディング）をする中で必要なことはVSCode上からやります。
ブランチの切り替え、コミット、プッシュなどを主にやっていると思います。
簡単な確認作業も拡張機能のおかげでできています。

使っている拡張機能

・GitLens
https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens

・Git History
https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory

・Git Blame
https://marketplace.visualstudio.com/items?itemName=waderyan.gitblame

・Git Graph
https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph

VSCodeをあまり使いこなせていないのですが、慣れればSourcetreeでやっているような作業もできると思います。
最近使い分けするのが少し面倒になっているのが正直なところです。

コマンドライン

VSCodeのpowershellとかGit bashから操作します。
主な使いみちとしては検索作業です。
漏れがないかとかを確認するのにGUIとかの線を一本一本追ってられません。
VSCodeのターミナルから実行したりするのでVSCodeからやってるやん！！ってなるけどそこは気にしない。

主に使うコマンドは以下のような感じ

#マージ済みのブランチを確認
$ git branch --merged

#マージ漏れの確認
$ git branch --no-merged

#開発ブランチマスターにマージする前に変更内容を確認
$ git log --oneline --no-merges origin/master..開発ブランチ名

#変更したファイル名の一覧を取得
$ git diff --name-only ブランチ名 

目的

タスクの作業途中にレビュー依頼を受けた時のコマンドをまとめました。
深夜テンションで書いたのでおかしいところがあったらコメントにて教えてください?

環境

$ git --version
git version 2.26.2

1. まずはコミットする

$ git status
$ git diff

$ git add
$ git commit

のコマンドを駆使してコミットできるものはコミットします。

2. 編集途中のコードを一時的に退避する

$ git stash -u

急いでレビューしたい時はスタッシュで退避させておきます。
-u オプションを指定すると untracked file も含めて退避します。

3. 退避した内容を確認する

$ git stash list
$ git stash show -p

Gitのことを信頼してるので、あまり内容を確認することはないです。

4. ローカルリポジトリを最新の状態にする

$ git fetch

これを忘れるとレビューするブランチ見つからないやん?ってなります。

5. レビューしたいブランチに切り替える

$ git switch xxxxx

ローカルリポジトリを最新の状態に更新して、レビューしたいブランチに切り替えます。(checkout は使わないゾという強い意志)

6. レビューする

魚の骨が喉につっかえてしまうようなコードがないか確認して問題なければLGTMです。
レビューする時に使うコマンドを補足でご紹介します。

レビュー用にウェブ設計チェックリスト作りました。チェックリストとソースコードを照らし合わせてレビューします。

補足: git log

コミットのログを表示します。

$ git log
$ git log --one-line
$ git -P log --one-line

-P Git全般のオプションですが、ページャーなしで一気に表示します。地味に便利かもです。

$ git log --oneline --graph --decorate --name-status

オプション指定すれば良いってもんじゃないですけど、git log のオプションめちゃくちゃいっぱいあります。

• --one-line 1コミット1行で表示
• --graph グラフっぽい表示
• --decorate ブランチ名、タグ名等の別名表示
• --name-status ファイル名を表示

参考: git log よく使うオプションまとめ

補足: git show

$ git show
$ git show -1
$ git show -2
$ git show -3

git show と git show -1 は同じく最新のコミットの内容を表示します。
数値の代わりにハッシュ値を指定してもokです。

補足: git diff

$ git diff master
$ git diff master --name-only

他のブランチとの差分を見ることができます。
1個1個のコミットを見るのめんどいよって方はこちら。

--name-only 差分のあるファイル名のみ一覧表示

$ git diff master --color=always | less -R

git diff の結果を less を使って表示したい時はこんな感じで表示します。オプションを付けないとうまく色付け表示できないので注意です。

補足: git grep

ワークツリー内の検索をします。
.gitignore に登録してあるファイルは除外されるので便利です。

$ git grep -np 検索したいワード

-n 検索に一致した行数を表示
-p 検索に一致した行の前にある関数名を表示

git grep を使う

補足: git blame

$ git blame ファイル名

リポジトリで管理されているファイル内の行ごとの最終更新を見れます。
行ごとのコミット(ハッシュ値)、コミッター、更新日が分かるよ。
問題が起きたとき等でどのコミットで変更されたかを探すなどするときに便利です。(犯人探しには絶対に使わないでください。大体犯人は自分です)

• https://lgtmoon.herokuapp.com
• http://hackason-lgtm-front.s3-website-ap-northeast-1.amazonaws.com/

この辺りのサイトからレビュイーの趣味趣向合いそうな最高のLGTM画像を探します。
一番時間を使うところです。ここは全力で探しましょう。

補足: 結局のところ...

GitHubの差分表示が優秀すぎるのでコマンド打つ必要ないのかも?

7. 再び自分のブランチに戻る

$ git switch -

ブランチ名を指定してもいいですが入力するのも思い出すのも面倒です。
- で一つ前のブランチに戻れます。

8. 退避しておいたコードを元に戻す

$ git stash pop

最新のスタッシュから退避させておいたコードを戻します。
いい感じのコードを書けたらコミットしてプッシュします。

9. コミットしてプッシュする

$ git add
$ git commit
$ git push -u origin HEAD

レビューする時は大体この流れでやってます。

Git関連の記事まとめ

• Git関連の記事一覧

参考記事

• サル先生のGit入門

お題

以下の記事をトレースするだけ。
https://cloud.google.com/solutions/managing-infrastructure-as-code?hl=ja

前提

以下の記事でのセットアップが完了していること。
https://qiita.com/sky0621/items/c488e8adb2a51870ad22

以下については知識があるものとしてやり方や概念など説明しない。

• GitHubでのフォークのやり方
• GCS(Cloud Storage)

開発環境

# OS - Linux(Ubuntu)

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"

# Git

$ git version
git version 2.26.2

# Terraform

$ terraform version
Terraform v0.12.25

# gcloud

$ gcloud version
Google Cloud SDK 294.0.0

実践

■ アーキテクチャ

以下に記載の通り、「dev」と「prod」という（実際の開発現場ならもうひとつ「stg」もあるかも）構成。
https://cloud.google.com/solutions/managing-infrastructure-as-code?hl=ja#architecture

■ 使用リポジトリ

以下をフォーク。
https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops

で、ローカル（作業端末）にクローンしておく。
ディレクトリ構成は以下の通り。

$ tree
.
├── cloudbuild.yaml
├── environments
│   ├── dev
│   │   ├── backend.tf
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   ├── terraform.tfvars
│   │   ├── variables.tf
│   │   └── versions.tf
│   └── prod
│       ├── backend.tf
│       ├── main.tf
│       ├── outputs.tf
│       ├── terraform.tfvars
│       ├── variables.tf
│       └── versions.tf
└── modules
    ├── firewall
    │   ├── main.tf
    │   ├── outputs.tf
    │   ├── variables.tf
    │   └── versions.tf
    ├── http_server
    │   ├── main.tf
    │   ├── outputs.tf
    │   ├── variables.tf
    │   └── versions.tf
    └── vpc
        ├── main.tf
        ├── outputs.tf
        ├── variables.tf
        └── versions.tf

以降、上記のディレクトリ構造であることを前提とする。

■ 状態の保存先をGCSバケットに変更

terraform.tfstate（インフラ構築状態が保存されているファイル）の格納先をローカルからGCSバケット内に変更。

GCSバケット作成

GCPプロジェクトIDを名前の一部に含むバケット名を作るとバケット名の重複が防げる。

$ env | grep GOOGLE
GOOGLE_CREDENTIALS=/home/sky0621/.config/gcloud/my-gcp-prj-01-terraform-credential.json
GOOGLE_PROJECT=my-gcp-prj-01
$
$ gsutil mb -l asia-northeast1 gs://${GOOGLE_PROJECT}-tfstate
Creating gs://my-gcp-prj-01-tfstate/...

あと、デプロイ履歴を保持できるようにしておく。

$ gsutil versioning set on gs://${GOOGLE_PROJECT}-tfstate
Enabling versioning for gs://my-gcp-prj-01-tfstate/...

backend.tf ファイルの修正

terraform.tfstateの格納先の指定はbackend.tfファイルで行っているので、dev と prod それぞれの環境別に置いてある当該ファイルを修正。
修正後は以下のようになる。

environments/dev/backend.tf

terraform {
  backend "gcs" {
    bucket = "${GOOGLE_PROJECT}-tfstate"
    prefix = "env/dev"
  }
}

※ environments/prod/backend.tf の方も同様に修正。

terraform.tfvars ファイルの修正

dev と prod それぞれの環境において、定義時にGCPプロジェクトIDの指定が必要になる箇所が複数ある。
そのため、変数として定義しておいて、必要になる箇所ではその変数を参照する記述にしてある。
変数が定義されているのは、terraform.tfvars ファイル。
この中も以下のように環境変数からGCPプロジェクトIDを参照するように修正する。

environments/dev/terraform.tfvars

project="${GOOGLE_PROJECT}"

ここまでの状況をGitHub上のリポジトリにPush

$ git status
ブランチ dev
Your branch is up to date with 'origin/dev'.

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:   environments/dev/backend.tf
    modified:   environments/dev/terraform.tfvars
    modified:   environments/prod/backend.tf
    modified:   environments/prod/terraform.tfvars

$ git add -A

$ git status
ブランチ dev
Your branch is up to date with 'origin/dev'.

コミット予定の変更点:
  (use "git restore --staged <file>..." to unstage)
    modified:   environments/dev/backend.tf
    modified:   environments/dev/terraform.tfvars
    modified:   environments/prod/backend.tf
    modified:   environments/prod/terraform.tfvars

$ git commit -m "Update project IDs and buckets"
[dev 6c54e5f] Update project IDs and buckets
 5 files changed, 8 insertions(+), 5 deletions(-)

$ git status
ブランチ dev
このブランチは 'origin/dev' よりも1コミット進んでいます。
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

$ git push origin dev
Enumerating objects: 17, done.
Counting objects: 100% (17/17), done.
Delta compression using up to 4 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (9/9), 750 bytes | 375.00 KiB/s, done.
Total 9 (delta 5), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (5/5), completed with 4 local objects.
To github.com:sky0621/solutions-terraform-cloudbuild-gitops.git
   bf83e89..6c54e5f  dev -> dev

■ Cloud Build 関連の設定

API使えるようにしておく

$ gcloud services enable cloudbuild.googleapis.com
Operation "operations/xxx.99999999-xxxx-999-xxxx-99999999" finished successfully.

Cloud Build サービスアカウントに権限を付与

元記事でも記載があるけど、「とりあえず roles/editor をつけているものの本来なら必要最小限なロールを付与すべき」とあるので実際の開発現場では留意すべき。

サービスアカウントの情報を得る

プロジェクト自体の情報

$ gcloud projects describe ${GOOGLE_PROJECT}
createTime: '2020-05-27T15:19:59.167Z'
lifecycleState: ACTIVE
name: My Project 19162
projectId: my-gcp-prj-01
projectNumber: '999999999999'

プロジェクトナンバー部分を抜粋

$ gcloud projects describe ${GOOGLE_PROJECT} --format 'value(projectNumber)'
999999999999

上記ナンバーを含むCloud Build サービスアカウントのメアドを環境変数にセット

$ export CLOUDBUILD_SA="$(gcloud projects describe ${GOOGLE_PROJECT} --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"
$
$ env | grep CLOUDBUILD_SA
CLOUDBUILD_SA=999999999999@cloudbuild.gserviceaccount.com

ロール付与

$ gcloud projects add-iam-policy-binding ${GOOGLE_PROJECT} --member serviceAccount:${CLOUDBUILD_SA} --role roles/editor
Updated IAM policy for project [my-gcp-prj-01].
bindings:
　　　〜〜〜
  - serviceAccount:999999999999@cloudbuild.gserviceaccount.com
  role: roles/editor
　　　〜〜〜

Cloud Build を GitHub リポジトリに接続

以下を参照しながら。
https://cloud.google.com/solutions/managing-infrastructure-as-code?hl=ja#directly_connecting_cloud_build_to_your_github_repository

Cloud Build アプリの GitHub Marketplace ページにアクセス

https://github.com/marketplace/google-cloud-build

ちなみに、下記とのこと。

Cloud Buildは、無料枠を超えるビルド1分あたりの料金です。
1日120分の無料ビルド分。その後$ 0.003 /分。
最大10の同時ビルドが含まれます。
ビルドされたイメージをGoogle Container Registryに自動的にプッシュします（ストレージコストがかかる場合があります）。
詳細については、Cloud Buildの料金ページをご覧ください。
https://cloud.google.com/cloud-build/pricing

終わった様子。

■ ソースの変更によるCloud Build発動を確認

ローカルでソース修正しリモートにPush

$ pwd
/home/sky0621/work/src/github.com/sky0621/solutions-terraform-cloudbuild-gitops
$
$ git branch
* dev
$

フォーク元リポジトリで（学習用に）タイプミスされていたファイルを修正。

$ git diff
diff --git a/modules/firewall/main.tf b/modules/firewall/main.tf
index 5e40f70..1d2e549 100644
--- a/modules/firewall/main.tf
+++ b/modules/firewall/main.tf
@@ -27,6 +27,6 @@ resource "google_compute_firewall" "allow-http" {
     ports    = ["80"]
   }

-  target_tags   = ["http-server2"]
+  target_tags   = ["http-server"]
   source_ranges = ["0.0.0.0/0"]
 }

上記バグ修正のコミット用にブランチを切って、上記の内容を反映。

$ git checkout -b bugfix origin/dev
M   modules/firewall/main.tf
Branch 'bugfix' set up to track remote branch 'dev' from 'origin'.
Switched to a new branch 'bugfix'
$
$ git branch
* bugfix
  dev
$
$ git add .
$
$ git status
ブランチ bugfix
Your branch is up to date with 'origin/dev'.

コミット予定の変更点:
  (use "git restore --staged <file>..." to unstage)
    modified:   modules/firewall/main.tf
$
$ git commit -m "http ファイアウォール ターゲットの修正"
[bugfix 82e283a] http ファイアウォール ターゲットの修正
 1 file changed, 1 insertion(+), 1 deletion(-)
$
$ git status
ブランチ bugfix
このブランチは 'origin/dev' よりも1コミット進んでいます。
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
$
$ git push -u origin bugfix
Enumerating objects: 9, done.
　　〜〜〜
To github.com:sky0621/solutions-terraform-cloudbuild-gitops.git
 * [new branch]      bugfix -> bugfix
Branch 'bugfix' set up to track remote branch 'bugfix' from 'origin'.

作成したバグ修正ブランチを dev ブランチにマージ

あれっ、Cloud Buildのとこで失敗してる？
というわけで、詳細を見に行く。

これでもよくわからないので、Cloud Build側のページへ飛ぶ。

terraform init で失敗してるのかな。
「生データを表示」してみると、

Step #1 - "tf init": [0m[1mInitializing the backend...[0m
Step #1 - "tf init": [31mError loading backend config: 1 error occurred:
Step #1 - "tf init":    * terraform.backend: configuration cannot contain interpolations
Step #1 - "tf init": 
Step #1 - "tf init": The backend configuration is loaded by Terraform extremely early, before
Step #1 - "tf init": the core of Terraform can be initialized. This is necessary because the backend
Step #1 - "tf init": dictates the behavior of that core. The core is what handles interpolation
Step #1 - "tf init": processing. Because of this, interpolations cannot be used in backend
Step #1 - "tf init": configuration.
Step #1 - "tf init": 
Step #1 - "tf init": If you'd like to parameterize backend configuration, we recommend using
Step #1 - "tf init": partial configuration with the "-backend-config" flag to "terraform init".
Step #1 - "tf init": 
Step #1 - "tf init": [0m[0m
Finished Step #1 - "tf init"
ERROR
ERROR: build step 1 "hashicorp/terraform:0.11.14" failed: step exited with non-zero status: 1

「terraform.backend: configuration cannot contain interpolations」とのこと。
ググる。
https://qiita.com/aoshimash/items/f0be7dd81c856d335460
backend.tfで変数使えない様子。。。
しょうがないので変数使わず、再度Push。

お、先ほどはすぐに失敗したけど、しばらく継続してる様子。

成功した。
詳細を見てみる。

失敗時にも出ていたけど、以下に記載の４つのステップが実行されたログとなっている。
https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops/blob/master/cloudbuild.yaml
つまり、terraform apply までされているので、うまくいっているなら、適用対象のGCPプロジェクトにTerraformの定義が反映されているはず。

なのだけど、よくよくログを見ると、

そう、今回、bugfix ブランチから dev ブランチへのプルリクは作ったけど、まだマージしてない。
このCloud Buildログは、あくまで bugfix ブランチが出来たから流されたもので、設定としては dev と prod 以外は terraform apply はしないものとなっているので、実際にGCP環境には適用されていない。

では、プルリクをマージして、dev ブランチを更新してみる。

はい、マージ完了。
Cloud Build側でビルド状況を確認してみる。

すると、devブランチに更新がかかったゆえの実行中ビルドが増えている。

完了後のログ詳細を見てみると、

今度は、スキップされずに terraform apply が実行されている。

■ 反映結果の確認

まずは、Terraform実行による状態管理をCloud Storage上で行う設定にしたので、その確認。

うん、tfstate ファイルが格納されている。

うまくいっているなら、以下が出来ているはず。

• VPC
• Firewall
• Compute Engine

それぞれ出来ておる。

まとめ

参考記事では、このあと、「Cloud Build の実行が成功した場合にのみマージを適用できるようにする」対応や本番環境の方への適用などもやっているけど、ちょっと力尽きたので今回はこのへんでおしまい。

概要

この記事は私の知識をより確実なものにするためにRailsチュートリアル解説記事を書くことで理解を深め
勉強の一環としています。稀にとんでもない内容や間違えた内容が書いてあるかもしれませんので
ご了承ください。
できればそれとなく教えてくれますと幸いです・・・

出典
Railsチュートリアル

MVCとは

MVCとは
Model　View　Controller　を略したものである

Railsチュートリアル第1章より
https://railstutorial.jp/chapters/beginning?version=6.0#sec-mvc

図の通りブラウザからリクエストがあるとコントローラがリクエストを受け取り
必要なデータはモデルを通してデータベースを照会し、Viewを出力することでページを表示する

ルートルーティングの設定

config/routes.rb 内に

root 'controller_name#action_name'

と記述することで指定したコントローラーのアクションをルートURLとして参照する　

演習

1.application_controller.rbをこのように書き換える

application_controller.rb

class ApplicationController < ActionController::Base
  def hello 
    render html: "hello, world!"
  end
end

2.省略
3.①application_controller.rbにgoodbyeアクションを追加

application_controller.rb

class ApplicationController < ActionController::Base
  def hello 
    render html: "hello, world!"
  end

  def goodbye
    render html: "goodbye!!!!!!!!!!!!!!!!!!!"
  end
end

②routes.rbを書き換えルーティングをgoodbyeアクションへ変更

routes.rb

Rails.application.routes.draw do
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
  root "application#goodbye"
end

Gitによるバージョン管理

Cloud9を使っているならばGitのインストールは不要

初期設定

初回のみ初期設定を行う

1.名前とメールアドレスを登録

$ git config --global user.name "自分の名前"
$ git config --global user.email your.email@example.com

2.Gitで使うデフォルトのエディタを設定
今回の場合はnanoエディタを使う
$ sudo ln -sf `which nano` /usr/binを実行

3.エイリアスを設定（しなくてもOK）
git checkout コマンドを今後省略形の　git co で使いたい場合は
設定する
$ git config --global alias.co checkoutを実行

4.Gitパスワードの保持時間の変更
以降使うことになるpushコマンドなどでパスワードを入力する手間を省くためにパスワードの保持時間を設定する
意識高い人は設定しなくても良い。デフォルトの保持時間は900秒

リポジトリセットアップ

1. git initでリポジトリを初期化する
2. git add -Aで全てのファイルをステージングに追加
3. git commit -m "Initialize repository"でaddしたファイルをコミットする

ここまでがGitの基本的な流れ（ここまではまだローカルマシンでしか保存されていない）

このようにバージョン管理を行うことで以前の状況まで戻りたい時などに
戻れる（超重要！）

↑の作業でローカルマシン上ではコミットしたのでネットワーク上（リモートという）にアップする
リモートにアップすることで完全なバックアップができ、他の作業者とのソースコードの共有が容易になる
リモートでよく使われるものにGithubやBitbucketなどがある
今回はGithubを使用してリモートへアップしてみる

まずはGithubのアカウントを作成し、
新規のリモートリポジトリを作成する

ローカルリポジトリを今作成したリモートリポジトリにアップするコマンドを表示してくれているので
コピーしてターミナルにそのままはりつける

初回はユーザーネームとパスワードの入力を求められる

ちなみにCloud9ではパスワードが入力できない問題があり、私はそれでGithubではなくBitbucketを当初使っていました…

コンソールに文字の入力ができなくなる
https://teratail.com/questions/106094

パスワードがセキュリティ対策で表示されなかっただけですね…?

ブランチ

gitではブランチというものを扱う。ブランチはリポジトリのコピーで都度使い分けることで
変更や実験を自由に試すことができる
通常、親リポジトリはmasterブランチと呼ばれ（デフォルトはこれ）、今回はREADME.mdを編集するための
お試しブランチとしてmodify-READMEブランチを作成して作業することにする
トピックブランチはgit checkout -b modify-READMEで作成できる
※gitの初期設定でエイリアスを設定していた場合はgit co -b modify-READMEでもOK

$ git checkout -b modify-README 
Switched to a new branch 'modify-README'

ちなみにブランチ一覧はgit branchで表示される
*がついたブランチが現在のブランチ

$ git branch
  master
* modify-README

ブランチを作成したのでREADME.mdをさっそく編集

README.md

# Ruby on Rails Tutorial

## "hello, world!"

This is the first application for the
[*Ruby on Rails Tutorial*](https://railstutorial.jp/)
by [Michael Hartl](https://www.michaelhartl.com/). Hello, world!

編集が終わったらさっそくローカルリポジトリにコミットしてみる
流れとしてはgit add -Aでステージングしてから、git commit -m "~~~~"コミットである。
git commmit -a -m "~~~~"とするとステージングも含めて一緒にやってくれるので便利。
※-aオプションはステージングはしてくれるがバージョン管理下に置く機能はないため
バージョン管理下に置かれていないファイルはgit addでバージョン管理下に置く必要がある。
-aオプションを使えばいいというわけではない

merge(マージ)

ファイルの変更が終わり、modify-READMEブランチでコミットしたので
親リポジトリ（masterブランチ）に反映させたい。
他のブランチの内容を現在のブランチに上書きすることをmerge(マージ)と言う。

手順としては、masterブランチにmodify-READMEブランチを反映させたいので
masterブランチに移動→現在のブランチ(masterブランチ)にmodify-READMEブランチをマージとなる
この手順をコマンドで入力した結果がこちら

$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$ git merge modify-README
Updating 392f440..28a415b
Fast-forward
 README.md | 27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

git checkout masterでmasterブランチに移動後
git merge modify-READMEでmasterブランチにmodify-READMEの内容をmergeしている。

トピックブランチを削除することもできるが、必須ではないためここでは省略。

Push

先ほどローカルでmasterブランチに変更をマージしたのでこれらのファイルをリモートリポジトリにアップする。
このリモートにアップする作業をPushという。
最初の段階でgit push -u origin masterをしているので今回はgit pushで問題ない。

git pushで問題ない理由

この段階では難しいので、興味がなければスルーしても問題ないですが、
git push -u origin master　の意味について書いておきます。
このコマンドではローカルのmasterブランチで最後にコミットされた内容を
リモートのoriginにpushしますよ！というコマンド。
-uというのはmasterの上流ブランチにoriginを設定しますよというオプション。
まあ簡単に言うと-uで指定するとmasterのデフォルトのpush先がoriginになるため
一度このコマンドでプッシュした後はgit pushだけでデフォルトのプッシュ先
originにmasterの内容をプッシュしてくれるということ。

デプロイする

デプロイの準備①

ここまでで一連の流れが終了した。
ファイルを作成→編集→リモートにプッシュ
とりあえず試しで本番環境にデプロイしてみる。
使用するのは手軽なHeroku

使う前に、現在導入しているSQLiteはHerokuではサポートしていないため、
本番環境ではHerokuがサポートしているPostgreSQLを使うよう、Gemファイルを書き換える。

Gemfile

source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

gem 'rails',      '6.0.3'
gem 'puma',       '4.3.4'
gem 'sass-rails', '5.1.0'
gem 'webpacker',  '4.0.7'
gem 'turbolinks', '5.2.0'
gem 'jbuilder',   '2.9.1'
gem 'bootsnap',   '1.4.5', require: false

group :development, :test do
  gem 'sqlite3', '1.4.1'
  gem 'byebug',  '11.0.1', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  gem 'web-console',           '4.0.1'
  gem 'listen',                '3.1.5'
  gem 'spring',                '2.1.0'
  gem 'spring-watcher-listen', '2.0.1'
end

group :test do
  gem 'capybara',           '3.28.0'
  gem 'selenium-webdriver', '3.142.4'
  gem 'webdrivers',         '4.1.2'
end

group :production do
  gem 'pg', '1.1.4'
end

# Windows ではタイムゾーン情報用の tzinfo-data gem を含める必要があります
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

bundle install --without productionで本番環境gem以外をインストールする
ローカル環境ではもともとdevelopment環境のためproduction環境のgemは影響しないが
ここでproductionに対してgemを追加したことやRubyバージョンを指定したことをGemfile.lockに
反映させないと、本番環境デプロイで失敗する。

この段階で今の変更もコミットしておく

$ git commit -a -m "Update Gemfile for Heroku"

デプロイの準備②

次に、Herokuのアカウントを作成する。→ Herokuアカウント作成
続いて、Heroku CLI(Command Line Interface)をインストールする。
Cloud9を使っているならば次のコマンドで即インストール可能だ。

$ source <(curl -sL https://cdn.learnenough.com/heroku_install)

Heroku CLIがインストールできたがどうかは
heroku -vでHerokuのバージョン情報が表示できれば確認できる。

インストールが確認できたらHerokuコマンドで先ほど作成したアカウントにログインする

$ heroku login --interactive

次に

$ heroku create

を実行し、Herokuサーバー上に今回作成したアプリケーションの実行場所を作成する。
これで、デプロイしたらブラウザで表示可能になる。

あとはGitを使ってherokuにプッシュすればデプロイできる。

git push heroku master

ここまでやれば、heroku createコマンドで生成されたアドレスを開けば
hello_appが公開されている。

演習

1. application_controllerのhelloアクションを書き換え、もう一度今の変更をプッシュする。
2. routes.rbのrootURLをgoodbyeアクションに変更し、もう一度今の変更をプッシュする

Herokuコマンドについて

herokuには他にも様々なコマンドが用意されている。
heroku renameコマンドではアプリケーションの名前を変更することができる。
実際は自動で生成されるデフォルトアドレスで十分。
RailsチュートリアルもHeroku上に置かれている。
このような独自ドメインも使用可能。

演習

1. heroku helpまたはheroku -hでコマンド一覧を表示する。 Herokuのログは heroku logsで参照可能
2. herokuアプリのアクセスログやエラーログなど様々なログが確認できる

第一章のまとめ

• RailsはRubyのフレームワーク。
• クラウド環境(Cloud9)はRubyなどの環境があらかじめインストールされているのに加え 　環境の設定も容易でOSが違っても使用できる超有能ツール(環境による差異がない)

• rails コマンドを使えばrails の様々な機能が使える

  • rails server　→ローカルサーバーを立てる
  • rails console　→railsのコンソールを起動する
  • rails new　→railsのアプリを新規で作成する
  • rails generate　→railsのファイルを作成する(モデル・コントローラなど様々)

• RailsやHerokuを組み合わせることでhello_app程度なら一瞬で作れる。超便利。

• データの喪失を防止、複数の作業者と共同作業を行えるようにするため、Gitを使って
  　バージョン管理を行う。さらにはGitHubの非公開リポジトリにプッシュする。

• 作成したアプリケーションはHerokuを使って簡単にデプロイできる。