この記事を書いた背景
2week中期インターン（所謂就職するためのインターン）に参加するときに、
チーム内でチーム開発経験が比較的ある方だったので、
テックリードとして開発ルール選定をした時の記事です。
（なので、そのチームで共有する前提の記事です）
余力があれば記事を一般化させます
開発ルール選定
開発しながら、
ある程度自由にルール選定する予定ですが、代表的な典型的なルールを共有していきます。
ケース
参考記事:
スネーク？キャメル？なんちゃらケースのまとめ
参考記事の
・アッパーキャメルケース
・ロウワーキャメルケース
・アッパースネークケース
の三つに関してある程度意識してコードを書くと、いい感じになります。
ロウワーキャメルケース
まず一番よく使うロウワーキャメルケースについて、
getBook
takeBookFromBookshelf
変数名,関数/メソッド名は、単語が二つ以上場合に最初の単語のみ小文字にし、
それ以外の頭文字を大文字にします。
(takeBookFromBookshelfを英文で表すと、 take book from bookshelf になりますよね。
このように英文で表すと、スペースが入る部分を単語と認識します。bookshelfをbookとshelfで分けて認識したりはしません。)
変数名
関数/メソッド名
で使います。
アッパーキャメルケース
次にクラス/ファイル名で使うアッパーキャメルケースです。
ロウワーキャメルケースと比較し、
getBook
takeBookFromBookshelf
に対して考えると、
GetBook
TakeBookFromBookshelf
最初の頭文字も、大文字にします。
クラス名
ファイル名
で使います。
（クラス名というのが、言語の仕様上考えると存在しない、考えづらい場合があるので、
理解が難しい場合はとりあえず、ファイル名のみ考えるで良いです。）
アッパースネークケース
次に定数名で使うアッパースネークケースです。
ロウワーキャメルケースと比較し、
getBook
takeBookFromBookshelf
に対して考えると、
GET_BOOK
TAKE_BOOK_FROM_BOOKSHELF
全ての文字を大文字にし、単語間を"_"で、繋ぎます
定数名
で使います。
（言語の仕様上、開発の仕様上使わないケースはありますし、これに関しては、使う場面がそう多くないので、ケースルールを気にしなくても良いかもしれません。）
ブランチ名
ブランチ名に関しては大規模な開発ではないので、典型ルールを適用しませんが、
典型ルールの一例ですと、
feature/開発version/課題番号-やった内容を要約
featureは、fix,feat,taskなど、その業務がどのような目的で行われたかによります。
今回はfeat(新機能追加),開発versionが存在してなく、
課題番号をわざわざ検索して戻るほど保守、運用しないので必要ないかと思われます。
（もし必要ならgithubもissueで番号が生成されると思います）
なので今回は
対象ファイル/やった内容を要約
で行いたいと思います。
アトミックデザイン/コンポーネント指向
参考記事:
アトミックデザインとは？ コンポーネント単位で創るUIデザイン手法
一応私が大事にしているアトミックデザイン、コンポーネント志向について記載しておきます。
再利用可能なコンポーネント(例えば決定buttonなど)は何度も使われるはずで、何回も作るとなると、
一度の改修でなんども同じ場所を直す必要がありますが、一つのパーツとして作り上げて、それを流用すると、そこの場所のみの改修ですみますし、マージの際の競合が発生しずらくなります。
小規模の場合、ボタンまでのアトミックデザインはそこまで意識しなくて良いと思いますが、
例えばナビゲーションバーなどは独立させて作る方が良い
（複雑な機能をもっているわりに独立させやすい）
のでそのレベルのコンポーネント指向は持っとくと良いかもしれません。