Gitの基礎と使用例を簡単に with SourceTree ①


<br>「Gitなんぞや！って人(+α)が、とりあえず使えるねってぐらいになれる」記事です、タブンネ

# 始めに
そもそも *Git* とは何者なんだと。
めちゃ簡単に言うと、**変更点と履歴を管理してくれるシステム**です。基本はそうだけど、特にチーム開発で効果を発揮します。その辺はまた追々。

例えば、新しく書いたプログラムの変更点を表示してくれます。「どこをどう書き換えたっけなー」って時に一発で分かるんです。それくらい覚えとけって思われるかもしれんけど、無理なんよ。出来たら苦労しない。

僕は卒論でもGitを使ってました、履歴残すとどこまで進んだか分かりやすいんよね。
金魚並の記憶力。

さて、そんなGItのお話、はじまりはじまりー。

# Gitの基本(用語とか)
とりあえず基本の用語を並べていきます。
後の使用例でも出てくるので、都度戻ってきたらいいと思います。俺は一回じゃ覚えられん。

### リポジトリ
**作業しているフォルダ**のことです。
「フォルダ」だとローカルっぽいので、ローカルとリモートまとめてリポジトリって言います。そんだけ。

### ローカルとリモート
Gitには地味にクラウド機能が付いてます。要は、パソコン内部( **ローカル** )とネット上( **リモート** )の2つの記憶領域が存在してるんですね。
![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/7bdf9fcf-5049-23b0-c004-42e486035c78.png)
これの何がいいか。ずばり、**どのパソコンからでも作業が見える**ってことです。
とりあえずリモートに保存しとけば、別のパソコンにダウンロードして作業を再開できるんです。スタバでMacをぶちかます諸君にはうってつけってわけだ。
ちなみにボッチはあんま使わない、だってパソコン1台だし。

では、チームではどうか。他の人が作業物をリモートに投げると、こっちから見れるんですね。だから、「あの人はどんな作業したのかな～」って覗くことができます。合法のストーカーです、~~最高か？~~

冗談はさておき、チーム開発ではこの機能がとても重要になってきます。他メンバーとおんなじ作業しちゃうかもしれないからね。すごく時間の無駄。

### ブランチ
これも1人だとあんまり気にしないかな。
多人数で作業するとき、それぞれ自分が作業する**ブランチ**が存在します。
![画像2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/c2e8b4e2-bcb2-22fd-1c57-a3e0a4205df1.png)
大体、作ってる機能で分けることが多いですね。上の図だと「人名 / 機能名」ってブランチを分けて作業しています。

ここで重要なのは、**main** もしくは **master** ブランチです。名前はリポジトリによって異なりますが、**主流のブランチ**というのが必ず存在します。(以下、master)　ここから色んなブランチに分けて作業していくんですね。注意点は１つ。

:::note alert
絶対にmasterブランチで作業してはいけません。
:::

これは特に実務開発を行う時、大事になってきます。masterというのは、**必ず動作する**べきブランチです。エラーとか起こっちゃダメ。
他のブランチで作業して完全に大丈夫ならmasterに結合する、というのが基本の流れになります。マジでこれだけは大事にしてください。
(ぶっちゃけ、別ブランチならどんだけヘマしても一切問題なし！いつもめっちゃやらかしてる！)

### ステージング (indexにステージ)
さて、そろそろコアの話ですね。
変更点を加えたファイルは、Gitが自動で検知してくれるんですが、**どのファイルを履歴に残すかを選んであげる**必要があります。それが**ステージング**。特に重要じゃないよ。

### コミット
**履歴**です。履歴履歴と言っていましたが、Gitでは**コミット**と言います。
ゲームで言うなら、セーブポイント。オートセーブ機能はありません。

先ほどステージングしたファイルを、実際にセーブする操作です。
![画像3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/8b88a29e-32bf-7c75-adad-3f8c0ea5c0f7.png)
こんな感じ。``debug``ブランチと``main``ブランチがあって、それぞれでコミットがされてますね。
上の図ではコミットで何をしたか分かりませんが、実際は**コミットメッセージ**を付けて、「こんなことしたよー！」ってのを残します。
これがマジで便利。半年前の作業とか覚えてるわけないもんね。ちなみに自動で日付と時間も記録されます。(頑張ったら誤魔化せるので、たまに誤魔化してます)

