web-dev-qa-db-ja.com

異なるタイプのブランチがありますか？

Gitには機能ブランチと呼ばれるものがあります。たとえば、ゲームを作成していて、Power-up機能を追加する必要があるとします。

コミット名with機能ブランチの表示方法：
支店名：Adding Power-up.
最初のコミット名：Added prefab.
2番目のコミット名：Implemented graphics.
3番目のコミット名：Added collision detection.
4番目のコミット名：Added effect on player on collision.

コミット名なしfeaturesブランチの表示方法：
最初のコミット名：Adding power-up: added prefab.
2番目のコミット名：Adding power-up: added graphics.
3番目のコミット名：Adding power-up: added collision detection.
4番目のコミット名：Adding power-up: added effect on player on collision.

コミットがファイルの場合、Power-upというディレクトリを作成し、そのフォルダー内にprefab、graphics、collision detection、effect on player on collisionを置きます。

Gitブランチのもう1つの使用法は、開発バージョンを製品バージョンから分離することです。

  1. 私の直感が正しければ、git機能ブランチはExplorerのフォルダーに匹敵し、git masterおよびdevブランチは環境に匹敵しますか？
  2. 別の「タイプ」のブランチを見逃したことがありますか？
  3. 異なるタイプのブランチがある場合、gitはいくつかの構造化を追加する必要がありますか？ （git featureBranch <newBranchName>またはgit environmentBranch <newBranchName>と呼ばれるコマンドのように）

参照：
- https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

gitnaminggitflow
2
Ambroise Rabier

すべての哲学を理解するわけではありませんが、gitのブランチは、コードベースの代替現実であり、他のすべてのコード変更とは別に新しい機能または欠陥修正が開発されたパラレルユニバースです。

Gitのブランチは、ファイルを含む「フォルダ」と見なされるべきではありません。これは、コードベースに対する独立した孤立した変更を記録するタイムラインと見なす必要があります。

Masterブランチは、他のすべてのベースとなる共通のタイムラインです。他のすべてのパラレルユニバース（ブランチ）はマスターから分裂し、独自の方法で進化します（他のブランチにコミットします）。新機能またはバグ修正を他のタイムライン（他のブランチ）に含める準備ができると、これらの代替現実はgit mergeの形式で衝突します。

一部の支店は他の支店よりも長生きします。欠陥の修正は数日しか行われない可能性があります。新機能のブランチは数週間存在する可能性があります。 「dev」ブランチは、プロジェクトの開始時にマスターから切り離される可能性があり、アプリケーションが廃止されるまで存続します。

ブランチは、使用目的と寿命に基づいて互いに区別できます。これにより、「ブランチタイプ」に似たものが得られます。

  • マスター：1日目に作成されます。リポジトリが削除されるまで存続します。通常、他のすべてのブランチが最終的に基づいている標準的なソースです。
  • 統合ブランチ：多くの人の作業がここに統合されているため、マスターにマージする前に適切にテストできます。 「dev」や「development」などの名前を付けることも、アプリケーション環境（「qa」や「uat」など）にちなんで名前を付けることもできます。
  • 欠陥の修正：本番環境の問題を修正するための短期間のブランチ
  • 新機能：システムに新しい機能を追加するための、通常はかなり短命のブランチ
8
Greg Burghardt