1.1 GitHubの「Repositories」から「New」ボタンを押す。
1.2 リポジトリ名はすべて小文字でハイフンで区切る（例：my-dev-workflow）。
1.3 public/privateを選択する。
1.4 README.mdファイルを追加する。
1.5 必要な場合は.gitignoreファイルを追加する。
1.6 ライセンスを付与する。ライセンスを明示しない場合は、他者が利用できないので注意。
2.1 作業フォルダに移動する。
2.2 ローカルにクローンする。
git clone https://github.com/<ユーザー名>/<リポジトリ名>.git
3.1 .github/ISSUE_TEMPLATE/フォルダにIssueのテンプレートを作成する。テンプレート例はこちら。
3.2 .github/PULL_REQUEST_TEMPLATE.mdファイルにPull Requestのテンプレートを作成する。テンプレート例はこちら。
3.3 6.2~6.4を実行し、リモートリポジトリにプッシュする。
git add .
git commit -m "chore: Add templates for issues and pull requests"
git push origin main
4.1 GitHubで該当リポジトリを開く。
4.2 「Issues」から「New issue」ボタンを押す。
4.3 テンプレートを選択し、新しいIssueを作成する。
4.4 Issue番号を確認する（後でブランチ名やコミットメッセージに使用）。
5.1 新しく開発ブランチを作成する。開発ブランチの命名規則についてはこちら。
git checkout -b <Issue番号>-<prefix>/<開発内容>
5.2 開発ブランチに切り替わっているかを確認する。
git branch
6.1 開発作業を進める。
6.2 コミットしたいファイルをインデックスに追加する。
git add <file path>
6.3 インデックスに登録した内容をローカルリポジトリにコミットする。コミットメッセージの命名規則についてはこちら。
git commit -m "<prefix>: <開発内容> (#<Issue番号>)"
6.4 ローカルリポジトリの内容をリモートリポジトリにプッシュする。開発ブランチ名は現在いるブランチを指すHEADで代用できる。
git push origin <開発ブランチ名>
6.5 必要に応じて6.1~6.4を繰り返す。
7.1 GitHubで該当リポジトリを開く。
7.2 「Pull requests」から「New pull request」ボタンを押す。
7.3 新しいPull Requestを作成する。
7.4 Pull requestの作成完了後、画面右下の「Development」に該当するIssueを追加する。追加したIssueは、このPull Requestのマージが成功後、自動的に閉じられる。
8.1 GitHubで該当リポジトリを開く。
8.2 GitHubのPull RequestsからマージしたいPull Requestを開く。
8.3 「Merge pull request」ボタンを押す。
8.4 「Confirm merge」ボタンを押し、マージする。
9.1 mainブランチに切り替える。
git checkout main
9.2 ローカルのmainブランチを更新する。
git pull origin main
10.1 マージされたローカルの開発ブランチを削除する。
git branch --delete <開発ブランチ名>
10.2 マージされたリモートの開発ブランチを削除する。
git push origin --delete <開発ブランチ名>
10.3 念のため、リモートリポジトリから最新のブランチ情報を取得する。
git fetch -p
git checkout -b <Issue番号>-<prefix>/<開発内容>
- Issue番号については、4.3で確認した番号を使う。
- prefixについては、以下の中から適するものを使う。
- feature: 新しい機能の開発
- fix: バグの修正
- refactor: リファクタリング
- chore: 雑務的な作業
- 開発内容については、すべて小文字でハイフンで区切る。
git commit -m "<prefix>: <開発内容> (#<Issue番号>)"
- prefixについては、以下の中から適するものを使う。
- feat: 新しい機能の開発
- fix: バグの修正
- refactor: リファクタリング
- perf: パフォーマンス向上のための変更
- test: テストの追加や変更
- chore: パッケージのインストールやビルドプロセスの変更など
- docs: ドキュメントの追加や変更
- style: コード自体には影響しない変更（空白、インデント、セミコロンなどのコーディングスタイル）
- 開発内容については、英語か日本語を使う。文末のピリオドや句点はいらない。
- Issue番号については、4.3で確認した番号を使う。
- フォーマッターやリンターツールを導入し、コーディングスタイルを統一する。
- テストコードをしっかりと書き、保守性を上げる。
- 変数名や関数名は分かりやすくして、可読性を上げる。
- 「Continuous Integration」の略。
- コードの変更をリポジトリに統合するたびに自動でテストやビルドを行い、品質を保つ仕組みのこと。
- 「Continuous Delivery」または「Continuous Deployment」の略。
- 継続的デリバリーは、テストやビルド後に本番環境へリリースできる状態を常に保つ仕組みのこと。
- 継続的デプロイは、テストやビルドが成功したら自動で本番環境にデプロイまで行う仕組みのこと。
-
.github/workflows/フォルダを作成する。 -
そのフォルダの中に、
.ymlファイル形式でCIやCDの記述をする。詳しくはプロジェクトで使用している環境に合わせて調べてください。