なぜコード管理標準が必要なのでしょうか?
ちょっとした話をさせてください。あなたは Honor of Kings または League of Legends をプレイしたことがあります。私たちは相手のミッドレーナーをガンクする (ゲーム内の 1 人または複数のゲーム キャラクターが相手のゲーム キャラクターを急所攻撃し、側面を突いて殺害すること) したいので、合意された戦略は次のとおりです。
- 私たちのミッドレーナーは、相手のミッドレーナーを誘惑し、引きずり込む責任があります
- 私たちのジャングラーは草の中で待ち伏せして助けが来るのを待っています
- サポートプレイヤーが最下位レーンから応援に駆けつける
プレイヤーが戦略に従えば、良い波で敵を倒すことができますが、ジャングラーは落ち着かないため、待ち伏せのプロセス中に相手のジャングルエリアに行き、野生のモンスターの波を彼らが見られた場所で反転させました。相手選手が反撃してきたのですが、こちら側の選手たちはそれを知らずに喧嘩を始めましたが、ご想像のとおり、局地的な反撃を受けてやられました。
コード管理は、相互利益と共生を実現するための複数人によるコラボレーションでもあり、プロジェクトをスムーズに進めるためには、合意された戦略が必要です。
1.仕様をコミットする
標準化されたコミット ログにより、重要な情報を一目で確認できます。不正なログは、特にコードのロールバックが必要な場合に人々を混乱させ、混乱させます。かつて、次のような方法で送信を続けたチーム メンバーがいました。その後、彼女のコードをロールバックする必要がありました。このログの状況では、3 ～ 4 回ロールバックしても正しいノードが見つかりませんでした。この同僚は何度も説得を試みましたが無駄でした。この度、この同僚は会社から雇用契約について連絡を受けました。
タイプ (必須) + 件名 (必須) を含むコミット メッセージ送信仕様により、迅速な参照のための詳細な履歴情報が提供されます。特定の情報をフィルタリングできます (インストール パッケージの構築など)。
#1 type
#主要type
feat：新功能
fix: 修补bug
#特殊type
docs：文档（document）
style：格式（不影响代码运行的变动）
refactor：重构（既不是新功能，也不是修改bug的代码变动）
test：增加测试
build：构造工具的或者外部依赖的改动，例如webpack，npm
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
#2 subject
subject是 commit 目的的简短描述，不超过50个字符。
例は次のとおりです。
- 新機能
- バグ修正
の利点:
• 読みやすさと明瞭さ: コードを深く調べなくても、現在のコミットの役割を理解できます。
• コードレビューの準備
• プロジェクト履歴の追跡を容易にする
• gitblame を実行するときに他の開発者に明確にする
• プロジェクトの全体的な品質を向上させ、個人のエンジニアリングの品質を向上させる
2.支店管理仕様
ブランチ管理仕様。
- 現在のタスクの開発ブランチは開発ブランチであり、開発ブランチは開発ブランチとテスト ブランチとして使用されます。新しいオンラインがある場合は、マスター ブランチ コードを開発ブランチに手動でマージする必要があります。
- 開発ブランチのテストに合格し、開発から v2.0 などの現行バージョン ブランチ (以下では例として v2.0 を使用) に切り替え、v2.0 をプレリリース ブランチおよびオンライン ブランチとして使用します。
- v2.0 がプレリリース環境テストに合格すると、オンライン ブランチとして直接起動できます。
- v2.0 ブランチが正常に起動したら、master ブランチにマージする必要があります。
- オンラインバグ修正、v2.0のオンラインバグ修正、新しいブランチv2.1のカット、順次蓄積などが可能です。
git ブランチ管理のフローチャートは次のとおりです。
3. まとめ
優れた Git 管理方法により、チームの作業効率が大幅に向上し、提出時の混乱を回避できます。
参考：https://www.processon.com/diagrams/new#template
ご質問がございましたら、ご連絡ください〜
QQ グループへの参加へようこそ:
