こんにちは、Pythonエンジニア育成推進協会 顧問理事の寺田です。私は試験の問題策定とコミュニティ連携を行う立場です。

皆さんもよく耳にする言葉として、Gitというものがあると思います。

Gitが何者かと言えば、開発しているプログラムのバージョン管理をしてくれるものです。

プログラムの開発中は、機能を追加したり、修正したりといったことをしますが、そこで生じた変更による差分を適切に管理してくれるにバージョン管理システムがあると、開発がとてもやり易くなります。

今回はそのGitについてお話したいと思います。

開発現場で重宝されるバージョン管理システムとは？

バージョン管理システムにはSubversion（SVN）などいくつかあり、15～20年ほど前から利用されてきました。バージョン管理システムはもはや、現代のソフトウェア開発において必ず必須なものというくらいに多くの現場で利用されています。

利用されるようになった理由は、冒頭でも書いた通り、システムの開発中には変更や改造、新しい機能の追加と言ったことは当たり前に行われるため、その変更された部分の差分を別のバージョンとして管理しながら進めていくことができるためです。ブランチ（枝分かれして開発）しつつ、機能を選定し、追加・改修できるところや、前のバージョンに戻したいときには簡単に戻せること、そして、機能を追加した新しいバージョンを別の場所に保存するといったことを簡単にできるというところにメリットがあります。

このように、開発をする上でとても便利な機能を持っているので、個人的な開発であっても、仕事上の開発であっても、多くのプログラマーが開発するときにはGitなどのバージョン管理システムは必須で使われています。

コラボレーション機能など保有の「Git」はとても便利

さて、先ほど例として挙げたSVN自体は確かにとても良いシステムではありましたが、いろいろなところとのコラボレーションなどで使いにくさを感じていたころに、Gitが登場しました。Gitの利便性の高さから、近年はGitを利用されることが増え、今ではデファクトスタンダードと言えるほど、一般的に利用されるようになりました。実際、私や周囲ではバージョン管理システムはGitが利用されています。

なので、ぜひGitを覚えて、個人のプロジェクトであっても利用し、慣れていくのをおすすめしています。

私自身、プロジェクトを始める時には、必ずGitで何かしらのリポジトリを作成するところから始めます。

ただ、Git自体はとても難しいツールです。簡単な概念ではありませんし、簡単に利用できるものでもありませんが、以下の6個のコマンドを覚えれば、最低限の機能を使い始めることはできます。

＜最低限覚えておきたいGitで使うコマンド＞

• git clone
• git add
• git commit
• git checkout
• git push
• git pull

使っていくうちに他にも必要になってくるコマンドはありますが、まずは上記の6つを覚えてみましょう。用途はここでは割愛しますが、Webサイトや本などで学びながら覚えて、使っていってほしいと思っています。

「Git」と「GitHub」の関係性

Gitはローカルとリモートのリポジトリを管理することができます。

手元で動かす場合には、バックアップ的なものや、他の人と一緒に作業するコラボレーションができないため、センターリポジトリを配置するのが一般的です。リモート（外部）に置くものです。リモートを複数置くこともできますが、特殊な例と言えます。

そのセンターリポジトリが、GitHubと呼ばれるサービスです。

GitHubは、Gitのリポジトリをホスティングしてくれるサービスです。それもある一定のレベル範囲で使用するのであれば無料で使えます。特に、オープンソースのような外部に公開してもいいような、パブリックのリポジトリであれば、基本的に無料で使えます。

そのため、GitHubはセンターリポジトリとしてよく使われています。これはGitを使っている人が、必ずGitHubを使用しなければならないというものではなく、GitHubという選択肢があるというものです。他に似たようなサービスとしては、GitLab（ギットラボ）やBitbucket（ビットバケット）など、他にもGitのセンターリポジトリをホスティングしてくれるたくさんのサービスがあります。

