30 |
31 | この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。
32 |
33 | ## 派生プロジェクト
34 | - Gitをはじめからていねいに written by [@Shinpeim](https://github.com/Shinpeim) (*Thanks!*)
35 | https://github.com/Shinpeim/introduction-to-git
36 | - Subversion入門 for Windows written by [@masaru-b-cl](https://github.com/masaru-b-cl)
37 | https://github.com/masaru-b-cl/introduction-to-svn
38 |
--------------------------------------------------------------------------------
/3.world-with-vcs.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次") | [← 2章 VCSでできること](2.power-of-vcs.md "VCSでできること")
2 |
3 | # VCSのある世界
4 |
5 | さて、VCSが無いことで痛い目を見た開発プロジェクトが、その後VCSを導入した世界をまた覗いてみましょう。
6 |
7 | ## 後日
8 | あなたの開発チームは先日の反省を踏まえ、VCSを導入することになり、サーバーにリポジトリが用意されました。
9 |
10 | 
11 |
12 | 図3-1 リポジトリ
13 |
14 | あなたはまず、作業を行う準備として、PC内に作業フォルダーを作成しました。
15 |
16 | 
17 |
18 | 図3-2 作業フォルダー作成
19 |
20 | 次に作業対象のファイルの作業コピーを、リポジトリから取得しました。
21 |
22 | 
23 |
24 | 図3-3 作業コピー取得
25 |
26 | あなたは、幾つかの作業コピーのドキュメントやソースを変更し、動作を確認しました。
27 |
28 | 
29 |
30 | 図3-4 作業コピー編集
31 |
32 | 作業を終えたので、作業コピーの変更をリポジトリに反映しようとしました。すると、競合が発生したため、反映処理に失敗しました。
33 |
34 | 
35 |
36 | 図3-5 競合発生
37 |
38 | 発生した競合についてVCSを使って調べてみました。すると、田中一郎さんが先にリポジトリに反映した変更と競合していることが分かりました。
39 |
40 | あなたは早速田中一郎さんと相談し、田中一郎さんの編集した部分を残しつつ、自分の変更を競合したファイルに反映しました。
41 |
42 | 
43 |
44 | 図3-6 競合ファイルの編集
45 |
46 | 競合が無くなったところで、改めてリポジトリに変更を反映して無事作業を終えました。
47 |
48 | 
49 |
50 | 図3-7 リポジトリに反映
51 |
52 | ## VCSでハッピーに
53 |
54 | これまでシミュレーションしてきた話は、いささか恣意的な例であることは否定しません。
55 |
56 | しかし、実際の開発現場ではもっと構造が複雑で、対象となるファイルも多く、メンバーも多数であることがほとんどです。こういった環境では、共有フォルダーでの管理は、事実上不可能であるといっても過言ではありません。
57 |
58 | そういった複雑な環境でもVCSというツールを使うことで、自分も他のメンバーも、安心して作業を進めることができます。こういった連携を行うためにも、VCSは不可欠なものなのです。
59 |
60 | [→ 4章 VCSのみでの限界](4.end-of-world-with-only-vcs.md "VCSのみでの限界")
61 |
62 | ----------
63 |
64 |
--------------------------------------------------------------------------------
/2.power-of-vcs.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次") | [← 1章 VCSのない世界](1.world-without-vcs.md "VCSのない世界")
2 |
3 | # VCSでできること
4 |
5 | VCSのない世界で何が起きるかイメージ出来たところで、VCSで何ができるのかを見ていきましょう。
6 |
7 | ## VCSの力
8 |
9 | VCSの能力は、主に次の2つです。
10 |
11 | 1. 履歴を残す
12 | 1. 作業の競合を防ぐ
13 |
14 | ### 1. 履歴を残す
15 |
16 | VCSでできることの一番大きなものは「作業履歴を残すこと」です。これは、言い換えると「誰が」「いつ」「何を」したかが残るということになります。
17 |
18 | | 4/14 10:14 | 21 |○○機能を追加 | 22 |田中一郎 | 23 |
| 4/14 09:34 | 26 |△△機能のバグを修正 | 27 |鈴木花子 | 28 |
| ... | 31 |... | 32 |... | 33 |
--------------------------------------------------------------------------------
/5.wisdom-of-scm.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次") | [← 4章 VCSのみでの限界](4.end-of-world-with-only-vcs.md "VCSのみでの限界")
2 |
3 | # SCMという智慧
4 |
5 | VCSという「ツール」を導入しても、そこに「ルール」が加わらなければ意味がないと言いました。ここでの「ルール」とは何なのか、もう少し詳しく考えてみましょう。
6 |
7 | ## 何がしたいのか？
8 |
9 | ここで最初に立ち戻り、VCSを導入することで何がしたかったのか、考えてみることにしましょう。
10 |
11 | VCSがない状態では、次の問題がありました。
12 |
13 | - 作業履歴が残らない
14 | - 他の人と作業がぶつかる
15 |
16 | また、VCSを導入した後、ルールが無ければこんな問題がありました。
17 |
18 | - 履歴から目的の変更を探せない
19 | - 履歴の一つが、どういったきっかけで変更されたかわからない
20 |
21 | 以上の問題から、VCSを使って行いたかった事とは、
22 |
23 | - 各バージョンを識別したい
24 | - 特定のバージョンを再現したい
25 | - 何故変更が行われたのか知りたい
26 | - 他の人と連携して作業を行いたい
27 |
28 | ともいえると思います。
29 |
30 | これらを実現するための考え方が「SCM（Software Configuration Management、ソフトウェア構成管理）」です。
31 |
32 | ## 「構成」とは
33 |
34 | いきなりSCMと言われても何のことかわからないと思います。そんな時は、問題を小さくしていきましょう。
35 |
36 | - Software : ソフトウェア
37 | - Configuration : 構成
38 | - Management : 管理
39 |
40 | ですので、そのまま読めば「ソフトウェアの構成を管理する」となります。「ソフトウェア」と「管理」は良いとしても、「構成」とは何のことでしょうか？
41 |
42 | 「構成」を辞書で引くと、次のように説明されています。
43 |
44 | > こうせい 0 【構成】
45 | >
46 | > （名）スル
47 | >
48 | > 1. いくつかの要素を組み立てて一つのまとまりあるものにすること。また、その組み立て。
49 | > 「社会を―する一員」
50 | >
51 | > 1. 〔哲〕〔construction〕経験によらずに概念・形式・イメージなどを操作することで対象を組み立てること。
52 | >
53 | > \- [構成とは - 三省堂 大辞林 Weblio辞書](http://www.weblio.jp/content/構成) より -
54 |
55 | つまり、「ソフトウェア構成」とは「ソフトウェアというまとまりがどのような要素の組み合わせでできているか」となります。
56 |
57 | 
58 |
59 | 図5-1 ソフトウェア構成
60 |
61 | ## ソフトウェアを構成する「要素」
62 |
63 | では、ソフトウェアがどのような「要素」から成り立っているのか考えてみると、
64 |
65 | - ソースコード
66 | - コンパイラー
67 | - ライブラリ
68 | - ランタイム
69 |
70 | といったものが出てきます。もう一歩踏み込んで、ソフトウェアの振る舞いがどこから出てきたかを考えると、
71 |
72 | - 設計書
73 | - バグ管理表
74 | - QA票
75 |
76 | といったドキュメント類まで範囲に入ります。さらに踏み込むと、その「要素」の大本は、「こうしたい」、「こうであってほしい」という
77 |
78 | - 依頼
79 |
80 | もまた、ソフトウェアを構成する要素と考えることができます。
81 |
82 | 
83 |
84 | 図5-2 ソフトウェアを構成する要素
85 |
86 | ## どう管理するのか
87 |
88 | では、構成を管理するとはどういうことかを、そもそもの目的から導くと、次のようになります。
89 |
90 | **ある時点でのソフトウェアを構成する要素すべてを、識別、再現、追跡出来るようメンバー間で成果物を共有し、連携を促すための仕組み、ルール、プロセスを構築し、運用する**
91 |
92 | このためには、最低限その変更がどのような「依頼」によるものなのかを、それぞれの要素に紐付け、その組み合わせの履歴を残していかなければなりません。
93 |
94 | そのために、VCSをどのように活用すればよいのか次の章で説明していきましょう。
95 |
96 | [→ 6章 SCMを意識したVCS利用](6.dance-with-scm.md "SCMを意識したVCS利用")
97 |
98 | ----------
99 |
100 |
101 |
--------------------------------------------------------------------------------
/6.dance-with-scm.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次") | [← 5章 SCMという智慧](5.wisdom-of-scm.md "SCMという智慧")
2 |
3 | # SCMを意識したVCS利用
4 |
5 | SCMの目的が分かったところで、その考えをどのようにVCS利用方法に取り入れていくか、考えていきましょう。
6 |
7 | ## VCSの活用法
8 |
9 | SCMでやりたいことを今一度まとめると、仕様変更、バグなどをトリガーとした「変更依頼」で発生した、ソフトウェア構成の変更履歴について、
10 |
11 | - 識別
12 | - 参照
13 | - 再現
14 |
15 | が出来なくてはなりません。
16 |
17 | このことから、VCSを使う際には次のことを意識する必要があります。
18 |
19 | 1. ソースコード以外も管理する
20 | 1. 履歴を識別するメタデータを付加する
21 | 1. 「タグ」を活用する
22 |
23 | ### 1. ソースコード以外も管理する
24 |
25 | VCSに対するよくある誤解の一つが「ソースコードのバージョン管理を行うツール」というものです。ですが、前の章で述べたように「ソースコード」はソフトウェアを構成する要素のほんの一部でしかありません。ソースコードだけ履歴を残しても、ソフトウェアを再現することはできないのです。
26 |
27 | したがって、原則としてソースコードの他に設定ファイルや設計書などのドキュメント類も、VCSで管理する必要があります。
28 |
29 | 
30 |
31 | 図6-1 VCS管理対象
32 |
33 | ### 2. 履歴を識別するメタデータを付加する
34 |
35 | ソースコード以外の履歴を管理するようにしたとして、今度はその履歴をどうやって「識別」するのかを考えなければいけません。4章で紹介した
36 |
37 | - 「どのように」ではなく、その作業を「何故」「何を」「何のために」行うかをメッセージに残す
38 |
39 | という使い方を心がけても、どんな変更が行われたかはわかりますが、それがどういった「変更依頼」を元に行われたかはわかりません。
40 |
41 | この問題を解決するには、まずVCSとは別のところで「変更依頼」が管理されていることが前提として必要になります。それは例えば、Excelなどで作られた「バグ票」、「QA票」、「仕様変更依頼書」などのドキュメント類があるでしょう。
42 |
43 | こういったドキュメントには、その名前とともに識別するための「番号」などが、大体付いています。この情報を利用しない手はありません。
44 |
45 | つまりどうするかというと、履歴のメッセージに「文書名-文書番号」といった「メタデータ」を埋め込んでしまうのです。このルールがメンバーで共有できてさえいれば、この「メタデータ」で変更履歴を識別することができるようになります。
46 |
47 | | 4/14 10:35 | 50 |
51 | バグ管理票-XX001 52 | ○○が××になっていたため、△△に修正する。 53 | |
54 | 高橋太郎 | 55 |
| 4/13 17:45 | 58 |
59 | QA管理表-1 60 | ○○については××とするよう変更する。 61 | |
62 | 田中一郎 | 63 |
| ... | 66 |... | 67 |... | 68 |
106 |
--------------------------------------------------------------------------------
/1.world-without-vcs.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次")
2 |
3 | # VCSのない世界
4 |
5 | VCSについて学ぶ前に、VCSのない世界ではどんなことが起こるのか、ちょっと覗いてみましょう。
6 |
7 | ## ある日・・・
8 |
9 | あなたはとあるシステム会社で開発を行うプログラマーです。今関わっている案件は小さなプロジェクトということもあり、少人数で開発を行っているため、ファイルサーバーの共有フォルダーで成果物を管理していました。
10 |
11 | 
12 |
13 | 図1-1 共有フォルダー
14 |
15 | あなたは、今日もいつものように開発を行おうと作業を始めました。
16 |
17 | ### 1. 作業対象ファイルの取得
18 |
19 | まずは作業対象となるドキュメント、ソースコードを共有フォルダーからコピーしなければなりません。あなたが昨日帰った後、他の誰かが作業しているかもしれないからです。
20 |
21 | あなたはいつものように、PCの作業フォルダーに、共有フォルダーの内容一式を上書きコピーしました。
22 |
23 | 
24 |
25 | 図1-2 作業対象ファイルの取得
26 |
27 | ### 2. ファイルの編集
28 |
29 | 作業対象ファイルをコピーしたので、あなたは作業に入ります。ドキュメントを編集し、ソースコードを合わせて編集し、ビルドして結果を確認する、こういった作業を繰り返します。
30 |
31 | 
32 |
33 | 図1-3 ファイルの編集
34 |
35 | ### 3. 作業結果の反映
36 |
37 | 気が付くとそろそろ業務時間が終わります。あなたはとりあえずここまでの作業結果をメンバーと共有するために、作業フォルダーを丸ごとファイルサーバーに上書きコピーしました。
38 |
39 | 
40 |
41 | 図1-4 作業結果の反映
42 |
43 | あなたは今日の仕事の充実感に浸りながら、帰路につきました。
44 |
45 | ## 明くる朝
46 |
47 | 次の日あなたが出社すると、何やらプロジェクトメンバーが揉めています。話を聞くと、システムをテストしようと思ったら、上手く動かなくなっていたと言うことです。
48 |
49 | 
50 |
51 | 図1-5 テスト環境破壊
52 |
53 | あなたは早速メンバーと協力して、障害の原因を調べ始めました。しかし、なかなか原因がつかめません。
54 |
55 | そして調査すること数時間、ようやく原因を見つけました。それはなんと、あなたが昨日編集したファイルが原因でした。同じファイルを他のメンバーも編集していたことに気付かずに、そのまま上書きコピーしてしまっていたことが原因でした。
56 |
57 | あなたとメンバーは、各自のPCに残ったファイルを元に、修復と変更箇所の統合を行いました。しかし対象となるファイルの数が多く、その作業は深夜まで及び、ようやくシステムがテストできるようになりました。
58 |
59 | ## 何が問題だったのか？
60 |
61 | 以上のような出来事は、共有フォルダーで成果物を管理する限り、大なり小なり必ず起こります。その原因を詳しく見ていきましょう。
62 |
63 | ### 1. 作業対象ファイルの取得
64 |
65 | まず、共有フォルダーから作業対象ファイルを取得する際の問題を見ていきましょう。
66 |
67 | #### (1) 本当に「最新」なのか？
68 |
69 | 共有フォルダーであるということは、他の開発メンバーも常に変更が可能です。つまり、「最新」と思っているものが実はコピー途中であるといった可能性が否定できない
70 | のです。
71 |
72 | #### (2) 特定の「バージョン」を取得できない
73 |
74 | 共有フォルダーは常にもっとも後に変更されたものしか管理できません。したがって、「一昨日変更したファイルを元に変更したい」といったケースに対応できません。
75 |
76 | ### 2. ファイルの編集
77 |
78 | ファイルを編集する際の問題点は次の通りです。
79 |
80 | #### (1) どのファイルを変更したのかわかりにくい
81 |
82 | 変更したファイルを簡単に特定する方法が無いため、変更後の共有フォルダーへの反映時に、漏れる可能性があります。
83 |
84 | #### (2) 元に戻せない
85 |
86 | 何らかの失敗や、変更のやり直し、試行錯誤段階など、変更を無かったことにしたいケースが開発の中ではよくあります。しかし、共有フォルダーからコピーするやり方では、再度コピーするしか方法がありません。
87 |
88 | #### (3) 作業対象の「バージョン」が一定しない
89 |
90 | 上記の元に戻す際、共有フォルダーから再度コピーすると、最初にコピーしたときと作業対象のファイルの「バージョン」が変わってしまいます（この作業対象のファイルの「バージョン」を、作業ベースと呼びます）。
91 |
92 | ### 3. 作業結果の反映
93 |
94 | 作業結果を共有フォルダーに反映するときも、落とし穴があります。
95 |
96 | #### (1) 他の人が同時に変更している可能性
97 |
98 | 自分が編集したファイルを他の人が同時に変更している可能性が常にあります。この時は「後勝ち」となるため、先に共有フォルダーにアップした人の変更分が、失われてしまいます。
99 |
100 | #### (2) 誤操作で削除する可能性
101 |
102 | 共有フォルダーは、誤操作で簡単にファイルを消すことができます。
103 |
104 | #### (3) 環境を壊す可能性
105 |
106 | (1)、(2)にも関連しますが、開発中の成果物が不正な状態になることで、簡単に環境が壊れてしまい、テストが不可能になってしまいます。
107 |
108 | ## では、どうするのか？
109 |
110 | 人間は間違う生き物です。これらの問題は「気を付ける」レベルで対処できるものではありません。
111 |
112 | では、どうするのか？
113 |
114 | そこで登場するのがVCSです。人間が間違いやすいところを、ツールでサポートすることにより、システム開発を円滑に進めることができます。
115 |
116 | では、次の章でVCSの特徴を学んでいきましょう。
117 |
118 | [→ 2章 VCSでできること](2.power-of-vcs.md "VCSでできること")
119 |
120 | ----------
121 |
122 |
--------------------------------------------------------------------------------
/7.road-to-scm.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次") | [← 6章 SCMを意識したVCS利用](6.dance-with-scm.md "SCMを意識したVCS利用")
2 |
3 | # SCMの次のステップ
4 |
5 | VCSだけではサポートできない部分がSCMにはあると説明してきました。では、どんな部分があり、どういったツールでサポートできるのか、その一部を紹介していきましょう。
6 |
7 | ## 変更依頼の管理
8 |
9 | SCMは「変更依頼」の管理も含めてSCMである、と説明してきました。主な変更依頼のトリガーとしては、「バグ」、「仕様変更」等があります。
10 |
11 | こういったものは、多くの組織ではそれぞれ「バグ管理票」、「QA票」などで管理されていると思います。しかし、もともとはそれぞれが別文書であるということもあり、「どこからきてどこへ行くのか」追跡がしにくいという問題があります。
12 |
13 | このケースへの対応としては、変更依頼のトリガーとなる事象を一元管理する必要があります。ただ、その数は膨大で、とても手書やExcelシートで管理できるものではありません。
14 |
15 | 
16 |
17 | 図7-1 変更依頼の一元管理
18 |
19 | そこで、変更依頼を管理するためのツールの出番です。こういったツールは一般的に「ITS（Issue Tracking System、課題管理システム）」と呼ばれます。
20 |
21 | ITSでは、Issue（課題）を「Ticket（チケット）」という単位で登録します。このチケットには一意となる番号（チケット番号）が振られ、担当者を割り当てたり、関連する内容をコメントしたりする機能があり、課題を完了したらチケットを「閉じる（クローズする）」決まりになっています。
22 |
23 | これにより、今残っている課題、終わった課題、誰が担当しているかなどが明確になり、管理が容易になります。
24 |
25 | また、ITSにはVCSと連携する機能があり、チケット番号をメッセージに入れてそのチケットに関連する履歴を参照したり、完了したことを表すメッセージを入れると自動的にチケットをクローズしたり、といったことが可能になります。
26 |
27 | こういった機能を活用することで、その変更が何を起点に誰が作業し、今終わっているのかどうか、そして作業履歴がどうなっているかを、一気通貫で追跡できるようになります。
28 |
29 | 
30 |
31 | 図7-2 チケットのライフサイクル
32 |
33 | ただし、これはあくまでツールを正しく活用できた場合であり、どのような粒度でチケットを作成するかや、どうやって膨大なチケットを管理するかといった課題もあります。これらの問題は、導入した組織で試行錯誤を繰り返し、徐々に洗練させていくしかないでしょう。
34 |
35 | ## 動くソフトウェアの作成
36 |
37 | ソフトウェアは動いてこそです。しかし、ソフトウェアを動作させるには、ソースコードからのコンパイル、実行環境への配置、環境設定など、様々な作業が必要です。この一連の作業を「ビルド」と呼びます。
38 |
39 | VCSの仕事はバージョン管理です。したがって、そのバージョンに対応した成果物としての「動くソフトウェア」を作ることは出来ません。代わりに成果物を作る役割を担ってくれるのが「ビルドツール」です。
40 |
41 | ビルドツールにはプラットフォーム毎に色々種類があり、それぞれの専用の構文で書かれた「ビルドスクリプト」を実行することで、ビルド作業を行います。
42 |
43 | また、VCSと連携してリポジトリに変更が反映されたタイミングや、決められたスケジュールでビルドツールの実行を行うツールもあり、これらは「自動ビルドツール」と呼ばれます。
44 |
45 | このビルドツール、自動ビルドツールを活用することで、VCSの履歴に対応したバージョンの動くソフトウェアを、随時作成することができます。これにより、テストを行う際、今動かしているソフトウェアのバージョンが何であり、どんな変更が加えられたものかを追跡することが可能になります。
46 |
47 | 
48 |
49 | 図7-3 ビルドプロセスイメージ
50 |
51 | ## 成果物のテストの管理
52 |
53 | 変更依頼を受け、作業を終え、成果物ができても、今度はその成果物をテストしないといけません。もちろん変更依頼により、テストすべき内容も一緒に変わります。
54 |
55 | この時、テスト設計書を修正してリポジトリに反映し、テスターはそのテスト設計書
56 | を元にテストを行い、結果を記入する、といったやり方が、これまでの一般的な方法でした。しかし、変化するスピードも速い昨今の開発では、このサイクルが追い付かない場合もあります。
57 |
58 | そんな時に使えるのが「テストツール」です。テストツールを使うと、ソフトウェアのテストをテスト用のプログラムを使って行うことができます。
59 |
60 | このテスト用のプログラムも、リポジトリに登録することで、変更依頼に対するテストを一緒に管理できます。
61 | ただし、テストツールによるテストでは、GUI（グラフィック ユーザーインターフェース）に関するテストはコストが高いため、あまり向いていません（不可能ではありません）。
62 |
63 | また、自動ビルドツールにより、ビルドのタイミングでテストを行わせることができます。このことを「自動化テスト」と呼びます。
64 |
65 | 自動化テストを利用し、テストツールで行えるテストはツールに任せ、テスターはGUIなど人の手によるテストに集中することで、テストの負担が軽くなります。
66 |
67 | 
68 |
69 | 図7-4 自動化テストイメージ
70 |
71 | ## 他にも・・・
72 |
73 | SCMをサポートするために、ソフトウェアの品質を測るために、様々なメトリクス（コード行数、複雑度、etc...）、コードの品質（適切な命名、バグを誘う記述の有無、etc...）、パフォーマンステストなど、様々なことを行ってくれるツールがあります。これらを自動ビルド、ITSと組み合わせることで、SCMで扱う範囲がどんどん広がります。
74 |
75 | また、ITSを顧客や上位組織と共有して課題の進捗状況などを共有することで、よりスムーズな連携を促すこともできます。
76 |
77 | こういったプロセスの運用、管理も含めてSCMであることを忘れないでください。
78 |
79 | ## 最後に
80 |
81 | VCSが無いとどうなるかから始まり、何ができてどのような問題を解決するか、そして一歩進んだSCMという考えをどうVCSと連携させていくかについて説明してきました。
82 |
83 | VCSは所詮ツールです。使える局面は限られますし、ちゃんと使わなければその有効性も発揮できません。ぜひ、ツールの背景にある概念、想定された使い方を理解し、開発を円滑に進められるよう、メンバーと話し合い、共有してみてください。
84 |
85 | 本文書があなたの開発を進める手助けに、ほんの少しでもなれば幸いです。
86 |
87 |
88 | [→ 付録 : 参考文献](A.reference.md "付録 : 参考文献")
89 |
90 | ----------
91 |
92 |
93 |
--------------------------------------------------------------------------------
/4.end-of-world-with-only-vcs.md:
--------------------------------------------------------------------------------
1 | [↑目次](readme.md "目次") | [← 3章 VCSのある世界](3.world-with-vcs.md "VCSのある世界")
2 |
3 |
4 | # VCSのみでの限界
5 |
6 | さて、VCSを使うと、それだけでハッピーになれるかというと、世の中そんなに甘くありません。例えツールを使っていても、協調作業（コラボレーション）を行うには、各人が好き勝手していては上手くいくはずもありません。
7 |
8 | そんな世界をまた少し覗いてみましょう。
9 |
10 | ## 数週間後
11 |
12 | VCSを導入したあなたのチームは、しばらく何の問題もなく開発を続けていました。
13 |
14 | そんなある日、何日か前に行った仕様変更で、影響があった成果物を調査してほしいという依頼を受けました。何でも、どうやらその仕様変更で、他の機能の動作が少しおかしくなっているらしいのです。
15 |
16 | あなたは早速VCSの機能を使って、リポジトリの変更履歴を見てみました。
17 |
18 |
19 | | 4/14 13:31 | 22 |○○機能に△△処理と××処理を追加した。ついでに□□のバグを修正 | 23 |斎藤京子 | 24 |
| 4/14 11:55 | 27 |昼休み前のコミット | 28 |田中一郎 | 29 |
| 4/14 10:35 | 32 |コンパイル失敗するけど、原因が分からないので一応コミット | 33 |高橋太郎 | 34 |
| 4/14 10:14 | 37 |hoge.csファイルにdoFugaメソッドを追加 | 38 |田中一郎 | 39 |
| 4/13 18:01 | 42 |4/13日分コミット | 43 |鈴木花子 | 44 |
| ... | 47 |... | 48 |... | 49 |
| 4/14 11:55 | 74 |昼休み前のコミット | 75 |田中一郎 | 76 |
| 4/13 18:01 | 81 |4/13日分コミット | 82 |鈴木花子 | 83 |
| 4/14 10:14 | 95 |hoge.csファイルにdoFugaメソッドを追加 | 96 |田中一郎 | 97 |
| 4/14 10:35 | 111 |コンパイル失敗するけど、原因が分からないので一応コミット | 112 |高橋太郎 | 113 |
| 4/14 13:31 | 125 |○○機能に△△処理と××処理を追加した。ついでに□□のバグを修正 | 126 |斎藤京子 | 127 |
160 |
--------------------------------------------------------------------------------