Git のブランチの成功モデル

Git を使用するには、ことが重要です。, ソフトウェアの共同開発環境の管理を維持することを含む、.

クレジット

この記事はオリジナルのポルトガル語版です。, 英語で, “成功した Git のブランチ モデル“, 著者によって正式に承認, ヴァンサン ・ デリセン. 人に感謝!

技術的な問題について, いくつかのキーワードをわざわざ英語で保管されています。. テキストの独創性を確保しよう, しかし、私は私たちの言語の理解を容易にするために調整した告白 (EN). 補正や翻訳の改善のための提案は歓迎.

導入

Este não é um Post ensinando a usar o Git. Se é isto que precisa, sugiro dar uma olhada no Manual do Git. Também não é nosso objetivo mostrar como se faz um versionamento de software, この場合, 参照してください。 バージョン管理の意味.

Aqui a proposta é gerenciar a colaboração da equipe no versionamento de software. Sabe quando você tem vários programadoresmexendoem um mesmo código-fonte? Isto é importante para agilizar o desenvolvimento, mas pode gerar imensa dor de cabeça (prejuízo e retrabalho) se não houver um controle. Para evitar que um desenvolvedor sobrescreva o trabalho de outro e garantir um desenvolvimento progressivo e organizado, minimizando os conflitos e gerenciando versões do software, é que utilizamos o Git e o modelo de そうしたら.

Modelo de branches

この記事で私は私のプロジェクトのいくつかのために使用開発モデルを提示します。 (仕事として特定) についての 1 年前, 非常に成功したとなっています。. それはずっと長い時間それについて書きたいです。, mas nunca encontrava um horário することができます, 今までに. プロジェクトの詳細を議論するつもりはないです。, のみの戦略について 管理 リリース.

Este modelo foca exclusivamente no Git 私たちのすべてのソース コードのバージョン管理のためのツールとして. (ところで, Git に興味があるなら, 私たちの会社 GitPrime 提供します, リアルタイムで, ソフトウェア エンジニア リングの最適化のためのいくつかの驚くべきデータ解析)

なぜ git?

Git の一元的なソース コード コントロール システムと比較しての賛否両論の徹底的な議論のため, 参照してください。Web. Há uma tremendaguerraem torno disso. 開発者として, 今日は他のすべての既存のツールに関連して Git を好む. Git は間違いない開発者が行うことについて考えて方法を変更します。 マージ 作成または、 支店. 古典的な世界から来た Cvs/Subversion, どこ マージ分岐 それは何かたまに行うのみと少し怖いですね (“矛盾に注意します。 マージ, 彼らはあなたを噛まないように!”).

Git でこれらのアクション [マージ分岐] 非常に単純で、私たちの仕事のルーチンの主要な部分の 1 つを表す, 信じてください. 例えば, で Csv/Subversion, 分岐 および マージ 後の章でのみ初めて覆われています。 (上級ユーザー向け), 中いずれか Git の本, これは章で見られる 3 (基本).

シンプルさと反復的な性質の結果として, 分岐 および マージ não são mais algo para se ter receio. 実際に, as ferramentas de controle de versão deveriam ajudar a fazerマージ 作成と 支店 何より.

Chega de conversa, 開発モデルに行こう. O modelo que irei apresentar aqui é essencialmente nada mais que um conjunto de procedimentos que cada membro da equipe deve seguir a fim de chegar a um processo de desenvolvimento de software gerenciado.

分散, しかし、中心

A configuração do repositório que utilizamos e que funciona muito bem com este modelo de 分岐 セントラル ・ リポジトリを構成します。. Note que este repositório é apenas “みなされる” 中央 (Git は、DVC ので [分散バージョン管理システム], IE, não existe nada tal como um repositório central a nível técnico). このリポジトリとして参考にさせていただきます 起源, この名前は Git のすべてのユーザーにはおなじみですので.

各開発者は、します。 引っ張る および 旅行 ため、 起源. しかし、関係を超えて プッシュ ・ プル 集中管理が [起源], 各開発者はまた拾うことができます。 [プル] サブのチームを形成する他のペアの変更. 例えば, これは新しい偉大な機能の 2 つ以上の開発者を扱う場合に有用することができます。, 以前の送信 [押す] 進行中の作業のため、 起源. 上の図で, アリスとボブのサブのチームがあります。, アリスとデビッド, クレアとデビッド.

技術的に, これは何を意味よりもアリスがボブという名前のリモート Git を定義, ボブのリポジトリを指す, その逆.

メインの枝

バック グラウンドで, この開発モデルはかなり周りの既存のモデルに触発します。. 中央のリポジトリは、2 つの分岐 [] 無限の生命の主要です:

  • マスター
  • 開発

