-
Notifications
You must be signed in to change notification settings - Fork 3
Home
JioShun edited this page Sep 21, 2022
·
8 revisions
- Git flowというモデルで開発を進めようと考えています。
- 提唱された記事
- 日本語で説明されてる記事
- 以上の形に沿って、今回の開発に適した形での運用を行います。
- mainブランチは各スプリントの成果をマージしていきます。
- developブランチは基本の開発ブランチです。ここからブランチを切って開発してください。
- feature/hoge(hogeは任意の機能名)ブランチですが、今回はプラットフォーム二つを統合しているため、feature/ios/hogeまたはfeature/android/hogeとしてください。
- hotfixesブランチは緊急のバグ直しブランチです。使用頻度は高くありませんが、ステークホルダーに見せる時にやばいバグが発覚したなどがあれば使用してください。
- コミットメッセージはわかりやすければ基本なんでもいいです。日本語でも英語でも構いませんが、CLI(Git bashやTerminal)を使用している場合は英語の方が入力しやすいです。
- ダメな例: "おやすみコミット", "多分動くと思います"
- 内容は任せますが、そのコミットの方向性がわかるprefixをつけてください。(prefixって何って人は聞いてください)
-
add:
機能などの追加を行った時 -
update:
orfix:
ファイルの修正などを行った時 -
wip:
WIP(Work in progress: 作業中)の時
-
- 進捗全然ねえ~という場合でも作業ブランチであれば他の人に迷惑かけないので積極的にコミットしましょう。具体的にいうなら2時間に1回程度が望ましいです。(Gitは作業内容を戻せるからどんどんやりましょう)
- 基本は各featureブランチからdevelopブランチにマージしたい時、つまりはfeatureブランチで開発していた機能が完成した時などにPRを出してください。
- 対応するJiraのチケットのURLを張り付けてください。
- テックリーダーかPOがスプリントレビュー前にdevelopブランチからmainブランチにPRを出します。なるべく全員でコードレビューするようにしましょう。
- PRでは、一人以上のコードレビューを必須にします。レビュー時のチェックすることリストは鋭意制作中ですが、基本的には下記を見るようにしてください。
- 変なファイルやコードが無いか
- 関数名、変数名などが適切か
- コーディングルールを守れているか
- ロジック箇所(UIではなく内部の関数などの処理)はテストを書くようにしたいです。