# 作業手順と開発規則

## hackMD email address

hackMDフリープランのメンバー上限が三人なので それぞれください
- [e-mail]
- [e-mail]

## 分業

- マネージャー
- 担当者: 中野
- レポート作成, 進捗管理
- フロントエンド
- 担当者: 乙部 石倉
- サブ: 中野
- ページ構成
- リストと遷移
- 必要な構造体の列挙
- UI
- デザイン
- ヘッダー/フッター
- ページ
- バックエンド
- 担当者: 中川 平野
- サブ:
- ユーザー
- ログイン
- 組織作成/管理/ユーザー管理
- 要求物
- 作成/編集/削除/購入
- 品追加/品削除/購入数変更
- タグ作成/タグ付け外し

### 割り振り - フロントエンド

- ベースデザイン決め
- Figma

- ランディングページ　みんなで

- 新規アカウント作成　中野
- ログインページ　　　中野

- 組織選択　　　　　　石倉
- 組織作成　　　　　　石倉
- 組織ページ　　　　　石倉
- 組織編集　　　　　　石倉

・要求物ページ　　　　乙部

・商品ページ　　　　　乙部
・商品編集　　　　　　乙部
・商品作成　　　　　　乙部

・タグ作成　　　　　　中野
・タグ編集　　　　　　中野

・ヘッダー　　　　　　石倉
・ユーザーページ　　　中野

### 割り振り - バックエンド

- init.build + docker
- domain
- service
- user
- org
- need
- item
- tag
- et al

## 進行

## 開発計画
- 12/16 ~ 12/18
- フロントエンド: 画面デザイン案
- バックエンド : データベースの作成・ルーティング
- 12/19 ~ 12/25
- フロントエンド: 要求物ページ、商品ページ、作成（全般）、 ヘッダーフッター作成、組織一覧、ログイン、新規アカウント作成ページ、
- バックエンド : API 作成
- 12/26 ~ 1/4
- フロントエンド: ユーザー、編集（全般）、要求物一覧
- バックエンド : API 作成
- 1/5 ~ 1/8
- フロントエンド:ランディングページ案持ち込み・決定、組織系（組織一覧除く）
- バックエンド : API 作成
- 1/9 ~ 1/15
- フロントエンド: 全画面作成 完成
- バックエンド : API 作成・完成
- 全体　:　 アプリケーション動作確認・デモ動画撮影
- 1/16 ~ 1/22
- 全体 : スライド作成

## フロント→バックへの依頼

- データベースのサンプルとAPI
- 要求物一覧（商品一覧よりも優先）
- 組織一覧（左側に表示するやつ）
- 商品一覧＝要求物ページ
- 商品ページ
- 組織ページ

## gitの操作

### 自分のブランチにmainの変更を適用する

1. `git checkout main`
2. `git pull origin main`
3. `git checkout [branch name]`
4. `git merge main`

### commitするまでもない変更を置いといて別のブランチに行きたい

1. `git stash`
2. `git checkout [branch name]`

### 置いといた変更を取り戻したい

1. `git stash apply`

## リポジトリ規則

:::warning
main pushは緊急時以外禁止します
:::

:::info
issue-basedな開発をします 1-4をたくさん回してください
:::

### 開発の手順

0. 実装/修正/改善すべき事柄をissueにする
- github
- https://github.com/cs-sysimpl/sysdes01/issues
1. 「New Issue」を押す
2. 事柄を詳細に記載する
3. 必要に応じてタグを付ける
- ".frontend", ".backend"は選択必須
1. 自身が作業する対象となるissueの担当を自身に結び付ける {　|　}
- github
- https://github.com/cs-sysimpl/sysdes01/issues
1. 既存のissueで自分がやりたいタスクを開く
2. 「Assignee」に自身を割り振る
- 理由:
- assigneeを明示的に割り振らないと、「同時に同じissueを解決しようとして一方の作業が無駄になってしまった…」が発生しかねない
2. 自身の作業を行うbranchを作成 {　|　}
- git command
- `git checkout -b [branch name]`
- OR `git branch [branch name]` -> `git checkout [branch name]`
- 命名: `[特徴]/(#N_)[作業の内容]`
- 分かりやすくする程度の効果しかないので、よく分かんなかったら従わなくていいです
- issue番号を付けると、あとで自分がPullRequestを作る時に役立ちます
- にほんごでもいいです
- 命名例
- `feat/#10_AddUser` issue#10になっているAddUserを実装(feature)する
- `fix/usericon_not_visible` userのiconが表示されないバグを修正(fix)する
- `improve/faster_need_searching` needの検索を高速化する機能の改善(improve)を入れる
- など 特徴は適当でも良いです
3. 自身の作業branchに変更をコミット xN {　|　}
- git command
1. `git add .`(変更を全てステージ)
- OR `git add [ファイル名]`(特定の変更をステージ)
2. `git commit`(ステージした変更をコミットに)
- OR `git commit [message]`(コメント入力エディタの表示をスキップ)
3. `git push origin [branch name]`
- コミットの頻度
- コミットはtransitionみたいなものなので、commit単位で変更を打ち消すことが出来ます
- 「変更の特徴を一つの動詞で表せる程度」で切るとヨシ
- 命名: `[特徴]: 作業の内容` OR `[git emoji] [作業の内容]`
- 分かりやすくする程度の効果しかないので、よく分かんなかったら従わなくていいです
- にほんごでもいいです
- 命名例
- `feat: AddUser` AddUserAPIの実装
- `fix: AddUser wont add column on db` AddUserがdbに列を追加しない問題を直した
- `refactor: untangle complex code` 複雑化したコードを直し、「機能は変わらないコードへの改善」(refacor)をした
- `add: app icon` リソースの追加を行った
- `chore: fix typo` typoの修正みたいな何とも言えないその他の変更
- gitemojiの使い方はググってください
- 悪いコミット
- 「機能追加と一緒に過去に自分が作ったコードの修正もした」=> 1コミットに詰め込み過ぎ
- 「`fix: problem`」=> 何の修正か分からん
4. 自身のブランチをpull requestにする {　|　}
- github
- https://github.com/cs-sysimpl/sysdes01/pulls
1. 「Create PullRequest」
2. タイトルと説明文を書く
3. 解決したissue番号を`resolves #[issue number]`と説明文内に記載する
- 複数のissueを解決した場合は行を分ける事
4. Reviewer依頼をする
5. Reviewerから承認が来る
6. Merge PullRequestを押す
- 命名: 日本語でどういう変更をしたのか書く
- 説明: どういう変更かをいい感じに書く