ただ、その中で、GitHubは多くのオープンソースや企業でデファクトスタンダード的に利用されています。よほどの理由がない限りはGitHubを選択することがほとんどです。もちろん、絶対にGitHubでなくてはならないという事ではありません。

「Git」と「GitHub」の使い方

さて、手元で開発するときにはGitを使い、GitHubをセンターサーバとして使うというよくあるパターンの例でいくと、GitHubでリポジトリを作り、そこから最初にcloneで空のリポジトリを持ってきます。その後、開発したファイルをaddしてcommitしますが、commitしただけでは手元に履歴を上げているだけになってしまいますので、その後にセンターリポジトリであるGitHubに向けてpushします。

こうすることで、開発に携わる他のメンバーはGitHubからpullすれば同じものを手に入れることができます。逆に、自分が他の開発メンバーがcommitしたものをpullすることもできます。

つまりGitとGitHubを使うことで、開発メンバー間でのプログラムの共有を楽に行うことができるという事です。

「GitHub」の機能、プルリクエストとは

GitHub用語に「プルリクエスト（略：PR）」という言葉があります。「プルリクエスト」という言葉は実はサービスによって異なっており、先ほど例として挙げたGitLabではマージリクエストという名前です

Gitには先ほど説明をしなかった「ブランチを切る（枝分かれをさせる）」という機能があります。何らかの開発を複数人でやる場合は特にですが、開発現場では機能を枝分かれさせて開発を進めるという事はよくあります。例えば、新しい表示機能を作りますというブランチを作り、それをGitHubなどに向けてpushします。そうすると、枝分かれした新しく作られたブランチがセンターリポジトリと自分の手元にもあるという状態になります。

そして枝分かれした機能を［git marge］コマンドでマージして、最終的にひとつのプログラムを作り上げていきます。

以下がGitを使った一般的な開発の流れです。

（もちろん、ワークフローのルールはこれに限らず、いろいろなところで様々な提案がされており、他のやり方を取っているところはあります。）

①開発者Aがブランチを切って新しい機能を追加し、センターリポジトリにpush

②開発者Aは、他の開発者にプルリクエスト機能を使ってマージを依頼する

③他開発者は、GitHub上で開発者Aのプルリクエストから、差分を確認し、問題がなければ承認（approve）して、PRをマージする

④作業を完了する

このように、複数人が別の機能をどんどん作り、GitHub上でソースコードをお互いに共有・確認して結合するという、プルリクエストとマージを繰り返してひとつの機能を完成させていきます。

［git marge］コマンドを使うシーンは減っており、GitHub上かセンターリポジトリのプルリクエスト機能を使って行われることが多くなっています。

これは多くのオープンソースの世界でもそうしていますし、ここ最近のこの開発の流れ的には、仕事においても、オープンソース活動においても、さらには個人活動においても、このようなやり方をすることが多いかなと思います。

もちろん、１人でやる時は自分だけしかいないので、プルリクエストを作るのが面倒ですがセルフチェック、セルフマージで行うこともあります。

ところで、こんなに複数人であちこちを触ってきちんとマージできるのかと心配になると思いますが、その辺、Gitは上手くやっており、行単位で差分を確認しています。同じ行で変更があった場合にはコンフリクトというメッセージが出て、マージされることはありません。

このコンフリクトの解消については別のステップになりますので、ここでは割愛します。

「Git」＋「GitHub」が個人的ベスト

現在、私は３人のプロジェクトを実行中で、私が仕様やスペック面のリーダーとして立ち、技術面は別の人がリーダーとして行っています。ここでは、毎日お互いにプルリクエストを送信して、改造部分を確認やレビューしつつ修正を繰り返して作っています。

プルリクエストやブランチと言った機能は元に戻しやすいというのが大きな利点です。もし間違いが起きていても、プルリクエストを取りやめたり、前のものに戻したりということをGitの機能で出来るため、簡単に進めることができます。