### プッシュ / プル
コミットで作業を記録したら、それを**リモートにアップロード**します。その操作を**プッシュ**って言います。

:::note warn
ローカルのコミットは他の人からは見えません。
:::

逆に、**リモートからダウウンロードしてくる**のを**プル**って言います。チョロいね。
![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/7bdf9fcf-5049-23b0-c004-42e486035c78.png "使いまわし参考図")

### フェッチ
**リモートの状態を更新する**ことです。
「Aさんがリモートにプッシュしたのに、こっちから見れない」って時はフェッチしてください。

まぁ…正直、自動更新してくれやって思いますが…

### マージ
他のブランチを今のブランチにくっ付ける操作が**マージ**です。
![画像4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/bfdfad1f-bbce-d86e-6399-5835eb0ae763.png)
上の図では、``debug``を``main``にくっ付けてますね。実際には、マージした時に``main``にコミットが作成されます。

### リベース
マージと混同しないでね。
リベースは、**分岐点を更新する**操作です。例を見ていきましょう。
![画像3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/79f44f27-6b9a-a0ac-68c0-fa401953178e.png)
``debug``で作業している間に``main``でもコミットが作成されています。ここで、``debug``に対して``main``でリベースを行うと…
![画像5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/05e78ed5-ce85-e304-f2d1-b24b4dbe3ac7.png)
こんな感じ。``debug``の分岐点が移動しているのが分かるでしょうか。これで``main``側のコミット（コミット1~3）も``debug``に取り込めるってわけですね。Easy, Easy.
実際のところ、マージよりリベースのがよく使うと思うから覚えていて損はないですぜ。

### チェリーピック
別のブランチのコミットを自分のブランチに持ってくる操作です。言葉では難しい。
![Untitled Diagram.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3492459/b72b5702-f865-188e-21c7-0b1e2a2b28ca.png)
こんな感じ。``debug``が``main``のコミット2を持ってきてますね。
「あのコミット**だけ**欲しい！」って時に使います。

### プルリクエスト
リポジトリの管理者が自分じゃない時、``master``にマージを行うのも当然その管理者になります。
「自分のブランチ上手くいったので、``master``にマージしてください！」って管理者にお願いするのが、**プルリクエスト**です。なんでプルなんでしょうね。これだけはマジで分からん。。

### コンフリクト
直訳で、**衝突**ですね。作業領域が被ってしまうことを言います。
Git的には「2つのブランチで同じとこ編集してるけど、どっちが正しいの！？」って気持ちなんでしょう、可愛そうに。

マージ、リベース、チェリーピック…どれを行っても起きる可能性があります。解消方法はまた後ほど。

:::note warn
プルリクエストを出すときは、コンフリクトを解消してから！
:::

### クローン
おまけ。一番初めにリポジトリをローカルにダウンロードすることをクローンって言います。
それだけ、以上！

# GitHub / Bitbucket etc.
「GitHubってよく聞くけど結局なんなのさ！」
怒らんでくだせぇ。こいつらは単にGitを扱いやすくしてくれるサービスってだけでさぁ。

リポジトリを作ったり、管理したり、みんなに公開したり、そんなことをしてくれるサービスです。アカウントとリポジトリを紐づけてくれてるって感じ。
よくソースコードがGitHubで公開されてますよね。

ちなみに、僕はGitHubよりBitbucketの方が見やすいなーって思ってます。気分です。

https://github.com/

https://bitbucket.org/product/


# SourceTreeとは
あ、これ副題です。
あれこれGitについて述べてきましたが、**Git本体はああいった操作をコマンドで行う**んですね。
ぶっちゃけ超メンドイし、すぐ忘れるのでコマンドはイヤだ！　そーんなレディース&ジェントルメンにオススメなのが、SourceTreeというソフトです。

https://www.sourcetreeapp.com/

要は、**GitをGUIで扱える**ってことですね。あらやだステキ。

今回は、サクッとGItに触れてもらいたいので、以降はSourceTreeをベースに進めていきまーす。
(一応コマンドも載せる…かもしれない)

#
<br>なんか思ったより長くなったので、回を分けます。

第2回
まだ