怖くないよ、Git と GitHub

## 前書き
Git にビビり散らかしていた昔の自分向け

## Git てなんだ
語弊を恐れずに言うならファイルのタイムマシン。
例えばプログラムを書いていて、間違った時に(ctrl or cmd)+zで戻したり、やっぱり戻したのを進めなおしたりすると思う。それのファイル版。

分散型バージョン管理システム

## addしてコミットしてプッシュしてふぁるすがるしでぱーじがこくーん
コマンドが多くて混乱することもあると思うが、一度覚えてしまえば気にならなくなる。
一旦落ち着いてメモをとるべし。もし先輩に教えてもらったメモがあるなら、そのメモと比較しながら内容を反芻できるななおグッド
<dl>
<dt>add</dt>
<dd>`git add ファイル名` と使う
エイリアス(コマンドのショートカット)を切っている場合は別のコマンドを教わっているかもしれない。ga とか。
その場合は作業ディレクトリの .gitconfig か、 ~/.gitconfig を開いてみるとエイリアスが乗っている。

このコマンドは、変更したファイルをコミット対象にするコマンド
コミットしたのに変更が反映されてないときは、この add コマンドを叩いていない可能性が大</dd>
<dt>commit</dt>
<dd> `git commit` と使う
怖いと思いがちなコマンド。取り返しがつかないと思いがちだが、１つ前のコミットは簡単にキャンセルできるので安心するべし。
このコマンドは、addされたファイルの差分を一つのコミットとして保存するコマンド。
もしコミットしてから間違いに気が付いた時は、冷静にその間違えを直す修正を add して commit すれば何も問題はない。
間違いが膨大すぎる、あるいは事情があって急ぎで戻したい時は、下記の打ち消しコミットをすれば大丈夫。まだ git を理解しきれていない時は、reset より revert のが安心
打ち消しコミット `git revert HEAD`
</dd>
<dt>push</dt>
<dd> `git push (エイリアス or URL) ブランチ名` と使う
怖いと思いがちなコマンド。実際怖いが、やらかした時の対処方法もしっかり用意されているので、巻き戻しの準備をしてから丁寧に打ち込もう
このコマンドは、リモートリポジトリにコミットした内容を送るコマンド。
よくみるのは、
`git push origin feature/XX-1111`
みたいな形。
origin はリモートリポジトリの URL を指すエイリアスとなっている。
feature/xx-1111 は githubflow でよく使われる機能開発ブランチの命名方法。featureブランチの、タスク管理ツールのチケットxx-1111番、という命名の仕方


`git push` だけでも実行可能で、その時に実行されているのは、
`git push エイリアス 現在のローカルブランチ名`
である。

もしやらかした時は、修正コミットをかけて、pushし直そう。
ここで重要なのは、必ずローカル環境でエラーが出ていないことを確認すること。修正をミスしていることに気がつかないことが多々あるので、動作確認をしっかり行ってから修正コミットを行おう

</dd>
<dt>branch</dt>
<dd>本体とは分けて作業を行える機能。そしてその機能を使うためのコマンド
もしこの機能がない場合、全員が同じブランチを触ることになるため、新機能開発などを一つの大きなコミットで行わざるを得なくなり、バグフィクスでの差分確認や有事の引き継ぎなどが大変になる
この機能があるおかげで、Aさんはバグフィクス用のブランチを切って作業、Bさんは新規機能開発のブランチを切って作業、という風にそれぞれの作業が混ざらずに自分の作業に集中できるようになる。

ブランチは運用方法が色々あり、gitflow, githubflow などが有名

どんな運用でやっているのか、プロジェクト参加時にしっかり確認しよう。もし今現在でもよくわからない時は、今すぐ聞いてこよう。あとで運用方法と違うブランチの切り方をしてpushした方が迷惑がかかる
</dd>

<dt>merge</dt>
<dd>merge は二つのブランチを一つにするコマンド。怖いと思いがちなコマンドだが、怖いというよりコンフリクトが面倒なコマンンド

revert で打ち消せるので、やらかしても安心。一番怖いのはやらかしに気がつかないで push することなので、mergeしたら動作確認は忘れずに。
コンフリクトしたら `<======` `=========` `======>`こんな記号に挟まれた差分が発生する。ようはマージする側とされる側、両方に変更があるけどどちらを採用するかを問われているので、採用する側のコードを残してあげれば解決

その時、コンフリクトの記号を消し忘れないように、検索で `=====` を検索してあげるとなおよし。コンフリクトの修正漏れを見つけられたりもする
</dd>
<dt>checkout</dt>
<dd>`git checkout (ブランチ名 or ファイル名 or コミット番号)` と使う
ブランチの切り替えや、add していないファイルの差分を打ち消すのに使う
コミット番号を指定するとそのコミット番号の状態に飛べるが、ブランチ間の繋がりは失われるので、決してそこで作業はしてはいけない。
</dd>
<dt>pull</dt>
<dd>`git pull (リモートのURL or エイリアス) ブランチ名` と使う
リモートのブランチをローカルのブランチに merge させるコマンド。ローカルがリモートから遅れている分を解消するコマンド
毎朝一回か、ブランチをきる前に派生元のブランチには pull をかけてあげよう。そうするとコンフリクトの可能性がグッと減る。
</dd>
<dt>diff</dt>
<dd>`git diff (ファイル名)` と使う
作業前との差分を表示するコマンド。addする前にこのコマンドを叩いて差分に問題がないか確認s塗ることでミスが格段に減る</dd>
</dl>

## GitHub
英語がたくさんだしわけのわからない本番のソースコードが並んでいたりで怖いかもしれないが、大半は関係ないので気にしなくていい

ここでできるようになるべきはプルリクエストの作成
[こちら](https://qiita.com/samurai_runner/items/7442521bce2d6ac9330b)などでみるとわかりやすい。

差分のあるブランチを push すると自動で GitHub がプルリクエストを作成するためのボタンを用意してくれるので、それを押して、表示された項目にプロジェクトの規定に則ったコメントを書いて作成するだけ。
それだけで初心者のうちは GitHub で行うべき作業の半分を行ったと言える(個人的な感想

もし作成したプルリクエストがコンフリクトしていたら merge のボタンの代わりにコンフリクトしている旨が表示されているはずなので、ローカルで修正したものを作成してリモートに上げ直そう。
例えば develop ブランチに feature/hoge を merge しようとしてコンフリクトしていたら、ローカルで deveolop を最新の状態にしてから、feature/hoge に develop を　merge してローカルでコンフリクトを解消してあげてリモートに上げ直すと、GitHub 上でもコンフリクトは解消されている。

## それでもよくわからない
作業完了までの流れをタスク分解してみよう。きっと不安なところが見つかるはずだ。あとはその不安なところを調べたり教えてもらったりすれば、一人で立派に作業できるようになる