Git のさまざまなワークフローを深く理解する

この記事では、Git の紹介と、git の基礎知識、git をベースにしたさまざまなワークフローについて紹介します。

#この記事を通じて次のことを学ぶことができます:

git の起源
• git の基礎知識
• gitflow プロセスの基本的な方法
• git に基づく複数のワークフロー

#Git Flow について話す前に、まず他のことについて話しましょう

#バージョンとは何ですか?
• エディションは印刷版を指し、エディションは印刷された書籍を指します。エディションは、同じものの異なるさまざまな形式、状態、または内容を説明するために使用されるタイトルです。

  つまり、何かを区別する限り、バージョンという概念が含まれますが、ここで言うバージョンは、後で説明することも含めて、すべて意味のあるバージョンである必要があります。シャオミン 1 月 1 日 2 月 1 日から 1 月 31 日まで、計画書は毎日改訂されました。2 月 1 日、シャオミンの A 党は以前のバージョンの方が良かったと言いました。このとき、シャオミンにとって、以前のバージョンは何でしたか?おそらくそれがシャオ・ミンが党 A に送った最後の計画だったかもしれないし、あるいは党 A が大丈夫と言ったのが最後の計画だったかもしれないが、シャオ・ミンは計画が党 A に修正された具体的な日付を覚えていないかもしれない。
  
  

一般的なバージョン管理とは何ですか?
• copy ファイルを名前で区別する方法、このエディターの元に戻す/進む機能、svn、git などの専門ツールの使用はすべてバージョン管理のカテゴリに属します。バージョン管理が異なれば、用途も異なります。撤回すると、ファイルのコピーなど、この変更を簡単に元に戻すことができ、新しいファイルと古いファイルを同時に存在させて簡単に比較できますが、これらの方法は単純すぎて、中間プロセスは一時的なものです。変更履歴の参照として使用したり、完全なバージョンとして扱うには十分ではありません。このためには、集中バージョン管理システム SVN、CVS、分散バージョン管理システム BitKeeper、Git などの専門的なツールが必要です。

  
  

Git 開発の背景

• 人生の多くの素晴らしいものと同様、Git は大きな争いと革新の時代に生まれました。 Linux カーネルのオープンソース プロジェクトには多数の参加者がいます。 Linux カーネルのメンテナンス作業の大部分は、パッチの送信とアーカイブの保存という退屈な作業に費やされました (1991 年から 2002 年)。 2002 年までに、プロジェクト チーム全体がコードの管理と保守に独自の分散バージョン管理システムである BitKeeper を使用し始めました。

  2005 年までに、BitKeeper を開発した営利企業と Linux カーネル オープン ソース コミュニティとのパートナーシップは終了し、BitKeeper を無料で使用する Linux カーネル コミュニティの権利を取り戻しました。このため、Linux オープン ソース コミュニティ (特に Linux 作成者 Linus Torvalds) は、BitKeeper の使用から学んだ教訓に基づいて独自のバージョン システムを開発する必要がありました。彼らは新しいシステムに対していくつかの目標を設定しました:

  
  

  スピード

  • シンプルな設計
  • 非線形開発モデルの強力なサポート (並列開発の数千のブランチを可能にする)
  • 完全分散
  • Linux カーネルと同様の超大規模プロジェクトを効率的に管理する機能 (速度とデータ量) 2005 年に誕生して以来、Git は成長を続け、初期に設定された目標を維持しながら非常に使いやすくなりました。高速で大規模なプロジェクトの管理に最適で、驚くべき非線形ブランチ管理システムを備えています (Git ブランチを参照)。

Linux は、1991 年にオープン ソース プロジェクトである Linux システムを開発し、パッチ付きのソース ファイルを電子メールで送信して作成および開発する方法を採用していました。 Linux 自身がこれらを手動でマージしました。
2002 年、BitKeeper は Linux コミュニティと合意に達し、Linux コミュニティが BitKeeper を無料で試用できるようになりました。この合意は、BitKeeper 自体を保護することに重点を置いています。
2005 年、BitKeeper は協定の内容を破棄したとして Linux コミュニティに不満を抱きました (率直に言うと、BitKeeper はクラック版などを作成しようとして BitKeeper を逆コンパイルしていました)。
2005 年と同じように、Linux は最初のバージョンの Git の開発に 2 週間を費やし、1 か月以内に Git を使用して Linux コードを管理しました;
Git の基本知識

ワークスペース、一時記憶域 (インデックス)、リポジトリ (リポジトリ)

# 创建并进入 testGitFlow 目录
# 此时 testGitFlow 就是我们的工作区(Workspace)，也就是工作目录

$ mkdir testGitFlow && cd testGitFlow

# 初始化 git 仓库
# 此时目录中增加了 .git 目录，.git 目录就是 git 仓库，不属于工作区

$ git init