支店マスター起源 Git のすべてのユーザーにはおなじみであるべき. 平行に 支店マスター, もう一つ 支店 と呼ばれる 開発.

考えてください。 起源/マスター メインのブランチとしてどこのソース コード 常に状態を反映します。 生産準備 [生産準備のため].

考えてください。 起源/開発 あると、 支店 ここでメインのソース コード 次のバージョンで配信される最新の変更の状態を常に反映してください。. いくつかというと “支店 統合の”. ここでより不吉が起こる構造であります。.

ソースコード、 ブランチを開発します。 到達点を安定してリリースされる準備ができています。 [リリース], すべての変更をマージする必要があります。 [マージ] 戻って、 支店マスター バージョン番号がマークと [リリース]. これを詳細に行う方法, 後述します。.

だから, 各時間の変更が組み込まれています [マージ] 戻って、 マスター, 新しいバージョンが生成されました。 [リリース], 定義では. 我々 はそれについてはかなり厳格に求める, だから, 理論的には, さらにスクリプトを使用できます。 フック Git があるたびに、実稼働サーバーにアプリケーションを自動的に送信を作成して、 コミットマスター.

補助枝

次に、 主です, マスター および 開発, 当社開発モデルを使用して、さまざまな チーム メンバー間の同時開発を支援するために, 何 1) 新機能の追跡が容易になります [機能], 2) 新しいバージョンの配信のための準備します。 [リリース] および 3) すぐに生産の欠陥を修正することができます。 [修正プログラム]. 異なり 主です, これら 寿命が短いは, 今最終的に削除されます。.

さまざまな種類 [ヘルパー] 私たちを使用することができます。, なる:

  • 機能の分岐
  • リリース ブランチ
  • 修正プログラム枝

これらの各 特定の目的があり、厳格なルールにリンクされています。, だから, 上昇を与えることができます。 支店 そしてそれを マージする必要があります。 [マージ] あなたの目標. 私たちはそれぞれを参照してください。 [] 一瞬のうちに.

技術的な観点から下, これら 見なされません “特別です”. それぞれの種類 支店 我々 はそれらを使用する方法によって分類されています. とにかく, ちょうどやすい 良い古い Git.

機能の分岐

[機能 = 機能]

– 分岐することができます。 [支店] 差出人:
開発
– マージする必要があります-場合 [マージ] もう一度、:
開発
– 名前付け規則 支店:
何か, 除く マスター, 開発, リリース-*, または 修正プログラム-*

機能の分岐 (または時々 と呼ばれる トピック ブランチ) 次以降のバージョンに新しい機能の開発に使用します。. 開発を開始する、 機能, この機能の埋め込み先のターゲット バージョンないかもしれない知られているこの時点で.

本質を 機能の分岐 彼は間、 機能 開発は、します。, 最終的には、埋め込まれますが、 [マージ] 戻って、 開発 (新たに追加するには 機能 次へ リリース) またはスロー (失敗した経験の場合).

機能の分岐 通常、リポジトリ内に存在だけ 開発, ではないです。 起源.

分岐機能の作成

$ git のチェック アウト -b myfeature を開発します。
# Switched to a new branch "myfeature"

開発終了機能を組み込む

機能 確定マージすることができます[マージ] と、 ブランチを開発します。 次にそれらを追加するには リリース.

$ git checkout を開発します。
# ブランチ '開発' に切り替え
$ git のマージ ---FF myfeature
# Ea1b82a を更新しています.05e9557
# (変更の概要)
# $ git のブランチ d myfeature
# 削除済みのブランチ myfeature (05e9557 だった).
$ git push 起源開発します。

フラグ –いいえ ff 差し込み印刷が発生します。 [マージ] 常に新しいオブジェクトを作成します。 コミット, マージを実行可能性がありますが、 早送り [FF]. こうと歴史の存在の情報が失われる、 機能ブランチ, すべてのグループ化 コミット 追加されている、 機能. 比較:

後者の場合 [上の図], Git の歴史から見られますの コミット 内に実装された、 機能; 手動ですべてのログ メッセージを読み取りする必要があります。. 逆に、 機能 ワンピース (IE, グループ コミット), それは最後の状況の本当の頭痛, 場合、それは簡単に行われてフラグ –いいえ ff 使用されています.

うん, これはのいくつかのより多くのオブジェクトを作成します。 コミット (空), しかし、利得はコストよりもはるかに大きい.

リリース ブランチ

[リリース = リリース/配信/バージョン]

– 分岐することができます。 [支店] 差出人:
開発
– マージする必要があります-場合 [マージ] もう一度、:
開発 および マスター
– 名前付け規則 支店:
リリース-*