また履歴が残っているため、新たにメンバーに入った人が以前の更新履歴を確認して、追加された機能の意図を把握しやすいのも大きな利点といえます。

例えばオープンソース系は世界中に開発者がいる状態で行われ、リリースマネージャー的な立場の人が機能の承認・非承認を行います。ただ新しくバージョンを重ねていくごとに内容の把握がしにくくなりがちです。Gitのようなバージョン履歴管理システムを利用すると、変更理由を追いやすく、理解が早くなります。

Gitにこだわる必要はありませんが、バージョン管理システムの利点は大きいのでぜひ利用していきましょう。

特に理由がないのであれば、GitとGitHubで良いかなと思います。

GitHubにはプライベートなリポジトリも作れますので、用途に合わせて公開・非公開で使い分けしていってください。

ちなみに私が書籍の原稿を書く際にもGitHubのリポジトリを利用して、文書やコードを管理しています。

開発をする上ではGitとGitHubのセットが一番使いやすいと感じています。もちろん、GitHubは代わりのものがあるのは確かですが、もうこの２つのツールがないと先が進まないというほど頼っています。

開発周りのタスク管理も重要

いい機会なので、開発周りのお話をもう少ししてみます。

開発をするときには、どんなタスクがあって、次は何をしなければならないか、優先順位は何かと言ったことを考えますが、こうした時には課題管理ツールを使うと思います。特に複数人の開発現場では必ず必要なものになっています。

課題管理ツールにはすごくたくさんの種類があり、GitHubのようにこれがデファクトだと言えるほどのおすすめは特にはありませんが、GitHubにはという課題管理ツールがついてます。

特にオープンソース系の開発においては、GitHub Issuesで管理するか、GitHub IssuesをちょっとラッピングしたGitHub Projectsを使って、タスクやバグ、機能要望などの管理をしています。

ここでは、Gitのコミットやプルリクエストを紐づけておくことができますので、本当に何をしたかったのかを、コード以外のドキュメンテーションまたはディスカッションで、振り返ることができます。そうすることで、改造の意図がわかりやすくなります。

私も最近は課題管理ツールを中心に、次にやるべきもの、今すぐやらなければいけないものを考えて、コミュニケーションを取り、課題に対してのソースコードやドキュメンテーションを変更し、コミットして、プルリクエストを出すというような流れを作っています。

この方法をはじめた当初はGitHub Issues かGitHub Projectsで十分かなと考えていました。最近は新しいものを見つけたので、今は、GitHub Issuesではない別の課題管理ツールを使っています。

課題管理ツールに何を書くかと言えば、何でも書いてくということを心がけています。

実験したこと、失敗したこと、考えてダメだったこと、調査していることなど何でもです。特に間違ったことや、ダメだったこと、この技術を採用しない理由のようなものを、残しておいた方がいいと思っています。なぜかと言えば、プログラムには完成形の結果しか残らず、採用した経緯や流れは残らないからです。そこを見れば当時の考えが理解できるというのは、自分の学びだけでなく、後々になって助けになります。

もちろん量が増えてしまって、把握しにくいこともあるかもしれませんが、そうなった時には別のドキュメンテーション手段として取りまとめていくというようなやり方になるのかなと思ってます。

課題管理ツールも昨今の開発ではとても重要な1つのツールです。

ただ、比較的、使う理由がわかりにくいと考えている人は多いようです。ですが、プロジェクトをやる上では、今どれだけの課題があるのか、または、どれだけのエラーがあるのか、やりたいことはどれだけあるのかというのをわかるようにしておくためには、必須のツールだと思っています。

課題管理ツールがたくさんありますので、ご自身にあったものを見つけて使ってみて頂ければと思います。

Gitのようなバージョン管理システムや課題管理システムは、使いこなしが上手い人ほど開発も上手です。

覚えなくてはならないことも多いとは思いますが、ぜひ覚えて使ってみてください。