クローンの手順

1. 作業用フォルダを用意。

2. 作業用フォルダでgit clone [email protected]:kurakke/nitkit-shot.git

3. 以下のコマンドを上から順に実行。

   1. cd nitkit-shot

   2. npm install

以下コーディングルール

コミットメッセージ

• コミットメッセージはタイトル: 詳細の形式

• タイトル一覧

タイトル	コミット内容
add	機能・ファイル等の追加
fix	バグ等の修正
update	機能等修正（バグではない）
rename	ファイル・変数等の改名
move	ファイル・フォルダの移動
remove	ファイル・コード等の削除
readme	README の追記

命名ルール

• ブランチ

  • ブランチ名は右の形式: issue/issueの番号

  • 例: issue#1に関してブランチを作成する: issue/1

• TypeScript(JavaScript)の命名

記法	コミット内容	例
コンポーネント名	アッパーキャメルケース	UserForm
変数名	ローワーキャメルケース	sampleFunction
定数名	スネークケース	API_URL
関数名	ローワーキャメルケース	addNumber
プロパティ名	ローワーキャメルケース	userName
クラス名	アッパーキャメルケース	MyCar
インターフェイス名	アッパーキャメルケース	MemberProps

処理系のルール

• レンダー内で関数を定義しないこと

  • 悪い例

  return <button onClick={() => dispatch(ACTION_TO_SEND_DATA)}>This is a bad example</button>;

  • 良い例

  const submitData = () => dispatch(ACTION_TO_SEND_DATA);
  
  return <button onClick={submitData}>This is a good example</button>;

• コンポーネントに子要素がない場合は、自己終了タグを使うこと

  • 悪い例

  <SomeComponent variant='stuff'></SomeComponent>

  • 良い例

  <SomeComponent variant='stuff' />

• 三項演算子を使用すること

  • 悪い例

  const { role } = user;
  if (role === ADMIN) {
    return <AdminUser />;
  } else {
    return <NormalUser />;
  }

  • 良い例

  const { role } = user;
  return role === ADMIN ? <AdminUser /> : <NormalUser />;

• 文字列変数の受け渡しには波括弧は使用しないこと

  • 悪い例

  return <Navbar title={'My Special App'} />;

  • 良い例

  return <Navbar title='My Special App' />;

• ブール変数の受け渡しの時、値がtrueの場合には、省略形を使うこと

  • 悪い例

  return <Navbar showTitle={true} />;

  • 良い例

  return <Navbar showTitle />;

• 文字列の合成にはテンプレートリテラルを使用すること

  • 悪い例

  const name = 'デク';
  const age = 16;
  const food = 'リンゴ';
  
  console.log(
    '私の名前は' +
      name +
      'です。' +
      '年齢は' +
      age +
      '歳です。' +
      '好きな食べ物は' +
      food +
      'です。',
  );
  //出力結果：私の名前はデクです。年齢は１６歳です。好きな食べ物はリンゴです。

  • 良い例

  const name = 'デク';
  const age = 16;
  const food = 'リンゴ';
  
  console.log(`私の名前は${name} です。年齢は${age}歳です。好きな食べ物は${food}です。`);
  //出力結果：私の名前はデクです。年齢は１６歳です。好きな食べ物はリンゴです。

• 変数の宣言にはなるべくconstを使用すること

プルリクエストのルール

• タイトルには何を行なったかをわかりやすく書くこと

• 説明欄には以下のものを必ず記述すること

  1. 対応する GitHub の issue の URL

  2. どのような変更・追加を行ったかの説明

• エラー等の問題解決のためにプルリクエストを立ち上げた場合、どのような問題が発生し、どのように解決したかを説明欄に記述すること

  例: 「不具合 A」が、「ファイル B」で発生したため、「C」のように解決した場合

  「不具合A」のような問題が「ファイルB」で発生したため、「C」のように解決しました。と説明欄に追記する。

• レビュアーに重点的に見てほしい箇所がある場合それがどこであるかを説明欄で明示すること

  例: 実装したコードの中で、「ファイル A」の「X 行目」からの処理を重点的に見てほしい場合

  「ファイルA」の「X行目」から処理を重点的にチェックしてください。と説明欄に追記する。

• プルリクエストの内容が、issue の一部分の場合、どの部分を担当したのかを説明欄に記述すること

  例: 「要素A」、「要素B」、「要素C」を実装する内容のissue#1が存在し、作成したプルリクエストの内容が「要素A」のみを実装したものだった場合

  issue#1での実装内容の内、「要素A」を実装しました。と説明欄に追記する。

• 一度のプルリクエストでの変更量は、レビュアー側の負担を考えて、適切な大きさにすること

  • 具体例

• レビューコメントに対する修正を行なった際は修正内容のコミット ID のリンクをコメントに貼って返信すること

  • 詳しい手順

• ブランチを作成した時点で、git commit --allow-emptyを実行してpushした後、github でDraft Pull Requestを出すこと

  • 詳しい手順

  • Draft Pull Request について

プルリクエストのルールに関する具体例