どのくらいの頻度で変更のリストを調べて理解する必要がありましたか？
コメントをざっと見て、必要な情報をすべて知りたいですか？
私たちのチームで確立された略語を共有したいと思います。
- ::サブシステム
- =新しいものを作成しました。 アナロジー：int a = 30;
- +追加されたメソッド/機能
- -削除済み（例：非推奨）
- 〜互換性のあるままに変更（小さなリファクタリング）
- ; 論理作業/ステージが完了しました。
- @最適化。 （記号はカタツムリのようなものです）
- *バグ修正
- ％2つのモジュール/サブ機能に分割
- ＆ロジックを簡素化（ある種のがらくたがありました）
- $サポートを追加しました。 （進化！サポート->！S-> $）
- ？ 注意、議論が必要です。 何が正しいのか分かりません。
- ！ 互換性のない変更、注意が必要
- `マイナーチェンジ。
- | 彼らが達成したこと（タスクボードに描かれたもの）
- \、/-分岐
これは私たちが定期的に使用するものであり、常に必要です。
リストは完全とはほど遠い（さらに多くのコミットイベントがあります）が、残りはまだ体系化されていません。
あなたの創造性の象徴はたくさん残った。
例
マネージャーの内部ロジックをリファクタリングし、Runメソッドのバグを修正しました。
~ task_manager * task_manager::Run(num)
マネージャーの開発は別のブランチに入ります。 多くの互換性のないドラフトの変更が計画されています。
/ task_manager
単純なタスクの作業が完了したら、コミットに分割し、後でメインブランチとマージできるようにします。
\ task_manager::simple_task
詳細なコメント。
サブシステムの変更のステータスに互換性があり、機能が追加され、ロジックが簡素化され、コミットが論理的に完了しました。
base::exception: ~+&; | ~ - * % fatal_exception operation_fail ?
私は他のアイデアがあればとてもうれしいです、コメントであなたの応答を楽しみにしています。