1提案を送信する
- コードを送信する前に、更新（svn up）、コンパイル、および機能テストは正常です。
- アトミックサブミッションを維持するために、関数またはバグを一度送信することをお勧めします。一度に複数の関数またはバグを送信することや、関数またはバグを複数回送信することはお勧めしません。
- コードを送信するコマンドの順序：svn up、（svn add）、svn diff、svn commit –m / -F。
- 明確なコメント付きのコードを送信してください。第3章のログ形式を参照できます。
- 提出コードが完了したら、別のコードセットを使用して以前の提出を更新し、コンパイルしてテストすることをお勧めします。
- SVNコードを送信するときに送信ログの準備を容易にするために、次の2つの方法を参照できます。
方法1：
#cd / home / xxxxx（ユーザー名）
#vi〜/ .subversion / config
＃editor-cmd = viを変更または追加します
注意：
設定後、-mパラメータを追加せずにコードを送信すると、自動的にviが開きます。コメントを書き、vi（wq）を保存して終了すると、コードが自動的に送信されます。
このコミットを途中でやめると、vi（！Q）を強制終了でき、svnコミットが終了します。
方法2：
svn commit --editor-cmd = vi file1.txt fil2.txt
2ログ形式
<type> <module>：<summary> //空の行 説明： 問題の説明。 現象、小文字、特に最初の文字が推奨されます 理由： 問題の根本的な原因。 理由 解決策： 問題の解決策。 ソリューション コードレビュー： コードのチェックを手伝ってくれる人のリストコードレビューが実行されない場合は、「レビューなし」とマークする必要があります。 RD1、RD2、RD3、…/レビューなし テスト結果： 問題のテスト状況、テストに合格、テストに合格、未テスト、テストしない理由を示す必要があります。 合格/環境テストなし
2.1タイプと要約の説明
typeは、バグを修正するか（問題）、機能を追加するか（関数）など、特定の送信のタイプを表します。概要は送信の簡単な説明であり、タイプの値は次の表にリストされている値のみです。すべてのタイプタイプと対応する要約コンテンツは次のとおりです。
| タイプ |
褒める |
概要 |
| 直す |
バグを修正する |
バグ番号はアルファバグ56のようなものです。番号がない場合は、RD XXXによって誰が発見したかなど、バグの原因を簡単に説明してください。 |
| 特徴 |
新機能 |
他のプロジェクトグループを参照する場合は、グループ名とプロジェクト名を指定できます。また、需要のソースも指定できます。 |
| 移植 |
同じプロジェクトグループ内の異なる製品のコードを同期する |
移植プロジェクト名とバージョン番号 |
| 追加する |
最後の提出がない場合に使用される追加の提出 |
最後の提出にバージョン番号がありません |
| パッチ |
econetのパッチなどの3つのパーティを同期する |
パッチのソースを示します |
| 元に戻す |
以前のバージョンにロールバックする |
以前のバージョンのバージョン番号 |
| コンパイル |
プロジェクト構築ツールとコンパイルに関連する問題 |
追加する |
| リファクタリング |
コードのリファクタリング、新機能やバグ修正なし |
追加する |
| パフォーマンス |
パフォーマンス、エクスペリエンスの向上など、最適化関連 |
追加する |
| スタイル |
コードロジックを変更せずに、スペース、フォーマットインデントなどを変更するだけ |
追加する |
| docs |
ドキュメントのみを変更しました |
追加する |
2.2モジュールの説明
moduleは、この提出に含まれるモジュールのタイプを表します。複数のモジュールは、コンマで区切られます。モジュール名は次の表にのみ記載されています。大文字と小文字に注意してください。また、リストが足りない場合は提出してください。現在のすべてのモジュールを以下に示します。
| 番号 |
名前 |
注意 |
番号 |
名前 |
注意 |
番号 |
名前 |
注意 |
| 1 |
busybox |
|
３ |
ウェブサーバー |
|
5 |
サンバ |
|
| 2 |
DHCP |
|
4 |
ウェブページ |
6 |
DLNA |
|
|
| 。 |
… |
|
。 |
… |
|
。 |
… |
|