はじめに
先日、現役エンジニアの方が主催された共同開発の練習を他の参加者の方と一緒に行いましたので、内容をまとめて備忘録にすることにしました。（コンフリクト解消まで）
私のように未経験からエンジニアを目指す場合に意外に軽視されがちなGitとGitHubなどを使用して行う共同開発の学習（練習）は非常に重要かと思いましたので、下記に列挙していきます。
1. まずはソースコードをクローンする
ターミナルで以下のコマンドを打ってGitHubに公開されているソースコードをクローンします。
$ git clone https://github.com/hoge/hogehoge.git
今回、クローンしてきたソースコードのディレクトリ名を仮にgit_sampleとして、下記のようにこのディレクトリに移動します。
$ cd git_sample
その状態でターミナルにてbundle installを行って、インストールが終わったらbundle exec rake db:createを行います。
続けてrails sでRailsを立ち上げてhttp://localhost:3000にアクセスしてViewを確認します。
2. 自分専用のブランチを作る
ソースコードをクローンしてきて、ブラウザでも確認ができたら次に下記のようにコマンドを打って自分専用のブランチを作っていきます。ブランチの名前はどのような機能を実装する（変更点）のかが、わかるブランチ名にするのが基本ですが、今回は簡略化して私の名前であるshoの開発という意味でsho_devというブランチ名で作成していきます。
$ git checkout -b sho_dev
これでブランチを作成でき、同時にsho_devというブランチに移動できました。
（git branchと打つことで今どこのブランチにいるか確認できます！）
その状態で試しにディレクトリ内のファイルをテキストエディタで編集してみましょう。
（Viewのindex.html.erbなど変更が確認しやすいファイルなど）
編集後にgit statusと打つことでまだ変更がcommitされていないファイルがあることが確認できます。
modified app/views/users/index.html.erb
このようにターミナル上に赤色で表示されると思います。
そして今回の変更をcommitするために
$ git add .
$ git commit -m "add introduce"
を行います。
git commit -m "add introduce"の名前も何を変更したのかわかるような名付けをするのが良いです。
またgit add .の後に、もう一度git statusをしてみると
modified app/views/users/index.html.erb
のように今度は緑色で変更したファイルが表示されcommitする準備が整いました。
そしてgit commit -m "add introduce"後にpushを行っていくのですが、ここで下記のようにpushしては絶対ダメです！！！
$ git push origin master # やったらあかん！ダメ絶対
なぜか？
それはgit push origin masterとしてしまうとその通りですが、リモートリポジトリのmasterブランチに誰のチェック（コードレビュー）も受けずに直接pushしてしまうことになり、大元のソースコードが変わってしまいます（泣）
これは開発現場では絶対にしてはいけないことの1つなので気をつけましょう！やってしまうとメチャクチャ怒られるそうです（現役エンジニアは語る）。まあ、怒られるだけならいいのですが、現場に多大なる迷惑をかけるので本当に気をつけていきましょう！
ではどうやっていくかと言いますと……
$ git push origin sho_dev # 先ほど作った自分専用のブランチ
のようにしてpushするとGitHub上でsho_devなるブランチが作られていてそこにpushされております。
実際の開発現場であると、この後にGitHub上でプルリクエストを行って上司のエンジニアの方などにレビューをしてもらって修正箇所があればそこを改めて修正し、OKが出ればmasterに変更を反映してもらえます。
次はコンフリクトについて見ていきます。
3. マスターが最新の状態になっていないのにブランチを切ると……
先ほどからの続きで、ターミナルにてgit checkout masterでブランチをmasterに切り替えてテキストエディタで変更した箇所を確認しに行ってみると、まだmasterには変更が反映されていないことが確認できると思います。
よくこの状況でありがちなミスとして、masterが最新の状態に書き換わっていないのに、ここで下記のように「ブランチを切る」ということを行うと、いわゆるコンフリクト（衝突）が発生する可能性があります。
（ブランチを切る ＝ ブランチを作る）
$ git checkout master
$ git checkout -b sho_dev2 # 新たにブランチを作ってしまいファイルを編集すると……
とターミナルで打ってテキストエディタにてファイルを編集して
$ git add .
$ git commit -m "hogehoge"
$ git push origin sho_dev2
という一連の流れを行ってGitHubでCompare & pull requestのボタンを押してみると
Conflicting files
という風に表示されて注意されてしまいます。
4. コンフリクトを起こさないようにするには
まずコンフリクトを起こさないようにするには、下記のようにコマンドを打ってmasterの最新の状態を引き出しておく必要があります。
$ git checkout master
$ git pull origin master
git checkout masterでブランチをmasterに切り替えて、
git pull origin masterでmasterの最新の状態を引き出してきます。
そしてテキストエディタの方で最新の状態が反映されていることを確認します。
この状態で
$ git checkout -b sho_dev2
としてブランチを切って（ブランチを作る）ファイルを編集してpushすると、コンフリクトが起こる可能性を減らすことができます。
5. コンフリクトを解消する方法
今回のようにしてコンフリクトを起こしてしまい、そのコンフリクトを起こしたsho_dev2のブランチが残ってしまっていますよね……
なので、コンフリクトを起こしたブランチのsho_dev2に最新の状態であるmasterブランチの変更を取り込んでいきます。（下記参照）
$ git checkout sho_dev2 # コンフリクトを起こしたブランチに移動
$ git merge master # sho_dev2にmasterの変更を取り込む
そうするとテキストエディタがAtomの場合はAtomの便利機能の1つで今回コンフリクトを起こしている箇所を教えてくれます。
そこでどの内容の方を使うかを選択します。
これでmerge完了です。
その後にpushまでの一連の流れを行います（下記参照）
$ git add .
$ git commit -m "modify conflict"
$ git push origin sho_dev2
そしてGitHubに戻り、Conflicting filesと表示されていた部分を見てみるとコンフリクトが解消されているはずです！（下の画像のような表示が出ます↓↓）
お疲れ様でした
最後に
今回はコンフリクトの解消までの基本的なGit・GitHubの操作について、自分が学ばせてもらった内容をテキストという形でまとめさせて頂きましたが、この他にもフェッチ（fetch）や、リベース（rebase）、フォーク（fork）、.gitignore、cherry-pickなどの用語があり、学ばなくてはならないことはあるのでどんどん学習・復習していかないといけないなーと改めて感じております。
備忘録として書いたものですが、今回の記事が誰かのお役に立てれば幸いです！
この記事がよかったらいいね！ボタン押してください（ムチャクチャ喜びますw）
それではまた！