概要
Gitのコマンド一覧(2)では、ブランチの考え方とリモートとローカルの関係性について話した。本ページでは、多人数で開発をする際によく必要とされる、cloneやpullであったり、ブランチを整理する際に用いられるrebaseについて説明する。
前提条件として、ローカルPCにgitのアカウントを登録しておく必要がある。（ローカルPCでgitコマンドを使えたらOK）
主に使っているコマンド
- init
- add
- commit
- push
- clone
- status
- log
- reflog
- branch
- checkout
- remote
- fetch
- merge
- pull
- rebase
- cherry-pick
- reset
- rm
clone
git clone [http]
リモートリポジトリをローカルPCに複製する時に用いるコマンドである。複製したいディレクトリで上記のコマンド（[http]の部分は、githubもしくはgitLabのリモートリポジトリのページからコピーする必要あり）を実行することによって、リモートリポジトリの情報（ブランチの情報などすべての情報）をローカルPCに複製し、ローカルPCでの開発が可能となる。実際に複製されたかを確認する方法として、ターミナル上でls -aコマンドを入力し、.gitが存在するかを確認すれば良い。（.git内部にブランチやgitのログが入っている）
git cloneを行った際はmasterブランチにいるため、ブランチを切ったり、別のブランチにチェックアウトすることを忘れずに行おう。
origin/masterって何？
自身のブログのGitのコマンド一覧(2)までではイメージしやすいように説明を省いていたが、git fetchを説明する場合、より深い部分まで説明をしなければならないため、その部分について説明する。
origin/masterとは簡単にいうと「リモートリポジトリ（originという名前）のmasterブランチと繋がっているローカルリポジトリ」である。何を言っているのかというと、ローカルで新規追加（更新）したファイルが直接リモートリポジトリに反映されるのであれば、git addやgit commitはいらないとは思わないだろうか。すなわち、ローカルからリモートへ情報を渡す際の中間層みたいなものがoriginなのである。イメージすると以下のようになる。（私の解釈ではgit remote add originを行なった際にリモートにoriginの情報が追記されている。）
自身が作業しているのはローカルのmasterブランチであり、git add、git commitを行うことによってローカルのorigin/master -> リモートのmasterブランチに反映されるという流れである。
fetch
git fetchとはリモートリポジトリの情報をローカルのorigin/master ([リモートリポジトリ名]/[ブランチ名])に反映させるコマンドである。ここで注意するべきことはローカルのorigin/masterは更新されるが、自身が作業をしているmasterブランチは反映が更新されないことである。
git fetch [リモートリポジトリ名] [ブランチ名]
でコマンドを実行する。[ブランチ名]は省略可能であり、省略した場合、指定したリモートリポジトリの情報をすべて取ってくる。自身がmaster ブランチで作業をしており、リモートリポジトリと違う編集を加えた際にgit remote origin masterを実行したら以下のような挙動を起こす。（参考）
merge
git mergeとはローカルにあるリモート追跡ブランチ（今回ではorigin/master）を作業しているローカルブランチに取り込むためのコマンドである。
git merge [リモート追跡ブランチ]
を実行することで、ローカルにあるリモート追跡ブランチ（origin/master）の情報を自身が作業しているmasterブランチに取り込むことができる。リモートリポジトリ名がoriginで作業ブランチがmasterの場合、git merge origin/masterを実行すれば良い。
上図の状態でgit merge origin/masterを行うと以下のような挙動となる。
コンフリクトとは
git mergeの図を見て、「あれ？同じ場所を編集していた場合どうなるんだ？」と感づいた人がいるかもしれない。具体的にはログCとログXで仮に同じファイルの同じ行に対して別の編集を行なっていた場合はログDはどうなるのだろうか？
答えは**コンフリクト（conflict）**が発生する。コンフリクトとは衝突のことで、git側が同じ箇所を修正しているためどっちの情報を取り入れればいいのかわからない状態となっており、そのコンフリクトを解消するまで実際にはログDは生じない。コンフリクトの解消方法としては、
- Cの変更箇所をガン無視する方法**（お勧めしないので説明は省く）**
- どちらの変更点を採用するか（もしくは両方採用するか）を選択する
が挙げられる。（他にもある場合は追記していく）
最近の開発エディタではgitを拡張機能として入れることができるものもあり、筆者はVSCodeを用いている。VSCodeの拡張機能にgitがあり、コンフリクトがあった場合その差分を見て（差分を見るコマンドもあるが、筆者は使わないので説明は省く）どちらを採用するかクリックするだけでコンフリクトの発生部分を解消することができる。
また、コンフリクトが発生した際にコンフリクトが発生した前の状態に戻したい場合は以下のコマンドで元に戻すことができる。
> git merge --abort # コンフリクトが起きた後、まだ何もしてない場合
> git reset --hard HEAD #コンフリクト解消のためファイル編集を行なっていた場合
多人数で開発をしている場合どうしてもコンフリクトは生じてしまうが、出来るだけコンフリクトが起こらないように管理・運用をするべきである。
pull
git pullは上記で説明したgit fetch+ git mergeを一連に実行してくれるコマンドである。以下のように実行することができる。
git pull [リモートリポジトリ名] [ブランチ名]
次のブログでは
次のブログではgit rebaseやgit cherry-pickなど、ブランチやログの状態を改編（実際にはそのログも残る）するコマンドについて見ていく。