#書こうと思った背景
会社でGit・GitHubでソースコードのバージョン管理を行うにあたり、そもそも**「バージョン管理する理由ってなんだっけ？？」**ってなったので、会社が紹介してくれた「VCS入門」という資料を読んでみました。その印象に残った点について自分用メモとして引用&記載させていただきます。
※VCS：Version Control System
#印象に残った点
###VCSはルールと対になって初めてその真価を発揮する
VCSを使えばハッピー・・・なはずでしたが、どうやらVCSを使った「だけ」では、そうはならないようです。
問題を整理してみると、リポジトリへの反映時に次のようなことが起きているようです。
1.「とりあえず」反映している
2.「どうやったのか」をメッセージに書いている
3.動かないものも反映している
4.複数の変更を盛り込んでいる
[・・・]
そこで、まずは最低限作業フォルダーの内容をリポジトリに反映する際のルールを決めましょう。先ほどの良くない例を見れば、守るべきルールが見えてきます。それが次のルールです。
・「時間」ではなく「作業」の単位で行う
・「どのように」ではなく、その作業を「何故」「何を」「何のために」行うかをメッセージに残す
・動かない成果物はリポジトリに反映しない
・一度に一つの変更だけ反映する
これらのことから、VCSのVersion（バージョン、版）とは「ファイル単位の改訂内容」を表すのではないことがわかると思います。Versionとは「作業単位の変更内容」を表すのです。このことを忘れないようにしてください。
これまで「実務で絶対使うから！」ということで、なんとなくGitを使っていたのですが、その目的を実現するにも、きちんとしたルールを設定しないといけないということですね。
###VCSのルールを設定するための考え方（SCM）を意識して運用せよ
ここで最初に立ち戻り、VCSを導入することで何がしたかったのか、考えてみることにしましょう。
VCSがない状態では、次の問題がありました。
・作業履歴が残らない
・他の人と作業がぶつかる
また、VCSを導入した後、ルールが無ければこんな問題がありました。
・履歴から目的の変更を探せない
・履歴の一つが、どういったきっかけで変更されたかわからない
以上の問題から、VCSを使って行いたかった事とは、
・各バージョンを識別したい
・特定のバージョンを再現したい
・何故変更が行われたのか知りたい
・他の人と連携して作業を行いたい
ともいえると思います。
これらを実現するための考え方が「SCM（Software Configuration Management、ソフトウェア構成管理）」です。
[・・・]
では、構成を管理するとはどういうことかを、そもそもの目的から導くと、次のようになります。
ある時点でのソフトウェアを構成する要素すべてを、識別、再現、追跡出来るようメンバー間で成果物を共有し、連携を促すための仕組み、ルール、プロセスを構築し、運用する
このためには、最低限その変更がどのような「依頼」によるものなのかを、それぞれの要素に紐付け、その組み合わせの履歴を残していかなければなりません。
###GitHubのissueがなぜ機能として存在しているのか
SCMは「変更依頼」の管理も含めてSCMである、と説明してきました。主な変更依頼のトリガーとしては、「バグ」、「仕様変更」等があります。
こういったものは、多くの組織ではそれぞれ「バグ管理票」、「QA票」などで管理されていると思います。しかし、もともとはそれぞれが別文書であるということもあり、「どこからきてどこへ行くのか」追跡がしにくいという問題があります。
このケースへの対応としては、変更依頼のトリガーとなる事象を一元管理する必要があります。ただ、その数は膨大で、とても手書やExcelシートで管理できるものではありません。
そこで、変更依頼を管理するためのツールの出番です。こういったツールは一般的に「ITS（Issue Tracking System、課題管理システム）」と呼ばれます。
ITSでは、Issue（課題）を「Ticket（チケット）」という単位で登録します。このチケットには一意となる番号（チケット番号）が振られ、担当者を割り当てたり、関連する内容をコメントしたりする機能があり、課題を完了したらチケットを「閉じる（クローズする）」決まりになっています。
これにより、今残っている課題、終わった課題、誰が担当しているかなどが明確になり、管理が容易になります。
また、ITSにはVCSと連携する機能があり、チケット番号をメッセージに入れてそのチケットに関連する履歴を参照したり、完了したことを表すメッセージを入れると自動的にチケットをクローズしたり、といったことが可能になります。
こういった機能を活用することで、その変更が何を起点に誰が作業し、今終わっているのかどうか、そして作業履歴がどうなっているかを、一気通貫で追跡できるようになります。
GitHubのissueがなぜ機能として存在しているのか、理解しました。。。！
#参考
VCS入門