はじめに
Gitが未経験の方や、Gitに苦手意識を持たれている方が、プロのチーム開発現場でGitを使いこなせるように解説をしていきます。
これからGitを勉強したり、もしくはGitを勉強していると、多くの方が一度はこんなことを思うはずです。
- 「マージするとコンフリクトが起きそうで怖い」
- 「エラーが起きたらどうしたらいいか分からない」
- 「コマンドが色々あって分かりづらい」
このようにGitが分かりづらく感じたり、怖く感じたりすることがあると思います。
なんでそういう風に感じるのか。
Gitが裏側で何をしているのか、コマンドを実行した時に何が起こっているのか、そういうことが分かっていないからです。
コミットしたら何が起きるのか、ブランチを作成するってどういうことなのか、そういうことが分かった時にGitが怖くなくなります。
この解説シリーズではそういった仕組みを、図を用いて理解していきます。
その上でハンズオンで実践していきます。
- 「理解した上で→実践」
開発現場で困ることのない確かな力を最短で身に付けていきます。
このシリーズで学ぶことは「開発現場で必要とされるGitのスキルの全て」です。
- 「バージョン管理とは何のためにやるのか?」
- 「Gitのコアとなるコンセプトは?」
- 「Gitはどのような仕組みでデータを管理しているのか?」
- 「コミットの裏側で起こっていることは?」
- 「誤った変更を元に戻すには?」
- 「ブランチやマージって何で、どう運用する?」
- 「コンフリクトの解消の方法は?」
- 「リベースって何なのか?」
- 「変更内容を一時的に避難するには?」
- 「GitHubを用いてのチームの開発の進め方は?」
このような全ての内容を網羅しています。
このシリーズを学ぶことで、開発の現場で本当に必要なスキル、コマンドが身に付きます。
Gitに悩まされることから卒業していきましょう。
Gitってなんのために使う?
Gitはファイルのバージョンを管理するために使います。
では、ファイルのバージョンを管理するってどういうことでしょう。
まず、逆にファイルのバージョンを管理しなかったことについて考えてみます。
発表資料を作っていた場合、ファイルの名前に日付が書いてあるにも関わらず、さらにその後ろに「コピー」とついていたり「最新」というのがついていたりして、どれが最新ファイルなのか分からなくなってしまいます。
一人の時は最新のファイルが分からなくなるくらいで済むのですが、複数人の場合はもっと悲惨です。
例えば決算資料のExcelを共有サーバに置いて複数人で編集しているという状況を想像してみて下さい。
決算資料のExcelがあってAさんが先に修正しました。
あとからBさんがAさんが編集したことに気が付かず、上書きしてしまいました。
こういうことが起こるわけです。誰がいつ何を変更したのかが分かれば「あ〜、これ最近変更したやつだな。じゃぁ消したらまずいな。」ということが分かりますが、Excelファイルを普通に共有サーバに置いて複数人で編集しているだけだとそういったことが誰にも分からなくなります。
ではここでファイルのバージョンを管理したらどうなるのでしょうか。
ファイルのバージョンを管理するというのは、毎回変更した時のバージョンのファイルの状態を記録するということです。
バージョンを記録する時に、「いつ」「誰が」「何を」変更したのかも合わせて記録します。
するとファイルの最新の状態が分かるようになります。
さらに毎回のバージョンが記録されているので、以前の状態にも戻せるようになります。
例えば下図では「README.md」というファイルを編集しています。
赤のラインが元々のもので、緑が修正したものです。
今回の場合は語尾に「.」がなかったのでそれを追加しています。
すごく微妙な修正ですが、こういった「どのファイルの何が修正されたのか」が分かるようになります。
また、バージョンを管理すると複数人の修正も楽になります。
誰かが修正したものを気が付かずに上書きしようとすると警告が出るようにすることができます。
こういったことがGitでバージョン管理をするとできるようになります。
まとめると、Gitとはファイルのバージョン管理システムで、ファイルのバージョンを管理しないと、最新のファイルがどれか分からなくなったり、気が付かずに上書きしてしまったりします。
そういうことを防止するためにGitを使います。
Gitの歴史
Gitがどのようにして誕生したのかを見てみましょう。
誕生の流れを知っておくとGitの特徴が分かるし、Gitのことがもっと身近に感じられます。
みなさんは「リーナス・トーバルズ」という人を知っていますか?
この人はLinuxというOSを作った人です。
Linuxの開発をしていましたが、Linuxカーネル開発で利用していたバージョン管理システムのライセンスが変更され、使用できなくなってしまいました。
そこで、フリーのバージョン管理システムや他のシステムも検討してみました。
しかし、Linuxの開発というのは世界でもトップクラスに高度なものです。
その高度な要求水準を満たすフリーのバージョン管理システムがありませんでした。
それなら自分たちでLinux開発用のバージョン管理システムを作ってしまおうと、2005年頃にGitの原型となるプログラムの開発を開始しました。
いけてるものがないのなら自分たちで作ってしまおうと言うのがGit誕生のきっかけです。
因みに他のシステムの何がいけなかったかと言うと、複数人での開発の場合は、ブランチというものを切って分散して開発できるようにしますが、そのブランチを切ったり、切ったブランチを統合するマージするというのにすごく時間が掛かりました。
要は複数人、特に大規模に開発するのに、非常に使いにくかったのです。
なのでGitでは大規模なプロジェクトが迅速に出来るように開発されています。
具体的には、「高速」「シンプルな設計」「ブランチが並列で開発可能」「大規模プロジェクトを効率的に取り扱える」ように開発されています。
一番最初はハッカーにしか使えないような荒削りのものだったらしいですが、多くの開発者の協力を得て、今では世界中のプログラマに利用されるようになっています。
GitHubってなに?
GitHubって何なのか、GitHubについて紹介します。
GitHubは元々創業者のクリス・ワンストラスのサイドプロジェクトとしてスタートしました。
元々Gitのファンで、Gitを使いながらオープンソースの開発をしていました。
ただ、当時、オンラインでコードをシェアすることが非常に難しかったのです。
そこで他の開発者とコードをシェアしやすいGitリポジトリのホスティングサービスが欲しくて作られました。
改めてGitHubとは何かというと、Gitリポジトリのホスティングサービスになります。
これだとだいぶ分かりにくいですね。
噛み砕いて言うと、Gitでファイルの変更履歴を管理しているのですが、そのファイルやファイルの変更履歴をオンライン上で預かってくれるサービスになります。
Gitが自分のパソコンにいて、GitHubに対して「コードを預かってよ!」と言うと、GitHubが「任された!」と言ってコードを保管してくれます。
次にGitHubの特徴について見て行きます。
GitHubの特徴として、ただのGitリポジトリのポスティング機能だけではなく、開発者やチームが良い開発のためのコラボレーションが出来る機能を提供しています。
そのひとつが「プルリクエストによる複数人での開発」です。
プルリクエストはGitHubにあるGitリポジトリ(コード)に対して自分の変更したコードを取り込んでもらえるように、リクエストをする機能です。
「バグを修正したので取り込んでもらえないか」とか、「機能を追加したので取り込んでもらえないか」といった感じで変更の取り込みをリクエストします。
プルリクエストを元にコメントのやり取りもできるので、リクエストに対して「ありがとう。取り込むよ。」と伝えたり、「これは取り込めない。」と却下したり、「もっとこういう風にしてくれ。」と修正依頼を出すこともできます。
このプルリクエストのおかげでコードのレビューがしやすく、チームでの開発が非常にやりやすくなりました。
特徴の二つ目が世界中のチームがGitHub上で開発をしていること、他チームのソフトウェアが見えることです。
世界でどんな開発が行われているかを見ることができますし、さらにそこに参加することもできます。
そのことからGitHubは「ソーシャルコーディングの場」とも呼ばれています。
オープンソースのソースコードに見ず知らずの人が集まってきてフィードバックを貰ったり、開発に参加したりして貰いながらコーディングするスタイルのことです。
GitHubが登場してからオープンソースの開発の敷居が低くなり、一般のエンジニアでもオープンソースの開発がしやすくなったので、是非オープンソースの世界に足を踏み入れて見て下さい。
参考図書
独学で挫折しそうになったら、オンラインプログラミングスクール