# 新增两个文件
$ echo 111 > a.txt
$ echo 222 > b.txt

# 添加两个文件到暂存区/索引(Index)
$ git add .

# 把索引中的两个文件添加到版本库(Repository)
$ git commit -m 'init'

上記に関連するいくつかの概念:

ワークスペース
:簡単に理解すると、プロジェクト DirectoryIndex
: 簡単に理解すると、送信するコンテンツが保存される領域ですRepository
: バージョン リポジトリコミット、ツリー、BLOB オブジェクト

# 通过 git log 查看版本
$ git log

>
commit 2b304a56998989dbcfd77f370f4b43fcad9e5872 (HEAD -> master)
Author: huihuipan <huihuipan163@163.com>
Date:   Mon Feb 27 17:56:53 2023 +0800

    init


# 通过 git cat-file 查看 commit 信息

# 查看 commit 类型
$ git cat-file -t 2b304a
> commit

# 查看 commit 内容
$ git cat-file -p 10d717

>
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author huihuipan <huihuipan163@163.com> 1677491813 +0800
committer huihuipan <huihuipan163@163.com> 1677491813 +0800

init

# 可以发现有 tree, author, committer 等信息
# 继续查看 tree 内容
$ git cat-file -t 4caaa1
> tree

$ git cat-file -p 4caaa1
>
100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

# 可以发现有 blob 信息
# 继续查看 blob 内容
$ git cat-file -t 58c9bd 
> blob

$ git cat-file -p 58c9bd 
> 111

# 可以看到里面存储的是 a.txt 的内容

上記に関連するいくつかの概念:

commit
: コミットは送信されたバージョンを記録します tree
: ツリーは送信されたバージョンを記録します異なるバージョンでのディレクトリ構造とファイル名blob
: BLOB レコード ファイルの内容##現時点での git プロジェクトの構造は次のとおりです##blob

: #

ファイルを変更してコミットを送信するとどうなりますか?

1. まず、a.txt の内容を 111 から 333 に変更します。この時点では git ウェアハウスは変更されていませんが、ワークスペースとインデックスが一致しません;
2. git add コマンドを実行します
   ##git ウェアハウスは、新しい a.txt コンテンツ (333) に基づいて新しい BLOB ノードを作成し、a.txt を記録します。 txt の内容
   1. インデックスが古い BLOB から変更されます。BLOB は新しい BLOB を指します。
git commit コマンドを実行します。
3. 以下に基づいてツリー オブジェクトを生成します。インデックスのステータス
   1. 新しく生成されたツリー オブジェクトと以前の A コミット オブジェクトに従って、新しいコミット オブジェクトを生成します
   2. ブランチ ポインタを古いコミット オブジェクトから新しいコミット オブジェクトに移動します

HEAD、Branch、Tag

Branch: は、ポインタを指します新しいコミットが送信されるたびに、現在のブランチは最新のコミットを指します;

HEAD: ブランチへのポインタ。チェックアウトが非-branch を実行すると、It is in thedetached head pointer state というプロンプトが表示され、いくつかの実験的なアクションを実行できます。;

Tag:コミットへのポインタ。ラベルとして使用され、通常は修正バージョンを記録するために使用され、指定されたコミットのエイリアスとしても理解できます。

上記のことから、バージョン管理の粒度が次のとおりであることがわかります。 git のデータがファイルレベルに到達し、blob を比較することで diff が得られるため、開発思考にもつながります プログラムを設計する際の基礎が比較的細かい粒度であると、その後の開発や拡張がより柔軟になりますコミットの操作も非常に柔軟なので、気をつけないと事故が起きる可能性があります。

チェックアウト、マージ、リベース、フェッチ、プル

チェックアウト チェックアウト: 指定されたブランチまたはコミットに HEAD をチェックアウトする、または指定されたバージョンの指定されたファイルの内容をチェックアウトします。チェックアウトは git であまりにも多くの機能を実行するため、すべてのスイッチング ブランチには排他的なコマンド switch があります。

#マージ マージ #:

##リベース リベース

:

リベースするとバージョン履歴が変更されます。リベース前の内容とリベース後の内容が一致していても、バージョンは同じバージョンではなくなります

fetch

: リモート ライブラリなどの別のリポジトリからオブジェクトと参照をダウンロードします。

#pull: git pull = fetch merge

Git のいくつかのワークフローに基づくGit Flow

はじめに

## の

Vincent Driessen より#2010 で書かれた記事

「成功した Git ブランチング モデル」

主なブランチは 2 つあります
# # ブランチはバージョンのライフサイクル全体を通じて実行されます。つまり、長期ブランチ:

master ブランチ: リリースに使用されます

develop ブランチ: 開発に使用されます masterブランチとdevelopブランチの関係は上記の通りですが、点線は直接関係はなくrelease/hotfixブランチ

