gitとgithubのオペレーション方法の説明無しに考え方だけ説明してみる。

gitの説明が難しいのは、オペレーションの方法とgitの概念を同時に説明しようとしてるからだと思う。よくある時系列のブランチツリーの説明がわかりにくいのも、車の機能や挙動を知らないのにいきなり縦列駐車をする方法を教えるようなものだと考える。

確かに習うより慣れろというのは確かで、車の運転と同じく、操作感については、メンタルモデルを体で身につけるしかないのだが、その前にgitの用語や基本的な考え方がわかってないと、無意味にいじっても混乱をきたすだけです。残念ながら、そこをわかりやすくナビゲートしてくれるような直感的なデザインにはなっていません。

この記事では、本当にわかりやすいかどうかはともかく、gitの概念だけ書き連ねてみます。

まずは、gitのことをつかむための、お勉強モードとして読んでいただけるとありがたい。この文章を読んで、具体的な手順やコマンドを調べてみたいと、ジワジワ思ったら勝ちだと思っています。

ユーザー(あなたのことです)

github-user

まずはユーザー。githubならアカウントのことで、作業する手元のPCのことも示しますし、いきなり難しいことを書くと、本番環境のフォルダのことでもあります。

gitで連携する設定をするのは、FTPでソースコードをダウンロードするのとは違い、github上のユーザーが持っているリポジトリと呼ばれる情報と、あなたのPC内のどのフォルダでも連携することができますし、本番環境のソースコードを置くフォルダともつながることができます。

その設定をすることによって、一度セットアップしたソースコードのセットを誰かが作った最新にしたり、リリースしてみたらバグが見つかったので、前の状態に戻すようなことをコマンド一発でできるようになります。

それらの環境には、githubの基本設定がしてあって、こことここが結びつきますよーという宣言が必要です。

ユーザーは、ソフトウエアを公開するための「リポジトリ」というものを複数所有することができます。

このユーザーは、個人で管理することもあれば、企業が保有するアカウントとして複数人で管理することも可能です。仕事でgithubを使う場合は、自分のアカウントを作って、チームとして登録することで、ソースコードの登録権限(コミット権限と言います)をもらい、共同でソースコードを管理ができるようになります。

リポジトリ

github-repos

gitにおけるリポジトリは、ソフトウエアの開発プロジェクト毎に存在するソースコードの保存場所です。さらにWebサービスとしてのgithubにおけるリポジトリは、gitにSNS機能のようなものが追加してあって、ソースコードの更新情報に加えて、ドキュメントや、todoリスト、一緒に作業しているメンバーとのコラボレーションの情報が含まれています。

もっとも大枠のプロジェクトの単位として覚えておきましょう。

ブランチ

github-branch

ブランチというのは、ソースコードのコピーを作ることができる機能です。新たにブランチを作り、そこでソースコードを改良した場合、別のブランチと競合することなく、開発作業を進めることができます。

gitコマンドを使って、ブランチを切り替えることで、さまざまな開発状態のソースコードセットを自由に切り替えることができます。この機能を通じて、新機能を追加したり、他の人と同時並行でも、快適に作業をすすめることが可能になります。

自分専用のブランチで開発作業が終わった後に、他のブランチに変更を反映する「マージ」という作業をすると、リリースに向けて手順を進めることができます。

ブランチの中でも、もっとも基本的なブランチを「マスターブランチ」と呼び、全てのソースコードは、このマスターブランチにマージすることになります。

この辺のオペレーションを始めると、いろんな便利機能や不便利な機能で苦しむことになります。その辺は全員が通る道なので慌てずゆっくり何が置きているのかをぐぐって、そこに書いてあることを理解するようにしてみてください。聞ける人が周りにいるなら、遠慮せず聞く方が早いです。

コミット

github-commit

コミットとは、特定のブランチにおいてソースコードを更新した際の変更したソースコードのセットを示します。自分のPCで開発作業をした後に、その時点のソースコードのセットを「コミット」というgitのコマンドを使って登録し、その後、githubに登録するpushというコマンドを使うことで、github上に修正情報を反映することができます。

このコミットの過去の履歴を調べると、これまでどのようなソースコードの変更をしてきたのかがわかるので、後でソースコード上の問題が起きたときの対処が簡単になります。また、多くのソフトウエアは、最初は小さく産んで、さまざまな修正を加えたり、新機能を追加して、プロダクトを成長させていきます。それにあわせてコミットの数も増えていくことになります。

プルリクエスト(ぷるりく)

github-pull-req

プルリクエストとは、誰かが特定のブランチで開発作業をした後、その修正を提出する時に発行されるものです。

gitコマンドで、更新されたソースコードを取り込むためのpullというコマンドに由来しており、相手にpullを促すという意味でプルリクエストと言われている。

プルリクエストを受けたソースコード管理者は、その修正差分を取り入れるかどうかを決定し、必要であれば取り込むし、そうでなければ突き返しても良い。特に、インターネットを介したオープンソースの開発において、この機能があることで、誰でも開発に参加し、かつ、安定的にプロダクトの管理を行うことができる重要な機能として考えられている。

リリース

github-release

リリースは、githubのおまけのような機能であるが、リリースした段階のソースコードのアーカイブを作ったり、変更ログを記述したりして、リリースの区切りをつけることができます。特に本機能がなくても、masterブランチ等をリリースに使っても問題ないが、今回のリリースは何をリリースしているのか?という機能一覧を作ることもでき、リリース管理機能として活用できるようになっています。

これらに示した機能を使って、Githubを活用したgitの開発フローは進んでいきます。

ちと実際のオペレーションについても軽く振れておくと、

0.【githubユーザー】を、githubに登録する。またローカルPCに、githubと接続する設定を行う。

1.【リポジトリ】を、自分のPCのローカル環境にコピー(checkout)し、
2.ソースコードを修正して、変更分を【自分のPC上のリポジトリ】に【コミット】
3.その変更分を、pushコマンドを通じてgithubの【リポジトリ】に反映
4.そこで生まれた、変更差分を他の人に提出するために【プルリクエスト】を送る
5.【プルリク】を受けたソースコード管理者が、ソースコードをレビューし、共有の【リポジトリ】に、マージして取り込む
6.【リリース機能】を使ったり、【リポジトリ】をそのまま本番環境にpullするなどして、本番にリリースする!

という流れになります。

ソースコードは自分以外の人もいじっているので、リリースしたら、再び1番に戻って次の開発作業を進めます。1では、checkoutというコマンドでローカル環境にコピーしましたが、一度、フォルダにリポジトリをまるごとコピー(checkout)してあるのなら、それ以降は、更新情報の取り込みだけでいいので、pullというコマンドを使えば、チームで開発した最新の情報を取り込むことができます。

ちなみに、ローカルのPCのソースコードを不用意に変更していると、その情報を消さないようにと、エラーを出してくれてpullや別ブランチへのcheckoutなどの作業が抑止されます。
それならそうと聞いてくれればいわけですが、ソースコードを守ってくれるという面では気が利くと言えば気が利くし、不案内っぷりについては、気が利かないと言えば気が利かず、ぶっきらぼうだけど過剰にいい人っぷりに、gitが少し面倒くさい理由でもあるのですが、いずれにせよコマンド一発で、一気に変更をなかったことにすることができますので、調べてみてください。そこでむやみにgitは難しくて使えないと抵抗するよりは、大人しく慣れたもの勝ちです。

gitの難しさは、何かミスを起こしたときの選択肢が沢山あるために、コマンドで指示しないといけないところです。ただ、それは柔軟に仕事をしていくにあたっては必要な機能だと思うので、必要な作業として勉強しましょう。

一つだけ、その状況を打開するために、リリースする気がないのに、適当にソースコードをコミットはしないようにお願いします。プロジェクトが混乱に陥ります。(あなたがやらなくても誰かが間違えるので、まぁチームとしては一度、二度はハマってもよいと思います)

また、チームの同意なく、リポジトリそのものを古い状態に巻き戻したりは禁物。自分がやろうとしてることを、しっかりぐぐって、正しく解決することを心がけましょう。チームで使うものですから、時には周りと相談していきながら慣れていく、それが早く習得できるコツです。

【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください