プロジェクトのルールや規則はチームによって異なると思いますが、ここでは入門者がプロジェクトに関わっていく上でもらった超初級なフィードバックを備忘録としてまとめておきたいと思います。随時更新予定です。

#ワークフロー全般に関するフィードバック

プルリクをするときは必ずUpdate from masterをする。（2016/12/26 Mon）
プルリク前にPC/SP(iphone5 , 6 , 6plus)それぞれの環境で正しく動作しているか確認すること（2016/12/26 Mon）
ブランチの命名規則を覚える（2016/12/26 Mon）

##プルリクをするときは必ずUpdate from masterをする。
自分がコードを書いてる間に他の人もコードを書いてアップデートしているから、それを自分のソースコードにも反映してプルリクをすること。最悪の場合、そのままmasterにsyncしてdeployしてしまうと他の人のアップデートが本番のソースコードから消える。また、アップデートする際は必ずコンフリクトを起こしてないか確認し、コンフリクトしている場合は解消すること。

##プルリク前にPC/SP(iphone5 , 6 , 6plus)それぞれの環境で正しく動作しているか確認すること
iphoneのバージョンによって画面の大きさが違うので一度作業を終えたら全てのバージョンで正しく想定通りの挙動を確認できるかという作業を怠ってはいけない。Chromeのdevtoolをつかってサイズを変えて確認していくのが王道だと思います。

##ブランチの命名規則を覚える

github上でissueをきる。
ブランチを切る。その際にissueの番号を先頭につける（i.g. xxx-implement-youtube-embeds）
作業開始

その他コミットの頻度やブランチを切ったあとのワークフローについては以下を参照。

個人的にはcommit/push単位とその理由が参考になりました。

コミットの最大粒度は1タスク
たとえタスクが途中でもキリが良ければ即コミット

コミットの頻度を細かくする理由

自身の見積もり精度やタスク管理能力向上

複数タスクが混在したコミットは悪
コミットとタグの相性UP
Pivotalなどの外部サービスとの連携が容易
履歴を参照する際のコスト低下(log, reset, bisect, rebase時など）
自分や他人がみてもcommit内容の把握が容易
プッシュの頻度を細かくする理由

大きなコンフリクト発生頻度低下

git pull の頻度も自然と上昇

チーム間での状況共有が容易
コードは即他人に晒すという意識向上