supportブランチ

を介して関係のある2つのブランチを示しています。

• feature ブランチ: 要件開発に使用されます

要件を開発するときは、develop ブランチから feature ブランチをプルします。feature ブランチが開発された後、 (開発セルフテストでは問題ありません), 開発ブランチにマージし直し、マージ後のブランチを削除し、後でバグが発生した場合は開発ブランチで修正します。

• release ブランチ: release に使用されます

develop ブランチが比較的安定した状態にある場合は、開発ブランチ リリースの準備が整ったリリースブランチ リリースブランチは機能開発は行わず、バグ修正だけを行います 問題がなければマスターブランチにマージされてリリースされます 同時にマージバックされます開発ブランチに追加され、その後リリース ブランチが削除されます。

• hotfix ブランチ: 実稼働環境の問題を修正するために使用されます



hotfix ブランチは、実稼働環境で緊急に修正する必要があるバグを修正するために使用されます。本番環境でバグが発生した場合 その時は、master ブランチから hotfix ブランチを取り出し、修復後にリリース用に master ブランチにマージし直し、develop ブランチにマージしてから削除します。

最後に完全な gitflow を確認します



追加

2020年 Vincent Driessen追加反省ノート、大まかに言うとGit Flowこのモデルは継続的配信ソフトウェアの下では複雑に見えますが、 Github Flowの使用を検討できます。 Git Flow をプロジェクトに押し込むのではなく。

フォロー中

Git FlowAdam Ruka forGit Flow の技術的な詳細が最適化されており、 # # と比較して One Flow

Github Flow



# が提案されています

#Git Flow、Github Flow トランク ブランチは 1 つだけあり、PR プロセスは Github プラットフォームを通じて追加されます。 ある機能を開発する際には、master ブランチからフィーチャーブランチを引き出し、機能完成後に PR を提出し、関係者にレビューしてもらい、レビュー期間内であれば、機能ブランチが存在しないことが確認されるまで提出することができます。リリース用ブランチGitLab Flow

GitLab Flow # を使用します。 ##master ブランチを開発ブランチとして、 master ブランチに基づいて、ブランチ production# をリリースします##GitLab Flow
次のブランチ定義を追加します: Environment ブランチ
: を使用します。 release ブランチ## 異なる環境で異なるバージョンをリリースする必要がある場合 #: プロジェクトが異なるバージョンをリリースする必要がある場合に使用されます。リリース ブランチを宣言した後、このブランチは重大なバグ修正アップデートのみをマージします。
継続的リリース

gitlab-flow では、開発には master ブランチを使用し、リリースには master ブランチに基づいて運用ブランチを構築することを推奨しています。環境ブランチの概念。さまざまな環境に応じてレイヤーごとにマージし、最終的にリリース

バージョン リリース

の製品リリース ブランチにまとめます。プロジェクトが異なるバージョンをリリースする必要がある場合は、gitlab-flow バージョン リリース モードの方が適している可能性があり、継続的リリース モードでは、異なるバージョンが異なるリリース ブランチでリリースされます。

Aone Flow

Aone-flow は master ブランチをベースにしており、master ブランチ以外は一時的なブランチです。環境ブランチは、master ブランチを基に引き出されます。環境ブランチ間には関連性がなく、独立して開発されます。環境ブランチは直接変更することはできませんが、異なる機能ブランチをマージすることによって結合されます。フィーチャー ブランチは、リリース ブランチにマージされるまで削除されません。利点の 1 つは、操作の粒度が高く、制御しやすいことですが、欠点は、環境ブランチの内容が同じであっても、バージョン履歴が不一致になる可能性があることです。

バージョン管理の選び方

gitflow から始まるいくつかのフローが上で紹介されていますが、gitflow を使用すると、自由度の高い git をガイド付きで使用できます。 flow は、gitflow の複雑さに応じて、最小限のバージョンの flow を提案します。

gitlab-flow は、gitflow と github-flow の過度に複雑または単純なメソッドに対する独自の妥協ソリューションも提案し、2 つの配信方法 (継続的配信) も提供します。 、バージョン配信) ソリューション;

最後に、より自由な操作粒度を備えたソリューションである AoneFlow も紹介されます。
実際には、万能のソリューションはありません。チームやプロジェクトごとに特殊な状況があり、状況に応じてフローも変化し、適切なソリューションが最適です。


最後に



結論として、万能薬は存在しないということを常に念頭に置いてください。自分自身の状況を考慮してください。嫌いにならないでください。自分で決めてください。

引用ヴィンセント・ドリエセン: 「最後に、特効薬はないということを常に覚えておいてください。自分の背景を考えてください。嫌いにならないでください。自分で決めてください。」

詳細については、プログラミング関連の知識については、プログラミング ビデオ をご覧ください。 ！

以上がGit のさまざまなワークフローを深く理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。