記事ディレクトリ
10.支店運営～支店紹介
目標
能说分支作用
コンテンツ
私たちの現在の Git の使用は、段階的に書いたコードを Git を使用して保存するために単純に理解でき、各提出物はバージョン情報を形成します。しかし、チームの全員が提出したバージョン情報が 1 つにまとめられるとどうなるか想像できますか? バージョンの数は数千にも及びます。Git はバージョンの操作を完了するのに役立つ一連の操作を提供しますが、最終的にはバージョンが多すぎると、見た目が乱雑になってしまいます。
たとえば、Zhang San は成熟した開発者です。彼はモジュールを完了した後にバージョンを提出します。Li Si はこの業界に 1 年いる開発者です。彼は機能を完了してバージョンを提出します。入社したばかりの Wang Wu の場合は、業界では、ファイルのバージョンを送信するのが待ちきれず、バージョンを送信するメソッドを作成することさえできますが、Git では実際に何万ものバージョンが管理されています。
実際、理想的な状況は次のようになります。Zhang San が機能 A を開発し、A が完全に作成される前にバージョンを提出せず、完成したらすべてのファイルを一度に提出します。このように、各バージョンの価値は非常に高く、無効な提出物が多数発生することはありません。無効な提出とは何ですか? モジュール内の 8 つのクラスを使用して作業します。クラスを作成してバージョンを送信した後は、ロールバックであろうとバージョン管理であろうと、単一のクラスで完全な開発状態を構成することはできません。このバージョンでは、ロールバックすることができません。使用していて、変更してもファイルが見つからないため、人々は非常にイライラします。
しかし、開発者として、私は自分の便宜のためにバージョンを入力し、いくつかのバックアップを作成しましたが、それは合理的であると思われました。このとき、新しい要件が提起されました。プロジェクト チームのコア コードと混合するのではなく、独自の専用バージョンを提出できますか? この関数は利用可能である必要があり、これは以下で説明するブランチです。
ブランチについて話す前に、以前の提出物が何であるかについて話しましょう。
提出の要点: ウェアハウス内の一連のファイルの変更情報 (追加、削除、変更) を記録する
支店とは何ですか?
ブランチは複数のコミットがつながった行です
シナリオ: 問題の背景: 新しい関数を開発したいが、現在のブランチ (メイン) の関数開発を邪魔したくないため、
メイン ブランチの開発は停止せず、関数 c4 の開発を続行でき、新しいブランチは新しい関数 c5 を開発でき、メイン ブランチには影響しないことがわかります。
新しいブランチの関数開発とテストに問題がなくなるまで待ちますが、メインでも新しいコードが必要な場合はどうすればよいでしょうか?
merge コマンドを使用して、新しいブランチの変更をメイン ブランチにマージできます。このとき、c6 には c4 以降の変更だけでなく、c5 の変更も含まれています。c5 が役に立たないと感じたら、削除できます。それ
私たちのブランチの説明は主に次のとおりです。
- 创建分支
- 切换分支
- 合并分支
- 查看分支
- 删除分支
まとめ
- あなた自身の理解に従って、ブランチとは何か、そしてそれが何をするのか教えてください
- ブランチは複数のコミットで構成される行です
- 機能: チーム開発がより便利になります。
支店の役割をまとめると
並行開発: ブランチを作成すると、複数の独立した開発タスクを同じコード ベースで同時に実行できます。各ブランチには、他のブランチとは独立して、コード変更の独自の記録があります。これにより、チームメンバーは、互いに干渉することなく、さまざまな機能に取り組んだり、さまざまな問題を並行して修正したりすることができます。
バージョン管理: 分岐により、コードのバージョン管理と追跡がより柔軟になります。各コミットの変更はブランチを通じて分離され、完全なコミット履歴を形成できます。このようにして、必要に応じて、さまざまなブランチでコードの変更を簡単に表示および比較でき、以前のバージョンに簡単にロールバックできます。
機能の開発とテスト: 新しい機能や修正は、専用のブランチを作成することでメイン ブランチ (通常はマスターまたはメイン ブランチ) から分離できます。こうすることで、新機能の開発とテストがメイン ブランチの安定したコードに影響を与えないようにすることができます。新しい機能が完成してテストされると、メイン ブランチにマージされて戻されます。
バグ修正とメンテナンス: master ブランチでバグが見つかった場合、または緊急の修正が必要な場合、修正を処理するために新しいブランチを作成できます。これにより、チームは他のブランチで通常の開発作業を継続しながら、そのブランチのバグ修正に集中できるようになります。修復が完了したら、ブランチをメイン ブランチにマージして戻し、修復コードを有効にすることができます。
バージョンのリリースと展開: 特定のバージョン (タグ) をタグ付けすることで、コード ベースに明確なリリース ポイントを作成できます。通常、これらのタグ付けアクションは安定したマスター ブランチに関連付けられているため、さまざまなバージョンのコードを簡単に追跡および管理できます。ブランチを使用すると、運用環境に影響を与えることなく、コードの特定のバージョンをテスト サーバーまたは運用サーバーにデプロイできます。
