プログラミングや開発をする際に、
絶対に使用するツールが存在します。
プログラミング言語やエディターとかではありません。
そうGitです。
(あとはDockerとかもありますが、
Gitに比べると必須とまではいかないかなと思います。)
Gitがなければ、
開発は始まりません。
それぐらい、Gitは重要なものです。
しかし、Gitは概念が複雑だったり、
コマンドが多かったりと学習コストが高いことでも有名です。
そこで本記事では、0からGitが最低限実務で使えるレベルになるまでに、
必要なことを完全解説します。
Gitとは？
さて、まずGitとは？なんでしょうか。
Gitとは、分散型バージョン管理システムと
定義されることが多いですが、
平たく言うと、ファイルの変更履歴とかを管理してくれるものです。
一人で開発しているとあまり問題にならないかもしれませんが、
チームで開発している場合、
誰がどういう変更をしたのかということはすごく重要なことです。
ある変更によって、
サーバーがエラーによってダウンしてしまったりした大変ですよね。その際の犯人を炙り出して糾弾するために、
その際のどの変更によってダウンしているのかをすばやく解明するために、
Gitで変更を管理することはものすごく大切なことです。
試しにGitを使わないとどうなるとかいうと、
おそらくDropboxとか、Googleドライブのような、
クラウドサービスを使う羽目になると思います。
しかし、こうなると地獄です。
これらの場合だと、まず誰もが変更しやすいという点と、
変更履歴を管理できないということと、
新規メンバーに対して、いちいち細かいファイルの履歴などを
送る必要があることです。
細かいソースコードのバージョンとかを管理するソフトウェア開発で、
上記のやり方は、実質上不可能に近いです。
(本当にあった怖い話として、Dropboxで開発をしている現場も目撃したことあります。)
Gitを使えば、バージョンを適切に管理できますし、
バージョンを戻すこともできます。
誰がどういう修正を加えたかもわかりますし、
新規メンバーは、リポジトリをcloneすればいいだけなので、
不毛なコミュニケーションコストも発生しません。
Gitはソフトウェア開発の女神様なんです。
さて、早速我らが女神のGitを使ってみましょう。
Gitは基本的にはCLIツールで、
git -vでバージョンが表示されたらインストールされています。
MacやLinuxとかなら、
何もしなくてもインストールされているかもしれません。
Gitの便利さは、
筆舌に尽くしがたいものがあり、
Gitがない開発は考えられないし、
考えたくもないレベルで重要なツールです。
(しつこいですね)
私は、一度だけDropboxを使って開発をしている現場に参画したことが
ありましたが、控えめに言って地獄でした。
開発は、膨大なファイルを複数人の変更履歴とかを詳細に管理することができないと、
成り立たないので、Gitなしの開発は、地獄です。
(しつこいですね)
Gitは学習コストがそれなりに高いので、
最初のうちは導入するメリットは感じにくいかもしれませんが、
そのうちGitの便利さを痛感する日が必ずきます。
絶対にいれましょう。
Githubとは？
GitがCLIツールなのに対し、
Githubは基本的には、Webサービスのことなので、
GUIツールにあたります。
Gitで管理しているローカルのファイルを、
Githubに反映させることで、
ローカル依存をなくし、誰もが同じディレクトリをダウンロードできるようにしてくれます。
具体的には、こんな感じです。
https://github.com/sindresorhus/fast-cli
こうしたGithubのリポジトリに、
開発しているアプリケーションをpushして、
他の開発者がpullしたりcloneしたりすることを可能にしているといった感じです。
(pullやcloneなどについては後ほど解説します。)
pushとは、ローカルのファイルをリモート（すなわちGithub）に
反映させることで、
pullとは、リモート（すなわちGithub)のファイルを
ローカルに保存することにあたります。
昨今の開発では、基本的には、
GitとGithubを別々に使って開発するようなことはないので、
両方使うものと思っていただいて問題ないです。
GitLab
こうしたリモートのGit管理サービスは、
Githubだけではなく、
GitLabというものもあります。
今のところ(執筆時点)は、
まだGithubのほうが使用者が多い印象ですが、
今後はGitLabも増えてくるかと思います。
GitLabとGithubの両者の差異が、
めちゃくちゃあるというわけではないので、
正直どちらを使っても良い気がします。
Gitの基本の流れ
さて、GitやGithubがどういうものかについては、
解説したので、Git開発での基本の流れについて
解説していきたいと思います。
Gitを使うにあたって、いくつかの用語が存在するので、
まずはそれを解説していきます。
リポジトリ
これは、Gitにおいては、基本的にはアプリケーションそのもので、
アプリケーションを起動するのに必要なすべてのファイルを集約した
単位のような感じです。
基本的に、下記のリンクにあるような
ファイルの集合体みたいなもの（アプリケーションに必要なファイル）を
Githubに登録しておく感じです。
https://github.com/sindresorhus/fast-cli
上記のようなものを一般に、
リポジトリと呼びます。
リポジトリをクローンとかって言いますが、
これは、中央のアプリケーションを持ってきて、
開発に参画するための最初のステップです。
クローン
さて、上記のリポジトリがあったら、
それをローカルに保存したいと思います。
その際、クローンという作業を行います。
これによって、ローカルにGithubのリポジトリと同じファイルを
持ってくることができます。
平たく言うと、複製ですね。
開発(修正など）
さて、そうしたクローンしたリポジトリになにか変更を加えるとします。
新規機能を追加したり、バグを直したりと。
そうして修正を完了したら、
その修正したやつをリモートのリポジトリにも反映させたいですよね。
そこで、次はpushというのを行って、
ローカルの内容をリモートに反映させます。
これで、リモートの内容が最新になりました。
ややはしょってはいますが、
Git・Githubを使った基本的な開発の流れはこのような感じです。
以上を踏まえて、
具体的に使うコマンドを見てみましょう。
Gitのコマンド
GitはCLIツールなので、
コマンドが色々あります。
全ては紹介しませんが、
よく使う基本的なものを紹介していきます。
add
いきなり混乱することを言って恐縮ですが、
pushをする前に、addとcommitをする必要があります。
commitは平たく言うと、
修正した差分をセーブするような感じですね。
commitしないと、どこが変更されたのかを
gitは管理できていないので、
pushしたところで何も変わらないといった感じです。
そして、Gitの場合、
commitをする前に、
このaddという操作をすることが多いです。
これは、ファイルをインデックスに追加する操作です。
https://git-scm.com/docs/git-add/ja
とはいっても、この説明だけで
「うんなるほど」って分かる人は、
そんないないと思います。
そもそもGitには、commit前にファイルを置いておくようなモードがあって、
ステージングって言われることも多いです。
まあ、正確にはファイルを置くモードというよりは、
commitするファイルを登録して、
なんでもかんでもcommitできないようにしているといった感じです。
このgit addしたファイルは、
インデックスに追加されているので、
commitができるようになります。
インデックスに追加されていなければ、
そもそもcommitができない感じですね。
なんで、こんなめんどくさい感じになっているのかというと、
そもそもcommit自体が、ある意味修正の歴史みたいな感じになるので、
同じcommitに含めるのがふさわしくないものが差分に出るかもしれません。
その際、commitに入れる差分と入れない差分を選り分けることが可能なように、
このステージングみたいな、commitの前のモードが存在する感じですね。
まあ、最初のうちは、
よくわかんないと思うので、
とりあえず、「commit前にaddしないとな！」って
覚えておけば概ね大丈夫です。
実際、使用する際も、
git add test.txtみたいに特定のファイルだけをaddするという使い方よりも、
git add .というようにカレントをすべてaddするという
ガバガバな使い方をすることがほとんどです。
addの仕組みがよくわからなければ、
とりあえずcommit前にgit add . ってするんだなぐらいの
理解でも一旦大丈夫です。
commit
既にaddのところでも、
commitについて簡単に言及しましたが、
commitは、平たく言えばセーブです。
ポケモンとかで、
セーブするみたいなやつあったと思いますが、
まあ、あれです。（概ねあってるはず...w)
Gitは分散型バージョン管理システムと
言いましたが、このcommitはまさに、
管理しているGitに新しい歴史（修正）を
刻むような感じです。
すなわち、Gitとは、
この歴史の積み重ね、
commitの積み重ねを管理しているシステムといっても
過言ではないでしょう。
https://git-scm.com/docs/git-commit
そのため、安易にコミットしてしまうと、
現状のリポジトリに新しい歴史を刻んでしまうも
同然なので、よく考えてcommitする必要があります(特大ブーメラン）
コミットには、基本的に
コミットメッセージをつけますが、
やり方としては、
git commit -m "first commit"みたいに、-mオプションつけてやるのが
多いでしょう。
このメッセージは、
git logとかでも確認できますし、
pushしたGithubとかでもチェックできます。
他の開発者が、
そのcommitでどういう修正をしたのかが、
簡単にわかるようにできると理想ですね。
ちなみに、このコミットメッセージの付け方や、
commitの単位の切り方とかで、
エンジニアのレベル感を見破られてしまうことがあるので、
気をつけましょう...
（よくない例としては、"Rspecインストール"というコミットメッセージなのに、
実際の修正内容は、FactorybotのインストールでRspecのインストールは別コミットに
なってしまっていたりとかですかね。）
間違っても、
git commit -m "疲れたから一旦commit"みたいなコミットメッセージはやめましょう。
恥を刻んでしまいます。（ギャグならいいですが）
あと、理想なら英語でcomitメッセージを書くのがいいですが、
なんだかんだ日本語で書いている現場が多いので、
プロジェクトに合わせれば問題ないと思います。
（みんな日本語で書いているのに英語で書いても
浮く気がするので...)
push
pushは、CLIのgitのみでは、
使わないコマンドですね。
これは、リモートのGithubに、
ローカルのGitのcommit履歴とかを反映させます。
いくら、ローカルでずっとgit commitしていても、
リモートに反映できなかれば、
他の開発者はその変更を取り込むことができませんからね。
使い方としては、
git push origin mainみたいな感じですね。
ちなみに、-fオプションは、強制的に
pushするオプションですが、
他の開発者にも影響を与えるリモートのリポジトリを
強制的に書き換えてしまう力技のコマンドなので、
使うときは慎重になりましょう。
下手すると、他の開発者のcommitが消し飛びます...
まあ、rebaseとかでcommitを書き換えたりしたとき以外は、
使うべきではありませんね。rebaseの際も、
他に影響がないか十分考慮してから行うべきです。
pull
ずっと、ローカルで開発している最中に、
ほかの開発者がリモートにcommitをしたとします。
そうすると、リモートは新しくなっているのに対し、
自分のローカルは古いままという状態になります。
こういった際、リモートの最新の状態を取り込むことができるコマンドが、
このpullです。
branch
Gitには、ブランチという概念があります。
詳しくは、こちらのドキュメントにも書かれていますが、
平たく言えば、作業領域のことです。
gitでは、デフォルトで、
mainやmasterというブランチが存在しますが、
基本的にこのブランチで開発をすることはほとんどありません。
なぜなら、仮にmasterで作業し続けてしまうと、
なにか致命的なバグとかが起きた際、
本番を別のブランチ（バグが起きていないブランチ）に戻すということが
できなくなり、サービスが止まってしまうことになりかねないからです。
仮にブランチを分けて開発を進め、
masterには、バグがない状態をキープして、
最新機能の開発とかは、別のブランチで行っていけば、
仮に別のブランチでバグが起きてもmasterには影響を与えません。
つまり、ブランチを分けることは、
Gitのバージョン管理システムを最大に活かすことであり、
ブランチを分けなければ、実質的にはバージョンを管理できていないようなものです。
masterのような、デフォルトのブランチをずっと使っていると、
他の開発者のコミットが即座に反映されてしまうため、
PRなどを挟むこともできなくなります。
そのため、基本的に
ブランチを切って開発することは必須です。
さて、ブランチの重要性はそんな感じですが、
例えば、何かをインストールするという修正を加えたい場合は、
git checkout -b feature/install-somethingというふうに新しいブランチを作成して、
そこで作業するのが一般的です。
この場合、feature/install-somethingというのがブランチ名です。
そして、ブランチを切って、
リモートにpushするときは、
git push origin feature/install-somethingとブランチ名を指定してpushします。
log
これは、文字通り、commitの履歴を確認できるコマンドです。
git logこちらもよく使う。
git log --onelineちなみにログに関しては、
本記事の後半で紹介する、
lazygitを使うと便利です。
status
これも、文字通り、現在のgitの状態を確認できるコマンドで、
commitしてないファイルやインデックスされていないファイル、
現在のブランチなどを表示してくれる。
git statusLinuxのlsコマンドと似たような感じで、
心を一旦落ち着かせたいときに打ったりするコマンドでもある。
clone
cloneは、Githubのリポジトリのコードを
ローカルに持ってくることができるコマンドである。
新しくチーム開発に加わった際など、
最初に行うのは、このコマンドで、
コードを自分のローカルに持ってくることだろう。
cloneとかする際、
ssh経由でcloneすることがほとんどなので、
後にSSHの設定についても紹介したい。
Git便利ツール
以上のように、
Gitには、様々なコマンドがあるので、
いちいち打つのが大変なときもあります。
そこで、個人的には、
LazygitというCLIツールがおすすめです。
https://github.com/jesseduffield/lazygit
上記の動画のような、
視覚的なGit操作を可能にしてくれるので、
いちいち個別のコマンドを打つ必要がなくなります。
機能が多く、
最初は使いこなすのが大変ですが、
なれると便利なので、試してみてください。
SSH設定
最後にGitのSSH設定について
触れます。
Gitのpushとかpullなどをする際に、
SSH設定をしておいたほうが便利なケースが多いので、
紹介します。
まずは、sshキーを作ります
ssh-keygen次に、作成したsshキーを
クリップボードにコピーします。
macとかなら、pbcopyコマンドが使えます。
pbcopy < ~/.ssh/id_rsa.pubあとは、Githubの設定で
sshキーの項目にこれを追加します。
追加したら、
ssh -T git@github.comを実行して、Hiと返ってくれば問題ない。
これでgit remote addとかする際、
sshの方を使えます。
git remote add origin git@github.com:example/test.gitcloneする際は、
git clone git@github.com:sindresorhus/fast-cli.gitという風に、sshの方でcloneします。
