最新のソース管理システムは、ソースコードでブランチを簡単に作成できる強力なツールを提供しています。しかし、最終的にはこれらのブランチを再びマージする必要があり、多くのチームはブランチの複雑な絡まりに対処するために過剰な時間を費やしています。ブランチを効果的に使用できるパターンがいくつかあり、複数の開発者の作業を統合し、本番リリースへのパスを整理することに焦点を当てています。全体的なテーマは、ブランチを頻繁に統合し、最小限の労力で本番環境にデプロイできる健全なメインラインに注力することです。

Ship/Show/Askは、プルリクエストの機能と変更を継続的に出荷する機能を組み合わせたブランチ戦略です。変更は、Ship（レビューなしでメインラインにマージ）、Show（レビューのためにプルリクエストを開くが、すぐにメインラインにマージ）、またはAsk（マージ前にディスカッションのためにプルリクエストを開く）のいずれかに分類されます。

「抽象化による分岐」は、ソフトウェアシステムへの大規模な変更を段階的に行うための手法であり、変更が進行中でもシステムを定期的にリリースできます。

継続的デリバリーとは、いつでも本番環境にリリースできるようにソフトウェアを構築するソフトウェア開発手法です。

継続的デリバリーを行っている場合

• ソフトウェアはそのライフサイクル全体でデプロイ可能です
• チームは、新しい機能に取り組むよりも、ソフトウェアをデプロイ可能な状態に保つことを優先します
• 誰かが変更を加えるたびに、誰でもシステムの本番環境への準備状況について迅速かつ自動化されたフィードバックを得ることができます
• オンデマンドで、任意のバージョンのソフトウェアを任意の環境にプッシュボタンでデプロイできます

回帰バグは、しばらく前から存在していたソフトウェアの機能に新たに出現したバグです。それらを追跡する場合、通常、ソフトウェアのどの変更がそれらの出現を引き起こしたかを把握することが重要です。その変更を調べることで、バグがどこにあるのか、どのように修正するのかについて貴重な手がかりが得られます。この調査形式にはよく知られた用語はありませんが、私はそれを差分デバッグと呼んでいます。

フィーチャーブランチとは、開発者が新しい機能の作業を開始するときにブランチを開くソースコードの分岐パターンです。彼女は、このブランチで機能に関するすべての作業を行い、機能が完了したら変更をチームの他のメンバーと統合します。

ソフトウェア開発チームは、できるだけ頻繁に作業を統合すると、作業がはるかに楽になることに気付きます。また、本番環境に頻繁にリリースすることも重要です。しかし、チームは未完成の機能をユーザーに公開したくありません。この緊張に対処するための便利なテクニックは、すべてのバックエンドコードを構築し、統合しますが、ユーザーインターフェースは構築しません。機能は統合してテストできますが、UIは、キーストーンのように機能を完成させるために追加され、ユーザーに公開されるまで、最後まで保留されます。

最近、Mercurialでいくつかのコミットをスカッシュして少し苦労したので、他の誰かがこれをしようとしている場合に備えて、投稿する価値があると思いました。これが最良の手順かどうかはわかりませんが、私にはうまく機能しているようでした。

常にバージョン管理を使用している人として、私はそれがコンピューターの使用のより多くの分野に成長できるものだと考えています。ソフトウェア開発者以外では、バージョン管理を使用するコンピューターユーザーはほとんどいません。しかし、ソフトウェア開発者が知っているように、バージョン管理は共同作業のための優れたメカニズムであり、複数の人が単一のソフトウェアシステムで共同作業を行うことができます。バージョン管理がより広く使用されることの利点は何でしょうか？

私は継続的インテグレーションの大ファンです。これは、ほとんどの開発チームに大きな違いをもたらすことができる比較的簡単なプラクティスです。ただし、ほとんどのプラクティスと同様に、欠陥^H^H^H^H^H改善の余地があります。この主題に関する近日発売予定の標準的な書籍の著者であるPaul Duvallは、最近これらの1つを指摘しました。コミットビルドが中断した場合、チーム全体が影響を受け、修正されるまで潜在的に速度が低下します。

最近、AppleはTime Machineを発表しました。これは、過去に戻ってファイルのすべての変更を確認し、削除されたファイルを見つける機能です。一部の熱心なギークにとって、これは新しい機能ではありません。他の人と同様に、私は作業ディレクトリ全体をバージョン管理（元々はCVS、現在はSubversion）下に置き、作業内容のすべての変更を簡単に確認できるようにしました。これは非常に便利な機能であるため、MoreVersionControlを使用するとどうなるのか疑問に思っていましたが、おそらくTime Machineはその方向への一歩です。

継続的インテグレーションの支持者が持っている一般的な前提の1つは、ビルドが再現可能である必要があるということです。これは、いつでも、作業中のシステムの古いバージョンを取得し、当時と同じ方法でソースからビルドできる必要があることを意味します。

同僚や私がフィーチャーブランチについて話しているのを聞いた人は、私たちがそのパターンの熱心なファンではないことを知っています。私たちの反対意見の重要な部分は、分岐は簡単だが、マージは難しいという観察です。時々耳にする議論の1つは、最新のバージョン管理ツールはマージを suffisamment 容易にするため、フィーチャーブランチは価値があるということです。

ほとんどのバージョン管理システムは、アーティファクトのバージョン間の変更（Unixでそれらを生成できるコマンドから差分と呼ばれることが多い）の使用と理解に依存しています。優れた差分（およびマージ）アルゴリズムは、テキストファイルとバイナリファイルに使用できます。これらの差分の問題は、かなりダムであることです。彼らは2つのアーティファクトバージョンを見て、一方から他方へ行く簡単な方法を生成するだけです。

Subversionは、オープンソースのバージョン管理システムであり、本質的にはCVSの後継です。 CVSの最大の問題を修正し、アトミックコミットやファイルとディレクトリの名前変更のサポートなどを導入しています。私はそれを数年間使用しており、非常に堅実であることがわかりました。

バージョン管理ツールについて説明したとき、それは非科学的な意見の寄せ集めだと言いました。私はそれをしているときに、調査を行うことで分析に偽りのある魅力的な数字を追加できることに気付きました。 Googleのスプレッドシートは、調査を実施するための仕組みを非常にシンプルにするため、抵抗できませんでした。

ソフトウェア開発者とツールについて話し合う時間があれば、私が耳にする最大のトピックの1つはバージョン管理ツールです。バージョン管理ツールを使用する段階に達すると、そして有能な開発者であれば、それらはあなたの人生の大きな部分を占めるようになります。バージョンツールは、プロジェクトの履歴を維持するだけでなく、チームが共同作業するための基盤でもあります。そのため、バージョン管理ツールが貧弱であるという苦情を頻繁に耳にするのは当然のことです。最近のThoughtworksテクノロジーレーダーでは、企業が使用を評価すべきバージョン管理ツールとして2つの項目を挙げました。Subversionと分散バージョン管理システム（DVCS）です。ここでは、バージョン管理ツールについて社内で何度も行った議論を要約して、それについて詳しく説明したいと思います。