プログラミングを真剣に取り組むなら、必ず「バージョン管理システム」を使用します。

現在、最も人気のある「バージョン管理システム」は Git です。

類似のソフトウェアと比較して、Gitには多くの利点があります。最も重要な点の一つは、ブランチの作成とバージョンのマージが容易なことです。従来のバージョン管理ソフトウェアの中には、ブランチを作成する際に既存のコードの物理的なコピーを作成するものもありますが、Gitは現在のバージョンへのポインタ（「スナップショット」とも呼ばれます）のみを生成するため、非常に迅速かつ簡単に使用できます。

しかし、便利すぎると副作用も生じます。注意を怠ると、あちこちにブランチが散らばった、広大でオープンなリポジトリができあがり、開発のメインラインが分からなくなってしまう可能性があります。

Vincent Driessen 氏が提案したブランチ管理戦略は、学ぶ価値が非常に高いと思います。この戦略は、リポジトリの進化をシンプルに保ち、メインブランチを明確にし、各ブランチがそれぞれの機能を体系的に実行できるようにします。理論的には、これらの戦略はすべてのバージョン管理システムに適用できます。Git はあくまで例として挙げているだけです。Git に馴染みのない方は、例のセクションを読み飛ばしてください。

I. 本支店長

まず、コードベースにはメインブランチが1つだけ必要です。ユーザーにリリースされるすべての公式バージョンは、このメインブランチで公開されます。

Gitのマスターブランチのデフォルトの名前はMasterです。これは自動的に作成され、リポジトリが初期化された後は、デフォルトでマスターブランチ上で開発が行われます。

II. 開発部門

メインブランチはメジャーバージョンの配布にのみ使用され、日常的な開発は別のブランチで行われます。開発に使用するブランチを「Develop」と呼びます。

このブランチは、最新のナイトリーバージョンのコードを生成するために使用できます。公式に公開したい場合は、DevelopブランチをMasterブランチにマージしてください。

開発ブランチを作成するための Git コマンド:

 git チェックアウト -b マスターを開発する

Develop ブランチを Master ブランチに公開するコマンドは次のとおりです。

 # マスターブランチに切り替える
git チェックアウト マスター
 
 # 開発ブランチをマージする
git マージ --no-ff 開発

前のコマンドの `--no-ff` パラメータの意味を簡単に説明します。デフォルトでは、Git は「fast-farward merge」を実行し、Master ブランチを Develop ブランチに直接ポイントします。

`--no-ff` パラメータを使用すると、通常のマージが実行され、Master ブランチに新しいノードが作成されます。バージョンの変化を明確にするために、このアプローチをお勧めします。マージの詳細については、Benjamin Sandofsky の「Understanding the Git Workflow」を参照してください。

III. 臨時支店

先ほど、リポジトリの2つのメインブランチであるMasterとDevelopについて説明しました。前者は公式リリース用に、後者は日常的な開発用に使用されます。実際、永続的なデプロイメントにはこの2つのブランチだけで十分であり、他のブランチは必要ありません。

ただし、永続的なブランチに加えて、特定の目的を目的としたバージョン開発に使用される一時的なブランチも存在します。一時的なブランチには主に3つの種類があります。

• 機能ブランチ
• プレリリースブランチ
• 「fixbug」ブランチ

これら 3 つのブランチはすべて一時的なものであり、使用後は削除する必要があります。そのため、コードベースの永続的なブランチは常に Master と Develop のみになります。

IV. 機能分野

次に、これら 3 つの「一時ブランチ」を 1 つずつ見ていきましょう。

1つ目のタイプは機能ブランチです。これは、特定の機能を開発するためにDevelopブランチから分岐するブランチです。開発が完了すると、Developブランチにマージされます。

機能ブランチは feature-* の形式で名前を付けることができます。

機能ブランチを作成します。

 git チェックアウト -b 機能-x 開発

開発が完了したら、feature ブランチを開発ブランチにマージします。

 git チェックアウト 開発
git マージ --no-ff 機能-x

機能ブランチを削除します。

 git ブランチ -d 機能-x

V. プレリリースブランチ

2 番目のタイプはプレリリース ブランチです。これは、公式バージョンをリリースする前 (つまり、マスター ブランチにマージする前) にテストする必要がある可能性のあるプレリリース バージョンを指します。

プレリリースブランチはDevelopブランチから分岐します。プレリリースが完了したら、DevelopブランチとMasterブランチの両方にマージする必要があります。プレリリースブランチの名前はrelease-*の形式で付けることができます。

プレリリース ブランチを作成します。

 git チェックアウト -b リリース 1.2 開発

問題がないことを確認したら、マスター ブランチにマージします。

 git チェックアウト マスター
git マージ --no-ff リリース 1.2
 # マージによって生成された新しいノードにラベルを付けます。
 git タグ -a 1.2 
 

次にそれを develop ブランチにマージします。

 git チェックアウト 開発
git マージ --no-ff リリース 1.2

最後に、プレリリース ブランチを削除します。

 git ブランチ -d リリース-1.2

VI. バグ修正ブランチ

最後のタイプはバグ修正ブランチです。ソフトウェアが正式にリリースされた後、バグは避けられません。このとき、バグを修正するためのブランチを作成する必要があります。

バグ修正ブランチはMasterブランチから分岐します。バグ修正が完了すると、MasterブランチとDevelopブランチの両方にマージされます。このブランチ名はfixbug-*の形式で付けることができます。

バグ修正ブランチを作成します。

 git チェックアウト -b fixbug-0.1 マスター

パッチ適用後、マスター ブランチにマージします。

 git チェックアウト マスター
git マージ --no-ff 修正バグ 0.1
 git タグ -a 0.1.1

次にそれを develop ブランチにマージします。

 git チェックアウト 開発
git マージ --no-ff 修正バグ 0.1

最後に、「バグ修正」ブランチを削除します。

 git ブランチ -d fixbug-0.1

オリジナルリンク: http://www.ruanyifeng.com/blog/2012/07/git.html