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

この記事では、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 は大きな争いと革新の時代に生まれました。 Linux カーネルのオープンソースプロジェクトには多数の参加者がいます。 Linux カーネルのメンテナンス作業の大部分は、パッチの送信とアーカイブの保存という退屈な作業に費やされました (1991 年から 2002 年)。 2002 年までに、プロジェクトチーム全体がコードの管理と保守に独自の分散バージョン管理システムである BitKeeper を使用し始めました。
2005 年までに、BitKeeper を開発した営利企業と Linux カーネルオープンソースコミュニティとのパートナーシップは終了し、BitKeeper を無料で使用する Linux カーネルコミュニティの権利を取り戻しました。このため、Linux オープンソースコミュニティ (特に Linux 作成者 Linus Torvalds) は、BitKeeper の使用から学んだ教訓に基づいて独自のバージョンシステムを開発する必要がありました。彼らは新しいシステムに対していくつかの目標を設定しました:

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

ログイン後にコピー

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

ワークスペース
:簡単に理解すると、プロジェクト 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

: #

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

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

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

HEAD、Branch、Tag

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

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

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

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

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

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

#マージマージ #:

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

リベースするとバージョン履歴が変更されます。リベース前の内容とリベース後の内容が一致していても、バージョンは同じバージョンではなくなります Git のさまざまなワークフローを深く理解する

fetch

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

#pull: git pull = fetch merge

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

はじめに

## の

Vincent Driessen Git のさまざまなワークフローを深く理解するより#2010 で書かれた記事

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

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

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

develop ブランチ: 開発に使用されます masterブランチとdevelopブランチの関係は上記の通りですが、点線は直接関係はなくrelease/hotfixブランチ Git のさまざまなワークフローを深く理解する

supportブランチ

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

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

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

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

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

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

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

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

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

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

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

追加

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

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

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

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

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