Git: Fixbug は、ローカル マスターに基づいて構築されたバグ修正ブランチです。実際のシナリオにおけるベスト プラクティスは何ですか?
追記: リモートマスターには複数のユーザーに対する権限があります。
実際の実稼働環境でのこのプロセスの操作は少し混乱します:
最初のタイプ:
git checkout fixbug
git add .
git commit -m '...'
git チェックアウト マスター
git pull オリジンマスター
git merge fixbug
テスト用マスタープット
テストOK
git pull オリジンマスター
マスターはオンラインです
2 番目のタイプ:
git checkout fixbug
git add .
git commit -m '...'
git チェックアウト マスター
git pull オリジンマスター
git checkout fixbug
gitmergermaster
テストのためにテスト環境にバグを修正しました
テストがOKになったら、
git チェックアウト マスター
git pull オリジンマスター
git merge fixbug
git Push -u Origin master
13.master online
3 番目のタイプ:
あなたの提案は何ですか?
カニ！
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
2番目の感覚は、論理的な抜け穴があるということです。9回目のリリーステストが完了した後、コードに変更があった場合は再度テストする必要があります。
プロジェクトが複雑で、複数の人が並行して開発している場合は、仲介者が必要です。他のプログラマーがプル リクエストを作成した後、モデレーターはコードをレビューしてから、コードをリモート マスターとマージするかどうかを決定する必要があります。
一般プロジェクトには仲介者がいないので、仲介者はあなた自身です。