リリース ブランチ 新しいプロダクション リリースの準備を支援します。 [プロダクション リリース]. 彼らを使用すると、最後の時間の i をドット. さらに, 彼らは、小さなバグの修正を許可します。 バグ 定義 メタ データ ため、 リリース (バージョン番号, ビルド作成日, など). この作業を行うには リリース ブランチ, 、 ブランチを開発します。 受信するクリーンな滞在します。 機能 次の大きな リリース [バージョン].

新しいを作成する重要な瞬間 リリース ブランチ 分岐 開発 ときに、 開発 既に (ほぼ) 新しいの目的の状態を反映してください。 リリース [バージョン]. すべての 機能 ための候補者、 リリース ビルドに組み込まれる必要があります。 [マージ] 、 開発 この瞬間に. 既に、 機能 直面しています。 リリース 将来は、次を期待すべき リリース [バージョン].

正確の冒頭には、 リリース ブランチ その次 リリース バージョン番号を取得します – 前ではなくに、. その時まで, 、 ブランチを開発します。 変更を反映、 “次のリリース” [次のバージョン], この場合は不明だが、 “次のバージョン” 最終的になります 0.3 または 1.0, まで、 リリース ブランチ 開始します。. この決定はの初めに、 リリース ブランチ バージョン管理にプロジェクトのルールによって実行されると [を参照してくださいことを勧めます “バージョン管理の意味“].

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

リリース ブランチ 作成された、 ブランチを開発します。. 例えば, たとえば、バージョン 1.1.5 現在の製品リリースは、我々 は偉大なを持って リリース 来る. 状態 開発 準備は、 “次のバージョン” [次のリリース] 我々 は、このバージョンになるだろうことを決めたと 1.2 (代わりに 1.1.6 または 2.0). だから, 我々 が拡大してきたし、を与える リリース ブランチ 新しいバージョン番号を反映する名前:

$ git のチェック アウト -(b) リリース-1.2 開発
# Switched to a new branch "release-1.2"
$ ./バンプ-バージョン.sh 1.2
# 正常に変更されたファイル, バージョンにぶつかった 1.2.
$ git のコミット --m "Bumped version number to 1.2"
# [リリース 1.2 74 d 9424] ぶつけられたバージョン番号 1.2
# 1 変更されたファイル, 1 挿入(+), 1 削除(-)

新しいを作成した後 支店 アクセス権, 我々 はバージョン番号. ここは, バンプ version.sh 新しいバージョンを反映するように作業コピーからいくつかのファイルを変更するシェル スクリプトです。. (これは、ことができます。, もちろんです, 手動で変更をします。 – ポイントは、いくつかのファイルを変更することです。) だから, は、 コミット 修正版数.

この新しい 支店 可能性がありますがしばらくの間、, まで、 リリース 間違いなくスローされます。. この時期, このバグの修正プログラムを適用ことができます。 支店 (ではなく、 ブランチを開発します。). 新しい、大規模な添加 機能 ここで固くお断りいたします. マージしなければなりません [マージ] で 開発 および, このように, 次を待つ大きな リリース.

リリース ブランチを確定

とき、 リリース ブランチ あなたがリアル バージョンになる準備ができています。, いくつかのアクションが行われる必要があります。. まずは, 、 リリース ブランチ マージされます。 マスター (各以来 コミットマスター 定義によって新しいバージョンです。, 覚えています。). そうしたら, これ コミットマスター 簡単な将来の参考のためにこのバージョン履歴をマークする必要があります。. 最終的に, 加えた、 リリース ブランチ マージする必要があります。 [マージ] もう一度 開発, 、 リリース 今後にはもこれらのバグ修正が含まれて.

Git の最初の 2 つの手順:

$ git checkout マスター
# 'マスター' の分岐に切り替え
$ git のマージ ---FF 発売-1.2
# 再帰によるマージ.
# (変更の概要)
$ git のタグ -1.2

リリース 完了とマークの今後の参考になって.

メモ: フラグ-s または u を使用するも あなたのタグに暗号で署名するには.

行われた変更を維持する、 リリース ブランチ, 我々 はそれらを置く必要がありますに戻る、 開発. Git で:

$ git checkout を開発します。
# ブランチ '開発' に切り替え
$ git のマージ ---FF 発売-1.2
# 再帰によるマージ.
# (変更の概要)

この手順は、マージの競合につながることができます。 (おそらく行く, 我々 は、バージョン番号を変更したら). そうすれば, 修正して、 コミット.

今, それは本当に別れた, 、 リリース ブランチ 削除することができます。, 私たちはもうそれを必要があるので:

$ git のブランチ -d リリース-1.2
# 削除済みのブランチ リリース 1.2 (ff452fe だった).

