model」(日本語訳)をベースにまとめてみました。Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。Gitを利用していくにつれて色々と疑問も出てきます。局所的なワークフローについては、様々なリソースによって理解することができます。行うために、大局的・継続的なワークフローをどのように採ればよいのか、特にGitの柔軟性を活かすにはブランチをどのように使えばよいのか、という疑問です。modelGitでの開発・運用の疑問に答えてくれる一つのモデルがあります。Gitでの開発・運用方法がブランチグラフと実際のシナリオ、コマンドとともに詳しく解説されています。要約すると、タグ付け専用のブランチ(master)と開発用のブランチ(develop)を用意し、通常の開発やリリースの準備はdevelopブランチをベースに、リリースやホットフィックスはmasterブランチをベースに行うというものです。大規模な運用でなければ、このモデルでほとんどのケースに対応できるかと思います。このモデルでの運用をサポートしてくれる「git-flow」というGitプラグインもあります。model」を当てはめて考えた場合、細かい部分で次のような新たな疑問も湧いてきました。model」のブランチグラフと開発・運用シナリオを掘り下げてまとめてみました。model」を理解していることが前提の内容となります。model」のブランチグラフをベースに、いくつかのブランチ群とシナリオを追加、一部の説明とレイアウトを調整したものです。破線の矢印を含む薄くなっている部分が追加部分になります。詳細は以降の章で解説します。fast-forward)フラグをデフォルトにするためのいくつかのアイデアを紹介します。model」ではブランチ間のマージに「--no-ff」フラグを指定することが推奨されています。これはファストフォワード(Fast-forward)マージを防ぎ、意図的にマージコミットを作成するためです。Fast-forwardマージではHEADの移動のみが行われるため、ブランチをマージした履歴が残りません。意図的にマージコミットを作成することで、ブランチをマージした履歴を残し、後々になっても容易に履歴の追跡ができるようにしておきます。マージオプション(mergeoptions)を指定する方法Gitの設定で、「branch.ブランチ名.mergeoptions」に「"--no-ff"」を設定します。"--no-ff"指定したブランチへのマージでは、「"--no-ff"」がデフォルトのオプションとなり、Fast-forwardマージが行われなくります。この設定はブランチごとに行う必要があります。プル(pull)によってマージが行われる状況においてもFast-forwardマージが行われなくなるため、複数人で開発を行う場合などには注意が必要です(この記事のコメント欄を参照)。--no-ff」のエイリアスを追加します。nffmerge」コマンドを使えるようになります。既存のコマンド(「merge」等)をエイリアスで上書きすることはできません。「git-merge(1)」バグフィックス用のブランチ(fix)ホットフィックス以外のバグフィックスは、必要に応じて、developブランチからバグフィックス用のブランチ(fix)を作成します。developバグの修正後はdevelopブランチへマージし、バグフィックス用のブランチを削除します。fix/2ただし、リリース用のブランチ(release)が存在する場合は、リリース用のブランチ(release)からバグフィックス用のブランチ(fix)を作成します。release/2.0.0バグの修正後はリリース用のブランチ(release)へマージします。fix/3ホットフィックスに関しても、リリース用のブランチ(release)が存在する場合、ホットフィックス用のブランチ(hotfix)はバグの修正後にリリース用のブランチ(release)にのみマージします。実用Gitサポート用のブランチ(support)過去のリリースに対するホットフィックス既にいくつかのリリースを行った後に、過去のリリースに対してホットフィックスを行わなければいけない状況になったとします。その場合は、該当するタグからサポート用のブランチ(support)を作成します。サポート用のブランチ(support)からホットフィックス用のブランチ(hotfix)を作成し、そこでバグを修正します。hotfix/1.1.1バグの修正後はサポート用のブランチ(support)へマージし、タグを付けます。hotfix/1.1.1混乱を避けるために、原則として、サポート用のブランチ(support)や、そこから派生したホットフィックス用のブランチ(hotfix)を他のブランチへマージすることは避けます。過去のリリースが複数ある場合は、該当するタグから、それぞれ新たにサポート用のブランチ(support)とホットフィックス用のブランチ(hotfix)を作成します。バグの修正後は、派生元のサポート用のブランチへそれぞれマージし、タグを付けます。サポート用のブランチ(support)は、サポートを終了するまでの間、過去のリリースにおけるmasterブランチとして扱います。最新のリリースに対するホットフィックス最新のリリースに対してもホットフィックスを行う必要がありますが、この場合は通常通り、最新のタグからホットフィックス用のブランチ(hotfix)を作成します。チェリーピック(cherry-pick)を使用する場合は、この後にcherry-pickを行う(後述)バグの修正後は、developブランチとmasterブランチへマージし、タグを付けます(リリース用のブランチがある場合は、リリース用のブランチへマージするのみ)。hotfix/2.0.1複数のリリースに対するホットフィックス複数のリリースでホットフィックスを行う場合には、cherry-pickを使用すると修正が多少容易になります。support」)もあるようです。するかということがあります。開発用・公開用などの用途により微妙に異なる内容を管理したい場合や、特別な機能を持たせたバージョンなどの部分的に異なる内容を管理したい場合です。異なる内容が些細な場合には専用のブランチを作成し、リベースを行いながら専用のブランチを維持していく方法が考えられます。異なる内容が大きい場合には、サポート用ブランチと同様の方法で専用のブランチを作成し、マージを行いながら専用のブランチを維持していく方法が考えられます。どちらの方法も専用のブランチは継続的に維持していく必要があります。model」の「維持するブランチを最小・最短に抑えるモデル」を考えると、派生元・マージ先ブランチの決め方を含め、リポジトリとブランチの管理が煩雑になりそうです。そこで、実際には状況に応じた方法を柔軟に選択する必要があるかと思いますが、とりあえずは以下のような方針で運用を行ってみようかと考えています。model」におけるmasterブランチとdevelopブランチの役割を入れ替える方法があります。masterブランチを開発用のブランチ(develop)として使います。公開用のブランチは専用のブランチ(production等)を作り、そこでタグ付けを行います。個人規模での開発や、公開よりも継続的な開発に重点を置く場合には、この方法のほうがスムーズな運用ができるかもしれません。GistまとめGitはSubversion等とは異なるブランチ、タグ、チェリーピックの概念、分散リポジトリやリベース、多様なマージ方法を持っており、標準で便利な機能が多く用意されています。柔軟に対応できますが、それゆえにどの機能をどう使うかは利用者次第です。ベースとして一つの指針となるはずです。最後に、基本的な運用方法を含めたGitの使い方を理解したい人には「入門Git」、Gitの詳しい概念と仕組みを理解したい人には「実用Git」がおすすめです。「実用Git」は「入門Git」と合わせて読むと理解しやすいかと思います。「実用Git」は、基本的な運用方法についてはあまり書かれていませんが、一つ一つの概念、仕組みが丁寧に解説されています。その他のリソースでは曖昧にしか理解できない部分でも、「実用Git」を読むことですっきりします。GitとSubversionリポジトリの併用」がかなり役立つ内容になっています。05:20こんにちは。“–no-ff”で常にファストフォワードではないマージを行うことについて一つ。マージコミットが作られます。(変更を一つずつ再適用する)」になります。