「Gitなんぞや！って人(+α)が、とりあえず使えるねってぐらいになれる」記事です、タブンネ
始めに
そもそも Git とは何者なんだと。
めちゃ簡単に言うと、変更点と履歴を管理してくれるシステムです。基本はそうだけど、特にチーム開発で効果を発揮します。その辺はまた追々。
例えば、新しく書いたプログラムの変更点を表示してくれます。「どこをどう書き換えたっけなー」って時に一発で分かるんです。それくらい覚えとけって思われるかもしれんけど、無理なんよ。出来たら苦労しない。
僕は卒論でもGitを使ってました、履歴残すとどこまで進んだか分かりやすいんよね。
金魚並の記憶力。
さて、そんなGItのお話、はじまりはじまりー。
Gitの基本(用語とか)
とりあえず基本の用語を並べていきます。
後の使用例でも出てくるので、都度戻ってきたらいいと思います。俺は一回じゃ覚えられん。
リポジトリ
作業しているフォルダのことです。
「フォルダ」だとローカルっぽいので、ローカルとリモートまとめてリポジトリって言います。そんだけ。
ローカルとリモート
Gitには地味にクラウド機能が付いてます。要は、パソコン内部( ローカル )とネット上( リモート )の2つの記憶領域が存在してるんですね。
これの何がいいか。ずばり、どのパソコンからでも作業が見えるってことです。
とりあえずリモートに保存しとけば、別のパソコンにダウンロードして作業を再開できるんです。スタバでMacをぶちかます諸君にはうってつけってわけだ。
ちなみにボッチはあんま使わない、だってパソコン1台だし。
では、チームではどうか。他の人が作業物をリモートに投げると、こっちから見れるんですね。だから、「あの人はどんな作業したのかな～」って覗くことができます。合法のストーカーです、最高か？
冗談はさておき、チーム開発ではこの機能がとても重要になってきます。他メンバーとおんなじ作業しちゃうかもしれないからね。すごく時間の無駄。
ブランチ
これも1人だとあんまり気にしないかな。
多人数で作業するとき、それぞれ自分が作業するブランチが存在します。
大体、作ってる機能で分けることが多いですね。上の図だと「人名 / 機能名」ってブランチを分けて作業しています。
ここで重要なのは、main もしくは master ブランチです。名前はリポジトリによって異なりますが、主流のブランチというのが必ず存在します。(以下、master) ここから色んなブランチに分けて作業していくんですね。注意点は１つ。
絶対にmasterブランチで作業してはいけません。
これは特に実務開発を行う時、大事になってきます。masterというのは、必ず動作するべきブランチです。エラーとか起こっちゃダメ。
他のブランチで作業して完全に大丈夫ならmasterに結合する、というのが基本の流れになります。マジでこれだけは大事にしてください。
(ぶっちゃけ、別ブランチならどんだけヘマしても一切問題なし！いつもめっちゃやらかしてる！)
ステージング (indexにステージ)
さて、そろそろコアの話ですね。
変更点を加えたファイルは、Gitが自動で検知してくれるんですが、どのファイルを履歴に残すかを選んであげる必要があります。それがステージング。特に重要じゃないよ。
コミット
履歴です。履歴履歴と言っていましたが、Gitではコミットと言います。
ゲームで言うなら、セーブポイント。オートセーブ機能はありません。
先ほどステージングしたファイルを、実際にセーブする操作です。
こんな感じ。debugブランチとmainブランチがあって、それぞれでコミットがされてますね。
上の図ではコミットで何をしたか分かりませんが、実際はコミットメッセージを付けて、「こんなことしたよー！」ってのを残します。
これがマジで便利。半年前の作業とか覚えてるわけないもんね。ちなみに自動で日付と時間も記録されます。(頑張ったら誤魔化せるので、たまに誤魔化してます)
プッシュ / プル
コミットで作業を記録したら、それをリモートにアップロードします。その操作をプッシュって言います。
ローカルのコミットは他の人からは見えません。
逆に、リモートからダウウンロードしてくるのをプルって言います。チョロいね。
フェッチ
リモートの状態を更新することです。
「Aさんがリモートにプッシュしたのに、こっちから見れない」って時はフェッチしてください。
まぁ…正直、自動更新してくれやって思いますが…
マージ
他のブランチを今のブランチにくっ付ける操作がマージです。
上の図では、debugをmainにくっ付けてますね。実際には、マージした時にmainにコミットが作成されます。
リベース
マージと混同しないでね。
リベースは、分岐点を更新する操作です。例を見ていきましょう。
debugで作業している間にmainでもコミットが作成されています。ここで、debugに対してmainでリベースを行うと…
こんな感じ。debugの分岐点が移動しているのが分かるでしょうか。これでmain側のコミット（コミット1~3）もdebugに取り込めるってわけですね。Easy, Easy.
実際のところ、マージよりリベースのがよく使うと思うから覚えていて損はないですぜ。
チェリーピック
別のブランチのコミットを自分のブランチに持ってくる操作です。言葉では難しい。
こんな感じ。debugがmainのコミット2を持ってきてますね。
「あのコミットだけ欲しい！」って時に使います。
プルリクエスト
リポジトリの管理者が自分じゃない時、masterにマージを行うのも当然その管理者になります。
「自分のブランチ上手くいったので、masterにマージしてください！」って管理者にお願いするのが、プルリクエストです。なんでプルなんでしょうね。これだけはマジで分からん。。
コンフリクト
直訳で、衝突ですね。作業領域が被ってしまうことを言います。
Git的には「2つのブランチで同じとこ編集してるけど、どっちが正しいの！？」って気持ちなんでしょう、可愛そうに。
マージ、リベース、チェリーピック…どれを行っても起きる可能性があります。解消方法はまた後ほど。
プルリクエストを出すときは、コンフリクトを解消してから！
クローン
おまけ。一番初めにリポジトリをローカルにダウンロードすることをクローンって言います。
それだけ、以上！
GitHub / Bitbucket etc.
「GitHubってよく聞くけど結局なんなのさ！」
怒らんでくだせぇ。こいつらは単にGitを扱いやすくしてくれるサービスってだけでさぁ。
リポジトリを作ったり、管理したり、みんなに公開したり、そんなことをしてくれるサービスです。アカウントとリポジトリを紐づけてくれてるって感じ。
よくソースコードがGitHubで公開されてますよね。
ちなみに、僕はGitHubよりBitbucketの方が見やすいなーって思ってます。気分です。
SourceTreeとは
あ、これ副題です。
あれこれGitについて述べてきましたが、Git本体はああいった操作をコマンドで行うんですね。
ぶっちゃけ超メンドイし、すぐ忘れるのでコマンドはイヤだ！ そーんなレディース&ジェントルメンにオススメなのが、SourceTreeというソフトです。
要は、GitをGUIで扱えるってことですね。あらやだステキ。
今回は、サクッとGItに触れてもらいたいので、以降はSourceTreeをベースに進めていきまーす。
(一応コマンドも載せる…かもしれない)
なんか思ったより長くなったので、回を分けます。
第2回
まだ