バリデーションの記述方法
お疲れ様です！
IHです！
さて、久しぶりにブログの方でもアウトプットをしていきたいと思います！
今日はバリデーションについて学びがあったので、簡単に振り返ります！
ーーーーーーーーーーーーーーーー
本日は、最終課題でユーザー管理機能の実装をしており、
app/models/user.rbに、以下のようなバリデーションの記述をしていたところ、メンターさんに修正するよう言われました。
＊
validates :nickname, presence: true, uniqueness: true
validates :birth_day, presence: true
with_options presence: true, format: { with: /\A[ぁ-んァ-ン一-龥]+\z/, message: 'Full-width characters' } do
validates :first_name
validates :family_name
end
with_options presence: true, format: { with: /\A[ァ-ン]+\z/, message: 'Full-width katakana characters' } do
validates :first_name_furigana
validates :family_name_furigana
end
＊
簡単にいうと、以下のような制限をかけています。
・まず、全てのカラムに「空欄では保存できない」という制限をかけている
・nicknameカラムには「既に保存されている、他ユーザーのニックネームと重複していれば保存できない」という制限もかけている
・first_nameカラムとfamily_nameカラムには「全角のデータのみ保存する」という制限もかけている
・first_nameカラムとfamily_nameカラムには「全角のカタカナのみ保存する」という制限もかけている
ローカル環境で試したところ、この記述でも問題なく制限が働いているようです。
このままメンターさんにコードレビュー依頼をしました。
しかし、メンターさんには
「これでは読みづらいので、「with_options presence: true ~ end」の中に、バリデーションを記述しましょう。オプションは、各カラム毎につけてください」
といったアドバイスをいただき、記述例も見せていただきました。
確かに、可読性という点では難ありな記述ですねー。
そういうわけで、以下のように記述を変えました。
＊
with_options presence: true do
validates :nickname, uniqueness: true
validates :birth_day
validates :first_name, format: {with: /\A[ぁ-んァ-ンー-龥]+\z/, message: 'Full-width characters'}
validates :family_name, format: {with: /\A[ぁ-んァ-ン一-龥]+\z/, message: 'Full-width characters'}
validates :first_name_furigana, format: {with: /\A[ァ-ン]+\z/, message: 'Full-width katakana characters'}
validates :family_name_furigana, format: {with: /\A[ァ-ン]+\z/, message: 'Full-width katakana characters'}
end
＊
いかがでしょう？
確かにひとまとめにすることで、ごちゃごちゃ感はだいぶなくなりましたね。
以上のような記述に修正すると、メンターさんにLGTMをいただくことが出来ました！
今後は
「動けばいい！」
ではなく
「他の人から見ても読みやすいコードを書けているか？」
ということを意識していかないとなぁ、と感じた一日でした。
ーーーーーーーーーーーーーーーー
いかがでしたか？
これから現場で働くにあたって、
「読みやすいコードかどうか？」
は非常に大事な要素ですものね。
今後は可読性も注意しながら最終課題の制作に当たりたいと思います！
それでは、本日はこの辺で！
ここまで読んでくださりありがとうございました！
セキュリティ攻撃について(JavaScript)
お疲れ様です！
IHです！
今日は、JavaScriptによるセキュリティ攻撃について学んだので、アウトプットを行いたいと思います！
ーーーーーーーーーーーーーーーー
Webアプリケーションに脆弱性があると、ユーザーと開発者の双方が被害を受けます。
脆弱性とは、ソフトウェアに欠陥や使用上の問題点のことをいいます。いわば、そのWebアプリケーションの抱える弱点です。
そして、悪意を持ったユーザー(攻撃者)が、この脆弱性につけ込んで、アプリケーション上で攻撃を仕掛けることがあります。
本日学んだ、その攻撃の種類は
順番に説明していきます。
クロスサイトスクリプティング(以下XSS)とは、攻撃者が脆弱性を持っているサイトを利用して、そのサイトの利用者を攻撃する手法のこと。
具体的な攻撃の流れは以下の通りです。
①XSSの脆弱性があるサイトに悪意のあるJavaScriptを埋め込む
②JavaScriptを埋め込んだサイトをリンクに指定する罠サイトを用意する
③罠サイトへ誘導するようなメールを送信する
④ユーザーは、メールに添付された罠サイトにアクセスし、JavaScriptを埋め込んだサイトにアクセスする
⑤ブラウザ上で埋め込まれたJavaScriptが実行される
⑥クッキーの盗聴やマルウェア感染が起きてしまう！
※罠サイトとは、JavaScriptを埋め込んだXSSの脆弱性のあるサイトへのリンクを含んでいるページのこと。
※スクリプトとは「ソースコードを書く→実行する」ということができる、簡易的なプログラムのこと。
TwitterやYoutubeも、過去にXSSによる被害を被ったそうです。
Twitterでは
「特定のツイートをマウスオーバー(マウスカーソルを対象に重ねること)するだけで、埋め込まれたJavaScriptが実行され、勝手にリツイートされる」
という被害が出て、
YouTubeではコメント欄に存在した脆弱性を狙って、コメント欄にJavaScriptが仕掛けられ、
「コメントが表示されなくなる」
「偽のニュースが表示される」
「不適切なウェブサイトへリダイレクトされる」
といった被害が出たそうです。
XSSが発生する主な原因として、フォームから入力されたHTMLタグがそのままページに反映されてしまっていることがあげられます。
したがって、HTMLを生成する際に意味を持つ「"」や「<」、「>」といった表記を違う文字列に変換することで、XSSを防ぐことができます。このように、HTML上で直接記述できない特殊文字を表記する際に用いられる記法を「文字参照」といいます。
文字参照を利用することで、たとえば
「<」は「& It;」
「>」は「& gt;」
「"」は「& quot;」
「'」は「& #39;」
「&」は「& amp;」
に変換することができます。(上記は、XSSの対策をする際に変換すべき特殊文字の一覧です)
以上のような特殊文字を文字列参照に変換して保存すれば、外部から埋め込まれたスクリプトが実行されることはなくなります。
「Webページのテキスト入力欄」
「URL」
などにSQL分の断片を埋め込むことで、データベースの改竄や、情報の不正入手を行う攻撃方法がSQLインジェクションです。
つまり、入力フォームから送信した値によりアプリケーションが想定しないSQL文を実行させることで、
「認証を突破する」
「情報を盗む」
といったことを可能にします。
SQLインジェクションの脆弱性を解消するには、SQL文の変更を防ぐ必要があります。
対策方法としては、以下があるそうです。
・事前にSQL文の構造を確定する
このSQLインジェクションについては理解が浅く、データベース言語の一つであるSQLも学習していないので、今後学習をしていきたいと考えています。
まず、セッションとは、Webサービスにおいて情報を一時的に記憶しておく仕組みのことです。
ショッピングサイトにも利用されています。
(たとえば、Amazonで買い物カゴに商品を入れた時、「買い物カゴには○○という商品が入っている」という状態が維持されているのは、このセッションのおかげです)
セッションハイジャックとは、何らかの方法を用いて、正規利用者ではない者が他人のセッションIDを乗っ取る攻撃方法です。
このセッションハイジャック、非常に恐ろしいです。
これが成功してしまうと、正規利用者ができることがほとんど実行できてしまいます。
具体的には、以下の通りです。
・正規利用者の個人情報閲覧
・送金
・物品購入
・なりすましメール etc……
とにかく、正規利用者はとんでもない被害を被る可能性があります。ヒエーッ！
そして、セッションハイジャックの具体的な攻撃方法としては、以下の3つがあります。
・セッションIDの推測
・セッションIDの盗み出し
・セッションIDの強制
セッションIDは、利用者の状態を保持するために使われます。
順番に説明します。
☑️セッションIDの推測
Webアプリケーションに用いられるセッションの生成規則に問題があると、第三者に用意にセッションIDを予測され、悪用されてします恐れがあります。
たとえば、
・ユーザーIDやメールアドレス
・リモートIPアドレス
・日時
・乱数
などを生成規則の元にしてセッションIDを生成すると、第三者に予測されてしまいます。
対策としては、Webアプリケーション開発ツールが持つセッション管理機構を利用することが安全とされています。主要なアプリケーション開発ツールのセッション管理機構に脆弱性が発見された場合、セキュリティ研究者によって指摘されすぐに改善されることが見込まれます。
そのため、セッションIDの生成は開発ツールに夜ものにすると、セッションIDを予測されることはほとんどなくなるそうです(反対に、独自の機構で生成したセッションIDは、予測されやすいのでやめておくこと)。
☑️セッションIDの盗み出し
セキュリティ対策が不十分なインターネット上の通信では、Webアプリケーションとサーバー間でのデータ通信の際に、値(ここではセッションID)を用意に取得できます(例：暗号化されていない無線LAN)。
この攻撃方法に対しては、SSL(Secure Socket Layer)という
「インターネット上の通信を暗号化する技術」
を利用することが対策となります。
☑️セッションIDの強制
セッションIDを悪意ある第三者が、外部から強制させる方法です。「セッションの固定化」とも呼ぶそうです。
セッションの固定化の手順は、以下の通りです。
①悪意のある第三者(以下攻撃者と呼ぶ)は、まず普通の利用者としてセッションID(例：id1)を取得する。
②攻撃者は、被害者に対して①で取得したセッションIDを強制する。たとえば、"http://example.jp?PHPSESSID=id1"のリンクを含んだメールを被害者へ送信する。
③被害者は届いたメールから"http://example.jp?PHPSESSID=id1"へアクセスし、標的となるアプリケーションにログインをする。
④攻撃者は、被害者に強制したセッションID(id1)を使って標的アプリケーションにアクセスする。
セッションIDの固定化への対策として、認証が完了した時点でセッションIDを変更するという方法があります。
具体的には、③で被害者が
"http://example.jp?PHPSESSID=id1"へアクセスし、標的となるアプリケーションにログインをして認証が終わった後、新たに別のセッションID(例：id1 → id2)を再発行します。
こうすることで、攻撃者は、
「"http://example.jp?PHPSESSID=id1"にアクセスしても、セッションIDが変更されているのでアクセスできない」
という状況になります。
ーーーーーーーーーーーーーーーー
いかがでしたか？
正直申し上げますと、僕自身
「難しい！ わからん！」
と思った内容がたくさんありました😅
でも、Webアプリケーションとは切っても切り離せない分野ですから、今後少しずつ理解を深めていきたいと思います！
データベース言語のSQLも勉強した方が良さそうですね。
プログラミングはやはり奥が深いですね😌
それでは、ここまで読んでくださってありがとうございました！
Dateクラスについて
お疲れ様です！
IHです！
今日は、Dateクラスについて、アウトプットを行いたいと思います！
ちなみに、こちらのサイトを参考にさせていただきました！
早速行ってみましょう！
ーーーーーーーーーーーーーーーー
Dateクラスを 使うことで、日付を扱うことができるようになります。
しかし、Dateクラスを使用したい場合は、
require 'date'
とファイルに記述してあげることが必要になります。
Dateクラスはnewメソッドと組み合わせることで、引数部分の日付を得ることができます。
たとえば
require 'date'
day = Date.new(2000, 1, 1)
と記述することで、「2020年1月1日」の日付を表すDateクラスのオブジェクトを生成できます。
（"day"はただの変数です）
また、今日の日付を取得することもできます！
以下のように記述します。
require 'date'
day = Date.today
これにより、今日であれば「2020年8月6日」の日付を表すDateクラスのオブジェクトを生成できるわけですね！
さらに、ここにwdayメソッドを付け足すことで、曜日の情報も取得できます。
ただし、返される値は
「0〜6の数字」
である点に注意が必要です。
具体的には
「日・月・火・水・木・金・土」
の順番で、
「0・1・2・3・4・5・6」
が渡されます！
以下が記述例になります。
require 'date'
day = Date.today.wday
=> "0~6の数字"
今日は「2020年8月6日木曜日」なので「4」という情報を受け取ることができます！
このwdayメソッドを使えば、以下のようなこともできます。
require 'date'
# 各曜日を要素にした配列
week = ["日曜日","月曜日","火曜日","水曜日","木曜日","金曜日","土曜日"]
day = Date.today.wday
puts week[Date.today.wday]
=> "木曜日"
各曜日を要素にした配列week(必ず日曜日始まり)の添字部分に、今日の曜日を返す変数dayを入れます。
すると、"4"が返ってくるので、
配列の5番目の要素である"木曜日"を取得することができるわけです！
ーーーーーーーーーーーーーーーー
いかがでしたか？
私事ですが、本日は、テックキャンプのカリキュラムで
「次のアプリをダウンロードしてください。そのアプリには、修正するべき問題が6つあるので、順番に解決してください」
と言った旨の課題が出され、そちらを解いていました。
なんとか5つの問題は解くことができたのですが、最後の問題で、このDateクラスを用いる問題が出てきました。
その問題は、簡単に言えば
「1週間分の曜日を表示させよう！」
というものなのですが……
これが、まあ難しくて解けない😅
エラーが出たり、「木曜日」がただ7つだけだったり😅
今日中に解くことは無理だったので、明日メンターの方に質問しながら解こうと思います。
それでは、本日もここまで読んでくださってありがとうございました！
一日お疲れ様でした！
おみくじアプリを作ります！③
お疲れ様です！
IHです！
昨日、今日とエラーに苦しみ、そちらに時間をとられておみくじアプリはノータッチでございました😅
GitHubのコンフリクトのエラーですね。
メンターの方に相談したところ、自分が日を跨いで悩んでいたところを、一発で解決していただきました。
流石すぎます！
僕もそのレベル目指して、今後もエラーと戦っていきたいと思います！
「エラーが発生しちゃった！」
ではなく
「成長の機会をもらえた！」
と思うようにして頑張ります！
さて、本日はおみくじアプリを作っていきますよ！
今日はREADMEの記述からです！
ーーーーーーーーーーーーーーーー
そもそもREADMEとは？
→ソフトウェアの仕様、規格、インストール方法などを文書化したアプリケーションの説明書のこと。rails newコマンドで自動生成され、マークダウンという方法で記述される。
ではマークダウンとは？
→文書を記述するための軽量マークアップ言語の一つ。マークダウンで記述したものは、HTMLに変換される。
マークダウンの詳細については、以下のURLからどうぞ！
今回、READMEには
usersテーブル、lotsテーブル、commentsテーブルの
・カラム名(Column)
・カラムの型(Type)
・オプション(Option)
とアソシエーションを記述していこうと思います。
そして、実際にREADMEに記述したものがこちら！
「『#』とか『|Column |Type |Option |』って記述してるけど、何の意味があるの？」
と思われるかもしれませんが、これがマークダウン記法になります。
こう記述することで、
commentsテーブルのType(カラムの型)の欄に記述してあるreferencesは
「Ruby on Railsにおいて外部キーのカラムを追加する際に用いるカラムの型」
のことです。
「foreign_key: true」
という制約を設けることで、他テーブルの情報を参照することができます。
つまり、この「references」と「foreign_key: true」を記述することで、
「どのユーザーが、どの投稿に対してどんなコメントをしたのか」
がわかるようになります。
さあREADMEを記述した後、GitHub Desktopでコミットとプルを行いました。
その後、GitHubのサイト(リモートリポジトリ)で確認したものがこちら！
いかがでしょう！？
マークダウンで記述したものがHTMLに変換され、このように表示されます！
これで、READMEでの、テーブル設計の作業は終了です！
ーーーーーーーーーーーーーーーー
いかがでしたか？
今はlotsテーブルに関しては手探りの状態ですので、今後カラムの追加や型の変更などがあるかもしれません。その辺りは、作業を進めながら考えていきたいなと思います！
それでは、ここまで読んでくださってありがとうございました！
おみくじアプリを作ります！②
お疲れ様です！
IHです!
おみくじアプリの進捗をまとめたいと思います！
ーーーーーーーーーーーーーーーー
現在の進捗状況
１：rails newコマンドで新規アプリケーション生成
アプリ名は「lot-app」
データベースは「MySQL」
に設定
２：database.ymlの記述を変更
データベース作成の前に
中略
default: &default
encoring: utf8
中略
と記述します。(utf8の部分が変更された)
３：ターミナルで「cd lot-app」と入力後、「rails db:create」
４：rails gコマンドで生成する、不要なファイルを生成しないようにする（必要によりけり）
config/application.rbに記述すること。
これをするのは、アプリの質をあげたり、意図しないエラーの発生を避けるため。
しかし、今回はこの設定をせず。
5：GitHub Desktopより、Current Repository→add→addExiting Repository→lot-appを選択
６：masterブランチへコミットする。（最初のコミットなので、コミット名は「first commit」）
７：「Publish repository」をクリック
ーーーーーーーーーーーーーーーー
簡単ですが、今日のところは、リモートリポジトリ作成までです！
次回からは、READMEにデータベース設計の記述をするところから始めていきたいと思います！
それでは、ここまで読んでくださってありがとうご合いました！
おみくじアプリを作ります！①
お疲れ様です！
IHです！
タイトルの通りですが、テックキャンプのカリキュラムとは別に、自分でアプリを作ってみようと思います！
その理由は
「自分にはアウトプットが足りていないなぁ」
と感じたからです。
最近、プログラミングの勉強について解説している動画を見ました。
要約すると、こんな感じです。
・暗記はやめよう（それより、「この機能を実装するには、あの記述をする必要があるな」といった思考を身に付ける方が大事）
・インプットしたら、すぐアウトプットをする（自分なりに、どんどんサービスを開発していくことが大事。しかし、なるべく別のアプリを開発する）
・必要な分だけ学ぶ
動画の視聴後、わたくしめちゃくちゃ反省しました😅
暗記の勉強、めちゃくちゃしてましたし、新出のメソッドをいちいちノートにまとめたりとかもしてましたね。これらは言ってしまえば、非効率な勉強方法だったわけですね。
もちろん、覚えることだって重要だと思います。
しかし、自分の最近の勉強方法を振り返ってみると、
「確かにインプット過多で、アウトプットが少ない……だから理解が浅いのかぁ」
と改めて感じました。
そういった経緯で
「自分なりにアプリを作ってみよう！」
という思いに至りました。
それでは、早速企画の段階からやっていきたいと思います！
ーーーーーーーーーーーーーーーーーー
◉作ろうとしているアプリケーション
「おみくじを引けるアプリ」
を作りたいと考えています。
実装したい機能は、以下の4つです。
①おみくじを引ける機能
②ログイン機能
③トップページに、自分や他のユーザーが引いた、おみくじの結果の投稿が表示される機能（ツイートのように）
④「自分や他ユーザーのおみくじの結果の投稿」に対して、コメントすることができる機能
ざっくりとですが、このようなアプリケーションを作っていきたいと思います。
◉企画（ペルソナの定義）
次に、ペルソナを定義していきたいと思います。
（ペルソナとは、サービスを利用するユーザーのこと）
・性別は、おみくじや占いを好む女性
・年齢は、インターネットの使用頻度が高い10代後半 〜 20代
・職業は、社会人より時間に余裕のある学生
◉要件定義
要件定義とは、開発者などがアプリケーションの仕様を把握するために、詳細まで言語化することです。
✅ユーザー管理機能
・ユーザーを新しく登録できる
・ユーザー登録が完了している場合、ユーザーはログインできる
・ログアウトできる
・ユーザー登録が完了している場合、ユーザー情報を編集できる（名前とEmailの編集）
✅おみくじ機能
・ボタンを押すと、おみくじを引くことができる
・おみくじの結果画面にいく→トップページに戻る
・トップページに、ユーザーのおみくじ結果が投稿され、表示される
・投稿の削除ボタンがある
・詳細ボタンで、投稿を詳しく確認できる
✅コメント機能
・投稿に対して、コメントできる
・投稿の詳細ボタンをクリックすると、その投稿とコメントフォームが出現する
◉画面遷移図
「どの画面からどの画面に遷移できるのか」を示したものを、画面遷移図といいます。
◉DB設計（エンティティの洗い出し）
まず、エンティティの洗い出しを行います。
（エンティティとは、サービスで使用されるデータ自体のことです）
✅ユーザー管理機能
✅おみくじ機能
✅コメント機能
という3つの機能があるので、必要なテーブルは、上からそれぞれ、
✅usersテーブル
✅lotsテーブル
✅commentsテーブル
となります。
(おみくじは英語で「a lot」だそうです。複数形で「lots」となります)
◉DB設計（テーブル間の関係性）
次に、テーブル同士にどのような関係性があるかを確認していきます（アソシエーションの確認）。
✅usersテーブル
・一人のユーザーは、多くの投稿（おみくじ結果）を持つ（has_many: lots）
・一人のユーザーは、多くのコメントを持つ（has_many: comments）
✅lotsテーブル
・一つの投稿（おみくじ結果）は、一人のユーザーに所属する（belongs_to: user）
・一つの投稿（おみくじ結果）は、多くのコメントを持つ(has_many: comments)
✅commentsテーブル
・一つのコメントは、一人のユーザーに所属する（belongs_to: user）
・一つのコメントは、一つの投稿（おみくじ結果）に所属する（belongs_to: lot）
いずれも「一対多」の関係ですね。多対多の関係はないので、中間テーブルは必要なさそうです。
ーーーーーーーーーーーーーーーーーー
今日はここまでにしたいと思います。
次から、本格的にコードを書いていきます！
とりあえずは
①rails newコマンドを入力
②データベースの作成
③READMEにDB設計の記述
④リセットCSS記述
⑤ビューファイル記述（HTML）
という順番で作業を進めていきたいと思います。
いやー、企画の段階からちょっとワクワクしておりました😁
よっしゃー！！
絶対完成させるぞー！！！
というわけで、ここまで読んでくださってありがとうございました！
またよろしくお願いします！
GitとGitHubの概要③
お疲れ様です！
IHです！
さて、今日は前回の続きで、GitHubの内容をアウトプットしていきたいと思います！
前回は、リモートリポジトリの作成までを行いました。
今日は、リモートリポジトリに保存をしたいと思いますが、その前に
「ブランチ」
というものから説明していきたいと思います。
では早速始めます！
ーーーーーーーーーーーーーーーーーーーーーーーー
ブランチとは？
→「リポジトリで管理しているファイルやディレクトリの変更の流れ」
このブランチには、分岐に種類があります。
変更の本流となる「masterブランチ」
と
「masterブランチから分岐するブランチである、トピックブランチ」
です。
文章だけではわかりづらいと思うので、イラストを載せます。
ちなみに、ブランチを日本語で言うと「枝」だそうです。木の枝のように枝分かれしているから、ブランチと呼ぶんですね。
ブランチは、複数人で開発をするときに非常に便利です。
一人でアプリケーション開発を進めていくと
「まず、ルーティングして、コントローラーを作って、それからビューファイルも作って……あー！ やること多すぎるよ！」
となります。
しかし、複数人でやれば
Aさん「じゃあ私はコントローラー作るね」
Bさん「じゃあ僕はビューファイル作ります」
と、役割分担できます。この方が効率的ですよね。また、不具合が発生した場合も、被害を最小限にでき、容易に対応できます。
では、このブランチを早速作っていきましょう！
（前回はgit-appというアプリを作って説明していましたが、今回は、僕が制作中のchat-appというアプリで行っていた作業の模様を、スクリーンショットでお届けしたいと思います）
◉ブランチの作成・リモートリポジトリへの保存
まずは、下の画像をご覧ください。
画面上側の真ん中に、「Current Branch」と書いてあると思います。こちらをクリックしてください。
すると、以下のような画面が出てきます。
filterという欄にブランチの名前を入力し、「New Branch」をクリックしましょう。
その次に、「Create Branch」と言う青いボタンが表示されるので、クリックしましょう。その後、「Current Brunch」の欄が、先ほど入力したブランチの名前になっているかを確認しましょう。
これで、ブランチの作成は完了です！
僕はこのとき、「メッセージ投稿機能の実装」という名前でブランチを作りました（このことを、ブランチを切る、とも言う様です）。
次に、画面右側に「Publish branch」という青いボタンが表示されるので、クリックしましょう。そうすることにより、このブランチをリモートリポジトリに反映することができます。
この後、ファイルを変更修正したら、前回の記事で説明したように、commitを行いましょう。commitが完了すると、画面右側に「Push origin」という青いボタンが表示されます。このボタンをクリックすることで、ローカルリポジトリの内容をリモートリポジトリに反映させることができます！ つまり、リモートリポジトリにローカルリポジトリのデータを保存させることができるわけですね！
この
「ローカルリポジトリでのコミットをリモートリポジトリに反映させること」
を
「push」
と呼びます。
◉プルリクエストの作成
pushをした後には、次のような画面が表示されます。
「Create Pull Request」とありますね。これをクリックすると、プルリクエストという機能を使用することができます。
プルリクエストとは？
→ブランチでのコミット履歴を残すとともに、各コミットにおける変更修正にコメントをつけることができるGitHubの機能のこと。1つのブランチ作業について、コードを確認しつつ、コミュニケーションを取れる掲示板のような物。
「Create Pull Request」をクリックすると、次のような画面が表示されます。
これから、「Leave a comment」と表示された部分に「What」と「Why」を書いていきます。具体的には、以下のように書いていきます。
このように、Whatの部分には「どのような実装をしているのか」を記述し、
Whyの部分には「なぜこの実装が必要なのか」を記述します。このプルリクエストを書くときは、マークダウン記法を使って書きます。以下のリンクの記事に、詳しく説明されていますので、ご覧ください。
必要な内容を入力できたら「Create pull request」という緑色のボタンをクリックします。
◉merge
すると、次のような画面が表示されます。
プルリクエストや、自分が行ってきたcommitの内容が表示されています。ここからさらに下の画面へスクロールすると、以下のような画面が出てきます。
（こちらからコメントを送ることができますが、今回は個人での開発のため、省略します）
次に「Merge pull request」という緑色のボタンがあります。これをクリックすると、実装したブランチの内容を、リモートリポジトリ上のmastarブランチにmerge(マージ)することができます。
mergeとは？
→機能実装のために作成したブランチを、リモートリポジトリ上のmastarブランチに反映させる作業のこと。
これを行うことで、Aさんが作ったコントローラーと、Bさんが作ったビューファイルを一つにすることができます。
それでは「Merge pull request」をクリックしましょう。すると、「Confirm merge」という緑色のボタンが表示されるので、こちらも続けてクリックします。成功すれば、トピックブランチの内容を、masterブランチに反映することができます。
mergeが完了すると、次のような画面が表示されます。
「Delete branch」をクリックすると、GitHub上のブランチを削除することができます。
それでは、「GitHub Desktop」に戻って作業を行いましょう。
◉pull
それでは、「Github Desktop」で、Current Branchをクリックし、masterブランチに切り替えましょう。
その後、画面右上の「Fetch origin」をクリックしましょう。すると、「Pull origin」という青いボタンが表示されます。
Pull(プル)とは？
→リモートリポジトリの変更を、ローカルリポジトリに取り組む操作のこと
つまり、今はまだローカルリポジトリのmasterブランチには、変更内容は反映できていない状態というわけですね。
この「Pull origin」をクリックすると、ローカルリポジトリにも、作業ブランチをmergeした状態が反映されます。
ーーーーーーーーーーーーーーーーーーーーーーーー
いかがでしたか？
ざっくりとですが、GitHubでの作業の流れをアウトプットしてみました。
複数人での開発において、GitHubは欠かせない存在ですので、是非リキしておきたいですね！
それでは、最後まで読んでくださり、ありがとうございました！
