Git戦闘（5）|作業を効率化し、Gitブランチ管理を取得

前の記事では、オンラインマージとローカルマージの両方でのGitのブランチ管理プラクティスについて説明しました。結局のところ、練習をしないと言うだけは偽物です。しかし、整理するのではなく、練習するのは愚かでしかありません。支店管理はどのように管理されていますか？

GitLabの古典的な図から始めましょう。一般的な概要として、ブランチの管理と傾向を理解することも便利です。

シーンプリセット

ここで、会社にHogwarts_Online2という開発プロジェクトがあり、オンラインブランチマスター、開発ブランチの開発、テストブランチのリリース、および個人開発機能ブランチ<feature branch>が含まれているとします。

機能ブランチと開発ブランチ

1.1）リモートウェアハウスとの接続を確立し、ローカルに独自のブランチを作成し、開発ブランチのファイルをプルします。

1.2）現在のブランチに新しいファイルgitflowDemo.txtを作成し、コンテンツ「study git」を入力して、追加してコミットします

1.3）git pullコマンドを使用して、リモートの開発ブランチが現在のブランチと競合するかどうかを確認します。

注：開発プロセス中にリモートバージョンが他のユーザーによって更新されないようにするには、プッシュする前にまずリモートコードをプルしてください。コードの競合がある場合、両者は競合の解決について交渉します。複数の人々が発展するとき、対立は避けられません。

1.4）git pushはリモート機能ブランチのオリジンgitflowDemoに変更をプッシュします：

1.5）GitLabでマージリクエストを作成し、developブランチでマージします。

このマージを撤回したい場合は、 `git merge --abort`を使用できます

マージ要求を作成します。

開発ブランチを選択します。

競合はなく、直接マージできます。

最後に、developブランチへのマージが成功したことがわかります。

グラフでブランチの方向を確認することもできます。

このようにして、機能ブランチと開発ブランチのコードのプルとマージが完了します

さらに、開発ブランチの作業がよりオープンになり、プッシュが可能になる場合があります。現時点では、マージをローカルで直接変更してからリモート開発にプッシュできます。

gitflowDemo.txtファイルを次のように変更します

追加、コミット、プッシュ

ローカル開発ブランチに切り替え、最新のコードをプルし、ローカルgitflowDemoブランチコードをマージして、リモート開発ブランチにプッシュします。

これは、GitLabで更新を確認するためのものです。

リリースブランチ

開発ブランチは頻繁に変更され、マスターブランチは上限バージョンに属しているため、内部テスト用のブランチバージョンが必要です。これはリリースブランチです。

特定の送信操作は、1の開発操作と同じ許可範囲に基づいています。

修正プログラム

すぐに変更する必要がある非常に緊急のバグがあり、各ブランチでマージテストを実行するには遅すぎる場合があります。これは、ホットフィックスモードを使用してバグ修正ブランチを作成し、他のブランチを直接バイパスして、変更をマスターに変更することです。

注：テストなしでインターネットに接続するのは危険です。私はこれに遭遇しました。以前にHuaweiで作業していたときに、グループの開発担当者が1行または2行のコードを変更し、問題はないと感じました。私たちはテストをスキップして、他の人に直接公開しました。そのとき私が所属していたグループはGNSSグループでした。その結果、1,000万台を超える携帯電話の測位機能が直接障害の危険にさらされ、多くの苦情を受け、大きな影響がありました。開発者は緊急に休暇を取るのをやめられました、そして私たちのテストチームも11日に7日間の作業を追加し、この小さな変更に多くの結果を支払いました〜

3.1）バグ修正ブランチを確立し、リモートブランチにプッシュするようにファイルを変更します。