修正プログラム枝

– 分岐することができます。 [支店] 差出人:
マスター
– マージする必要があります-場合 [マージ] もう一度、:
開発 および マスター
– 名前付け規則 支店:
修正プログラム-*

修正プログラム枝 非常に類似している、 リリース ブランチ, 彼らはまた新しい生産リリースの準備するもの, 計画されていないが. 彼らは生産バージョンの不要な状態の直後に行動の必要性から生じる [使用中]. とき生産バージョンに致命的なエラー, すぐに解決する必要があります。, その後、 hotfix ブランチ 既存の生産バージョンを示すタグから派生することができます。 Master ブランチ.

本質は、チーム メンバーの作業 (で ブランチを開発します。) 続けることができます。, 他の人の生産の欠陥の迅速な修正準備中.

Hotfix ブランチを作成します。

修正プログラム枝 作成された、 Master ブランチ. 例えば, バージョンを想定してください。 1.2 実行している現在の生産のリリース バージョンは、重大なエラーに起因する問題を提示. 変更、 開発 まだ不安定なまま. 我々 は、分岐することができます、 hotfix ブランチ 問題を解決するために開始:

$ git のチェック アウト -(b) 修正プログラム-1.2.1 マスター
# Switched to a new branch "hotfix-1.2.1"
$ ./バンプ-バージョン.sh 1.2.1
# 正常に変更されたファイル, バージョンにぶつかった 1.2.1.
$ git のコミット --m "Bumped version number to 1.2.1"
# [修正プログラム 1.2.1 41e61bb] ぶつけられたバージョン番号 1.2.1
# 1 変更されたファイル, 1 挿入(+), 1 削除(-)

分岐した後、バージョン番号を変更することを忘れないでください。!

そうしたら, エラーを修正し、 コミット 1 つまたは複数の補正 コミット 区切られました。.

$ git のコミット -m "Fixed severe production problem"
# [修正プログラム 1.2.1 abbe5d6] 固定の厳しい生産問題
# 5 変更されたファイル, 32 挿入(+), 17 削除(-)

Hotfix ブランチを仕上げ

終了したら, 、 バグ修正 マージする必要があります、 マスター, それはまたに再度組み込まれる必要がありますが、 開発, いることを確認するために、 バグ修正 次のバージョンにも含まれる. これは、方法にかなり似て リリース ブランチ 確定します。.

まずは, 更新、 マスター タグを付けると、 リリース [夏を選択します。]:

$ git checkout マスター
# 'マスター' の分岐に切り替え
$ git のマージ ---FF の修正プログラム-1.2.1
# 再帰によるマージ.
# (変更の概要)
$ git のタグ -、 1.2.1

メモ: フラグ-s または u を使用するも あなたのタグに暗号で署名するには.

そうしたら, あります、 バグ修正開発 また:

$ git checkout を開発します。
# ブランチ '開発' に切り替え
$ git のマージ ---FF の修正プログラム-1.2.1
# 再帰によるマージ.
# (変更の概要)

ここでの規則の唯一の例外は、します。, ある場合、 リリース ブランチ 進行中の, 変更 修正プログラム これにマージする必要があります。 リリース ブランチ, 代わりに 開発. マージ、 バグ修正リリース ブランチ 原因となります、 バグ修正 併合は、 開発 また, とき、 リリース ブランチ 完了すると. (場合の作業 開発 すぐにする必要があります。 バグ修正 まで待つことができない、 リリース ブランチ 完成品は, 安全にマージすることができます、 バグ修正 ため deveolp あまりにも。)

最終的に, 削除、 支店 一時的です:

$ git のブランチ -d 修正プログラム-1.2.1
# 削除済みのブランチ修正プログラム 1.2.1 (abbe5d6 だった).

概要

何も本当に特別なこの分岐モデルではあるものの, 記事の冒頭の図は、私たちのプロジェクトで非常に有用することができます。. 彼女は理解しやすい精神的なモデルを示しています、チーム メンバーのプロセスの一般的な理解を開発することができます。 分岐 および リリース.

高品質の図の PDF 版は、オリジナルのポストのブログで提供しています: http://nvie.com/posts/a-successful-git-branching-model/ [または下記のダウンロード リンク]. 先に行くし、いつでもへのクイックリファレンスのための壁にそれを置く.

アイコン

Git 分岐モデル 20170825.pdf
3.89 メガバイト 13 ダウンロード

著者: ヴァンサン ・ デリセン
元のブログ: http://nvie.com/
ライセンス: CC - SA

総ヒット数: 495

メッセージを残してください

あなたのメール アドレスは公開されません. 必要なフィールドが付いています *