はじめに
Githubを今回ちゃんと使ってみることになり，自分の知識不足を感じた．こればかりはきちんと利用しなければ，手順だったりマナーが理解できていなかったりしてしまい，今後のチーム開発に遅れを感じてしまうと思った．
そこで，今回はふんわりと雰囲気しかつかめていなかったGithubを利用した開発を，チーム開発で利用していきながら学んでいこうと思う．
そもそもGitとは
そもそもGitはバージョン管理ツールの一つである．様々なプロジェクトを管理するときに，二日前のプロジェクトの状態に戻りたいとかが起きてくる．他にも一つのプロジェクトに対して複数人で開発していくときにファイルの統合が面倒，みたいな状況に陥ることがある．自分は個人開発はまだしも，チーム開発は経験なしだったので，そういう発想には結局至らなかったためそこまで難しく考えたことがなかったが．
GithubはそのGitをグラフィカルに扱うためのツールであり，よく使うことになる．他にもGitを扱うサービスとして，BitbucketやSourceTreeもあるが，やはり代表的なものとしてはGithubらしい．なので，Githubを今回はしっかりとまとめていこうと思う．
Gitでできること
まずはGitでできることを考えていこうと思う．
ファイルの変更履歴の管理
ファイルの変更履歴を簡単に扱うことができる．それぞれ変更したら名前を変更する，などを行わなくても済むため，管理の手間を省くことができる．
スクリーンショット 2019-02-27 11.15.15.png
過去ファイルに戻せる
ファイルの変更履歴を管理しているため，過去の任意の状態にプロジェクトを戻すことができる．
チーム共有
プロジェクトのチーム内共有が簡単に行える．また，変更履歴をお互いに確認が取れるため，共有がしやすい利点が大きい．
Gitを扱うための基礎用語
リポジトリ
ファイルの変更履歴を保管しておくところ．これには二種類存在する．
- ローカルリポジトリ
- PC上におくリポジトリのこと．PC上にあるファイルやバージョン管理をしたい場合に活用
- リモートリポジトリ
- 外部サーバにおくリポジトリのこと．ネットワーク上におくことで，複数人管理が可能になる
リモートリポジトリに最新のファイル状態を置いておき，そこから自分のPC上のローカルリポジトリにリモートリポジトリのソースコードをダウンロードして開発を進めていく．ローカルで変更させていき，その後リモートにその変更を反映させる．
コミット
変更を反映させる作業を，コミットという．コミットすることでファイル状態を記憶させることができるため，いつでもその状態に戻ることができるようになる．
gitの基本操作
- git init コマンド
- 新しいリポジトリの作成，gitでのバージョン管理を始めるためのコマンド
- git add コマンド
- gitのバージョン管理対象として，インデックスに登録するコマンド，注意としてまだこのコマンドではバージョンの記憶はしていない
- git commit コマンド
- インデックスに登録されているファイルを，リポジトリに変更記録として記憶させるコマンド．コミットさせるコマンド
- git log コマンド
- リポジトリにコミットされたログの確認が取れるコマンド
Github
ここまでがGitという機能の紹介をした．このGitの機能を兼ね備えたもので，gitのリモートリポジトリと考えても良い．つまりGithub上にプロジェクトをおき，そこからチーム内でソースコードの変更やコピーを反映させていく．
これがDropboxなどを用いていた場合，同じファイルをお互いに知らずに編集していた時などに統合した場合お互いの変更を上書きしてしまう可能性がある．したがって，その不便性を解消したものがgitとなっている．
手順
実際にGithubを用いてバージョン管理をしていこうと思う．手順としては，以下の通りである．
- リモートリポジトリの作成
- ローカルリポジトリの作成
リモートリポジトリの作成
Githubのサイトから，「New Repository」を選択することでリモートリポジトリを簡単に作成することができる．
ローカルリポジトリの作成
リモートリポジトリを作成することで，チーム開発における共有のリポジトリの作成はできた．そのため，次はリモートリポジトリの内容を自分のPC上のローカル環境に作成していく．また，このようにリモートリポジトリからローカルリポジトリを作成することをクローンという．
リモートリポジトリはGithubのサイト上で行うに対して，ローカルリポジトリに関してはGuthub Desktopなどのローカル環境で行なっていくのが普通である．手順としては，Github Desktopから"Clone"によってリモートリポジトリの内容をローカル環境に移すことが出来てローカルリポジトリを作成することができる．
バージョン管理
リモートリポジトリでのバージョン管理の手順は以下の通りである．
- ローカルリポジトリで変更を加える
- その変更をコミットする
- コミットした内容をリモートリポジトリに反映させる．
コミット手順
Github Desktopによってローカルリポジトリの変更をコミットしていく．コミットしたいファイルを選択し，コミットメッセージを入力する．そのあと，"Commit to master"ボタンによってコミットする．これでコミットができた場合，"History"タブに変更が記録され，コミットの履歴として残っていく．
ここで気をつけたいのは，まだこの変更はローカルリポジトリ上でのみの変更であるためこれをリモートリポジトリに反映させる必要がある．
またコミットしていくときの注意点として，コミットは1機能ずつこまめに行なっていく方が良い．
コミットの取り消し
ちなみにコミットの取り消し方法としては，先ほどのコミット画面において"Commit to master"の下に"Undo"ボタンが追加されている．もちろんコミットを取り消した場合，"History"タブのコミット履歴も消える．
リモートリポジトリにプッシュ
Github Desktopの左上に"Publish"ボタンがある．このボタンによりリモートリポジトリへ同期し，表示が変わっていることをリモートリポジトリで確認が取れたらプッシュが完了となる．サイトの"Commit"の部分にコミット内容が溜まっていくため，そこで確認が可能．
複数人開発の時
以上は，1人で開発するときのバージョン管理の例を示した．ここからは本題である，複数人での開発を行う際のバージョン管理の手法を示していきたい．
リモートリポジトリでプロジェクトを開始していき，自分のローカルリポジトリにそれをクローンして環境を整えてからローカルリポジトリに変更をコミットしていく．
ブランチ
独立した環境で作業するためには，ブランチというものが必要になる．これがないと，お互いの開発による変更が影響しあって，元の処理が動かなくなる可能性があるからだ．ちなみに，Gitでプロジェクトを開始した時は必ずmasterブランチに属することになり，ここが大元のブランチとなっていく．
まずはmasterブランチをコピーして新たなブランチを作成したとする．そこで新機能を実装したとしても，ここでの変更はコピーしたブランチでのみの変更であり，masterブランチではこの新機能は実装されていないことになる．ブランチ同士は完全に独立しているため，この特性を用いて新機能を新たなブランチで開発していく．そして最終的にブランチをmasterブランチに統合していくことで，機能を付け加えていくことになる．
ブランチの作成
Githubデスクトップの左上にあるボタンを押すことでブランチを新たに作成することができる．ブランチ名を決めて作成すると，masterブランチから切り替わるため，そのまま開発を進めていけば，新しいブランチで実装してくことになる．
マージ
ブランチを統合することをマージという．主に新しく作成したブランチをmasterブランチにマージしていくことになる．
プルリクエスト
ここがチーム開発をしていく上で大切となってくる作業である．ブランチで作業していたものを全てマージしてしまうと，やはりそれではチーム間で作業内容が影響し合うことが多くなる．そのため，それを少しでもなくすためにはマージする前に確認作業を取る必要がある．それをプルリクエストという．
プルリクを行うと，Github上で差分を見ることができ，それを元に他のメンバーからコメントをもらうことができる．
プルリクの出し方
Github Desktopから右上にある"Pull Request"ボタンを押して，そのブランチで行なったことを記述する．その下に出る"Sent Pull Request"ボタンを押すとプルリクを出すことができ，URLをクリックすることでプルリクが出せたかどうかの確認が取れる．
プルリク画面
プルリク画面には"Conversation"，"Commits"，"Files Changed"の三種類ある．
Conversation
できることは以下の三つ．
- ブランチのマージ
- ブランチに対してのコメントの投稿
- プルリクの取り消し
まず，ブランチのマージについては緑色のボタン"Merge Pull Request"を押すことでマージすることができる．
コメントは画面下にある"Leave a comment"をという入力ボックスでコメントをすることになる．
また，その隣にある"Close Pull Request"ボタンによってプルリクを取り消すことができる．
Commits
現在ブランチでのコミットの一覧が表示される．コミットをクリックすることで，対応する編集部分を確認することができる．
Files changed
ファイルで変更されたものを確認することができ，追加部分が緑色のハイライト，消去部分が赤色のハイライトが当てられる．またソースコード一行単位でコメントをつけることもできる．
ブランチのマージ
"Merge Pull Request"ボタンをクリックすると"Confirm merge"ボタンをおすことで，マージが完了する．
完了したブランチは消去しても良いので，消去するのが慣例となっている．マージ後に"Delete Blanch"コマンドが出てくるため，そのボタンをクリックすることでプルリクによるブランチの削除が可能となる．
リモートリポジトリの内容をローカルに同期
プルリクをすることで，リモートリポジトリ上ではmasterブランチは進行している状況となっている．しかし，ローカルリポジトリ上のmasterブランチは変更を反映していない．そこで，リモートリポジトリの内容をローカルリポジトリの内容に反映させることをプルという．
プル
リモートリポジトリの内容を取得し，ローカルリポジトリの内容を更新すること．他のチームメンバーがリモートリポジトリを更新した後は，プルを行うことでリモートリポジトリの内容をローカルリポジトリの内容と同期させる必要がある．
実際のプルの作業は以下の通り．
- プルするブランチに切り替える
- Syncによって同期
これらの操作は全てGithub Desktop上で行えるため，そちらでやることをオススメする．プッシュもプルもどちらも同期させることを目的としているため，Syncボタンで行うことになる．
Github Flow
最後のまとめとして，Github Flowをまとめておく．これがGithubを用いて開発するときの流れとなるので，これに則って行なっていくのが安全である．
- masterブランチは常にデプロイできる状況にしておく
- 新しい作業はmasterブランチから新しい作業ブランチを切り取る
- 作成したローカルリポジトリのブランチにコミットする
- リモートリポジトリに定期的にプッシュする
- 開発の疑問点は随時プルリクを出すことによってフィードバックをもらう
- プルリクのレビューに応じて適宜修正をし，完了を確認したらマージする
- masterブランチへのマージが確認取れたら，デプロイして確認をとる
最後に
githubは断片的に使い方などを知ってはいたものの，実際の共同開発で用いるのは初めての経験である．今回の記事はgithubを使うにあたって，自分の知識の総ざらいが必要だと感じて知識をまとめることにした．実際に使ってみた時に迷ったこと，指摘されたこともまた別記事としてまとめておきたい