docs: MEMO.mdにConventional Commitsの詳細を追加
- コミットメッセージの標準化に関する概要を記載 - 基本構造と主要なtypeの説明を追加 - 実例を通じて具体的な使用方法を示す - GitHub CopilotやCI/CDとの統合についても言及
This commit is contained in:
parent
6310729265
commit
fc1a75eec1
6 changed files with 5622 additions and 1 deletions
296
FLOW.md
Normal file
296
FLOW.md
Normal file
|
|
@ -0,0 +1,296 @@
|
|||
# GitHub Development Flow Guide
|
||||
|
||||
このガイドは、Git worktreeを活用した効率的な開発フローをまとめたものです。
|
||||
|
||||
## 📋 基本的な開発フロー
|
||||
|
||||
### 1. 新規開発の流れ
|
||||
|
||||
#### 計画フェーズ
|
||||
1. **リポジトリの作成**: GitHub上でプロジェクト用のリポジトリを作成
|
||||
2. **ブランチ戦略の決定**:
|
||||
- `main`: リリース可能な安定版
|
||||
- `develop`: 開発統合用ブランチ
|
||||
3. **仕様書の作成**: README.mdに「何を」「なぜ」「誰のために」を記載
|
||||
4. **タスクの洗い出しと分解**: 数時間〜1日で完了できるレベルまで細分化
|
||||
5. **全タスクのIssue化**: GitHub Issuesに登録し、Projectsボードで管理
|
||||
|
||||
#### 開発フェーズ
|
||||
```bash
|
||||
# 1. Issueの選択
|
||||
# GitHub ProjectsでIssueを「進行中」に移動
|
||||
|
||||
# 2. worktreeでブランチ作成
|
||||
git worktree add -b feature/11-login-ui ../login-ui-work develop
|
||||
cd ../login-ui-work
|
||||
|
||||
# 3. 開発作業
|
||||
# コーディング作業
|
||||
|
||||
# 4. コミット (Conventional Commits形式)
|
||||
git add .
|
||||
git commit -m "feat: ログインフォームのUIコンポーネントを作成 #11"
|
||||
|
||||
# 5. プッシュ
|
||||
git push origin feature/11-login-ui
|
||||
```
|
||||
|
||||
#### レビュー＆統合フェーズ
|
||||
1. **プルリクエストの作成**: GitHub上でPRを作成（`Closes #11`を含める）
|
||||
2. **自動テストの実行**: GitHub Actionsが自動でテストを実行
|
||||
3. **コードレビュー**: レビュアーがコードを確認
|
||||
4. **マージ**: テストとレビューが完了したらマージ
|
||||
5. **後片付け**:
|
||||
```bash
|
||||
cd ../my-project
|
||||
git worktree remove ../login-ui-work
|
||||
git branch -d feature/11-login-ui
|
||||
git push origin --delete feature/11-login-ui
|
||||
```
|
||||
|
||||
### 2. 機能追加の流れ
|
||||
|
||||
#### 計画フェーズ
|
||||
1. **機能要件の明確化**: What（何を）、Why（なぜ）、How（どのように）を定義
|
||||
2. **Issueの作成**: 要件、技術的検討事項、受け入れ条件を記載
|
||||
3. **ラベルとプロジェクトボードへの追加**: `feature`ラベル、優先度設定
|
||||
4. **タスクの分解**: 大きな機能はサブタスクに分割
|
||||
|
||||
#### 開発フェーズ
|
||||
```bash
|
||||
# 1. 最新のdevelopを取得
|
||||
cd ../my-project
|
||||
git checkout develop
|
||||
git pull origin develop
|
||||
|
||||
# 2. 機能用の作業場を作成
|
||||
git worktree add -b feature/24-comment ../comment-work develop
|
||||
cd ../comment-work
|
||||
|
||||
# 3. 開発（小さなコミットを重ねる）
|
||||
git commit -m "feat: コメント投稿フォームのUIを作成 #24"
|
||||
git commit -m "test: コメント投稿APIのテストを追加 #24"
|
||||
|
||||
# 4. 定期的なプッシュ
|
||||
git push origin feature/24-comment
|
||||
```
|
||||
|
||||
#### レビュー＆テストフェーズ
|
||||
1. **セルフレビュー**: 不要なコードの削除、フォーマット確認
|
||||
2. **プルリクエストの作成**: 変更内容、テスト方法、スクリーンショットを含める
|
||||
3. **自動テストとCI/CD**: GitHub Actionsによる自動検証
|
||||
4. **コードレビュー**: 設計、可読性、テスト、パフォーマンス、セキュリティ
|
||||
5. **フィードバック対応**: レビューコメントに基づく修正
|
||||
|
||||
### 3. バグ修正の流れ
|
||||
|
||||
#### バグの分類
|
||||
- **Critical（緊急）**: サービス停止、データ損失の危険 → mainからhotfix
|
||||
- **High（高）**: 主要機能の不具合 → developからbugfix
|
||||
- **Medium/Low**: 限定的な影響 → developからbugfix
|
||||
|
||||
#### 修正フロー
|
||||
```bash
|
||||
# 1. バグ報告のIssue作成（詳細な再現手順、期待動作、実際の動作、エラーログ）
|
||||
|
||||
# 2. 緊急度に応じたブランチ作成
|
||||
# 緊急の場合
|
||||
git worktree add -b hotfix/28-critical-auth ../hotfix-auth main
|
||||
|
||||
# 通常の場合
|
||||
git worktree add -b bugfix/27-login-validation ../bugfix-login develop
|
||||
|
||||
# 3. バグの再現とテスト作成
|
||||
cd ../bugfix-login
|
||||
# まず失敗するテストを書く
|
||||
npm test -- --grep "email with plus sign" # 失敗を確認
|
||||
|
||||
# 4. 修正の実装（最小限の変更）
|
||||
git commit -m "test: メールアドレスに+記号を含む場合のテストを追加 #27"
|
||||
git commit -m "fix: メールアドレスの+記号を正しく処理するように修正 #27"
|
||||
|
||||
# 5. 検証
|
||||
npm test # すべてのテストがパス
|
||||
npm run dev # 手動確認
|
||||
|
||||
# 6. プッシュとPR
|
||||
git push origin bugfix/27-login-validation
|
||||
```
|
||||
|
||||
## 🔄 並列開発のパターン
|
||||
|
||||
### 複数機能の同時開発
|
||||
|
||||
```bash
|
||||
# 3つの機能を並行開発
|
||||
../feature-login/ # ログイン機能（localhost:3000）
|
||||
../feature-profile/ # プロフィール機能（localhost:3001）
|
||||
../feature-dashboard/ # ダッシュボード（localhost:3002）
|
||||
|
||||
# 各ディレクトリで独立して開発サーバーを起動
|
||||
cd ../feature-login && npm run dev
|
||||
cd ../feature-profile && npm run dev -- --port 3001
|
||||
cd ../feature-dashboard && npm run dev -- --port 3002
|
||||
```
|
||||
|
||||
### レビュー対応中の新規開発
|
||||
|
||||
```bash
|
||||
# PR待ちの間に別の作業を開始
|
||||
../feature-A/ # レビュー待ち
|
||||
../feature-B/ # 新規開発中
|
||||
../bugfix-C/ # 緊急修正
|
||||
|
||||
# レビューコメントが来たらすぐに切り替え
|
||||
cd ../feature-A
|
||||
# 修正対応
|
||||
git add .
|
||||
git commit -m "fix: レビュー指摘事項を修正"
|
||||
git push
|
||||
```
|
||||
|
||||
## 🛠️ 便利なコマンド集
|
||||
|
||||
### worktree管理
|
||||
|
||||
```bash
|
||||
# worktree一覧表示
|
||||
git worktree list
|
||||
|
||||
# 不要なworktreeの削除
|
||||
git worktree prune
|
||||
|
||||
# 特定のコミットからworktree作成
|
||||
git worktree add -b feature/test ../test-feature abc123def
|
||||
```
|
||||
|
||||
### ブランチ管理
|
||||
|
||||
```bash
|
||||
# リモートブランチの最新化
|
||||
git fetch --all --prune
|
||||
|
||||
# マージ済みブランチの削除
|
||||
git branch --merged | grep -v "\*\|main\|develop" | xargs -n 1 git branch -d
|
||||
```
|
||||
|
||||
## 📝 コミットメッセージ規約
|
||||
|
||||
### Conventional Commits形式
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
<body>
|
||||
|
||||
<footer>
|
||||
```
|
||||
|
||||
#### Type一覧
|
||||
- `feat`: 新機能
|
||||
- `fix`: バグ修正
|
||||
- `docs`: ドキュメントのみの変更
|
||||
- `style`: コードの意味に影響しない変更
|
||||
- `refactor`: バグ修正や機能追加を伴わないコード変更
|
||||
- `perf`: パフォーマンス改善
|
||||
- `test`: テストの追加・修正
|
||||
- `chore`: ビルドプロセスやツールの変更
|
||||
|
||||
#### 例
|
||||
```bash
|
||||
git commit -m "feat(auth): JWT認証を実装"
|
||||
git commit -m "fix: メモリリークを修正"
|
||||
git commit -m "docs: READMEにインストール手順を追加"
|
||||
```
|
||||
|
||||
## 🤖 GitHub連携機能
|
||||
|
||||
### GitHub Actions（自動化）
|
||||
|
||||
`.github/workflows/ci.yml`:
|
||||
```yaml
|
||||
name: CI
|
||||
on:
|
||||
pull_request:
|
||||
branches: [main, develop]
|
||||
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: actions/setup-node@v3
|
||||
- run: npm ci
|
||||
- run: npm test
|
||||
- run: npm run lint
|
||||
```
|
||||
|
||||
### PR作成時のチェックリスト
|
||||
|
||||
```markdown
|
||||
## 変更内容
|
||||
- [ ] 機能の説明を記載
|
||||
- [ ] テストを追加/更新
|
||||
- [ ] ドキュメントを更新
|
||||
|
||||
## テスト
|
||||
- [ ] ローカルでテスト実行
|
||||
- [ ] 手動での動作確認
|
||||
|
||||
## レビュー依頼事項
|
||||
- 特に確認してほしい箇所を記載
|
||||
```
|
||||
|
||||
## 💡 Tips & Best Practices
|
||||
|
||||
### 1. worktreeの命名規則
|
||||
```bash
|
||||
# 推奨される命名パターン
|
||||
../feature-login # 機能開発
|
||||
../bugfix-auth # バグ修正
|
||||
../hotfix-critical # 緊急修正
|
||||
../experiment-new-ui # 実験的変更
|
||||
```
|
||||
|
||||
### 2. 並列開発の注意点
|
||||
- 各worktreeで異なるポートを使用
|
||||
- node_modulesは各worktreeで独立管理
|
||||
- 環境変数は各worktreeで設定
|
||||
|
||||
### 3. クリーンアップの習慣
|
||||
```bash
|
||||
# 週次でのクリーンアップ
|
||||
git worktree prune
|
||||
git remote prune origin
|
||||
git branch --merged | grep -v "\*\|main\|develop" | xargs -n 1 git branch -d
|
||||
```
|
||||
|
||||
### 4. トラブルシューティング
|
||||
|
||||
worktreeが削除できない場合:
|
||||
```bash
|
||||
# 強制削除
|
||||
git worktree remove --force ../feature-xxx
|
||||
|
||||
# 手動削除後のクリーンアップ
|
||||
rm -rf ../feature-xxx
|
||||
git worktree prune
|
||||
```
|
||||
|
||||
ブランチの切り替えができない場合:
|
||||
```bash
|
||||
# 未コミットの変更を一時保存
|
||||
git stash
|
||||
# または
|
||||
git commit -m "WIP: 作業中の変更"
|
||||
```
|
||||
|
||||
## 🎯 まとめ
|
||||
|
||||
Git worktreeを活用することで：
|
||||
- ✅ 複数の作業を物理的に分離して管理
|
||||
- ✅ コンテキストスイッチのコストを最小化
|
||||
- ✅ 並列開発による生産性向上
|
||||
- ✅ レビュー対応と新規開発の両立
|
||||
|
||||
このフローに従うことで、効率的で整理された開発環境を維持できます。
|
||||
2216
GitHub個人開発 最大効率化戦略.md
Normal file
2216
GitHub個人開発 最大効率化戦略.md
Normal file
File diff suppressed because it is too large
Load diff
537
MEMO.md
537
MEMO.md
|
|
@ -836,4 +836,539 @@ git commit -m "fix: APIレスポンスのnullチェックを追加 #28"
|
|||
- 同じパターンのバグを自動検出するlintルールの追加
|
||||
- テストケースの充実
|
||||
- コードレビューのチェックリスト更新
|
||||
- ドキュメントの改善
|
||||
- ドキュメントの改善
|
||||
|
||||
# Conventional Commits - 標準化されたコミットメッセージ
|
||||
|
||||
## 概要
|
||||
Conventional Commitsは、コミットメッセージに意味のある接頭辞（type）を付けることで、変更の意図を明確にし、自動化を可能にする規約です。
|
||||
|
||||
## 基本構造
|
||||
```
|
||||
<type>(<scope>): <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
## 主要なtype
|
||||
|
||||
### 基本的なtype
|
||||
- **feat**: 新機能の追加
|
||||
- **fix**: バグ修正
|
||||
- **docs**: ドキュメントのみの変更
|
||||
- **style**: コードスタイルの変更（フォーマット、セミコロンなど）
|
||||
- **refactor**: バグ修正や機能追加を伴わないコードの変更
|
||||
- **test**: テストの追加・修正
|
||||
- **chore**: ビルドプロセスや補助ツールの変更
|
||||
|
||||
### 実例
|
||||
```bash
|
||||
# 新機能
|
||||
git commit -m "feat: ユーザープロフィール画面を追加 #15"
|
||||
git commit -m "feat(auth): JWTトークンによる認証を実装"
|
||||
|
||||
# バグ修正
|
||||
git commit -m "fix: ログイン時のメールバリデーションエラーを修正 #27"
|
||||
git commit -m "fix(api): nullレスポンスのハンドリングを追加"
|
||||
|
||||
# ドキュメント
|
||||
git commit -m "docs: READMEにインストール手順を追加"
|
||||
git commit -m "docs(api): エンドポイントの説明を更新"
|
||||
|
||||
# リファクタリング
|
||||
git commit -m "refactor: 認証ロジックを別モジュールに分離"
|
||||
git commit -m "refactor(utils): 日付処理関数を統合"
|
||||
|
||||
# テスト
|
||||
git commit -m "test: ユーザー登録のE2Eテストを追加"
|
||||
git commit -m "test(unit): バリデーション関数のテストケースを追加"
|
||||
|
||||
# 破壊的変更（重要）
|
||||
git commit -m "feat!: APIのレスポンス形式を変更"
|
||||
git commit -m "fix!: 認証方式をセッションからJWTに変更"
|
||||
```
|
||||
|
||||
## メリット
|
||||
|
||||
1. **履歴の可読性向上**: `git log --oneline`で変更の種類が一目瞭然
|
||||
2. **自動化**:
|
||||
- CHANGELOGの自動生成
|
||||
- セマンティックバージョニング（major.minor.patch）の自動更新
|
||||
- 特定typeのコミットに対するCI/CDトリガー
|
||||
3. **コミットの規律**: 1コミット1目的の原則が自然に身につく
|
||||
|
||||
## worktreeワークフローとの統合
|
||||
|
||||
```bash
|
||||
# Issue #30のユーザー設定機能を開発
|
||||
git worktree add -b feature/30-user-settings ../settings-work develop
|
||||
cd ../settings-work
|
||||
|
||||
# 開発を進めながら、目的別にコミット
|
||||
git commit -m "feat: ユーザー設定画面のUIを作成 #30"
|
||||
git commit -m "feat: 設定保存APIエンドポイントを追加 #30"
|
||||
git commit -m "test: 設定保存機能のテストを追加 #30"
|
||||
git commit -m "docs: 設定機能のAPI仕様を記載 #30"
|
||||
```
|
||||
|
||||
# GitHub Copilotによる開発効率化
|
||||
|
||||
## セットアップ
|
||||
1. VS CodeにGitHub Copilot拡張機能をインストール
|
||||
2. GitHub Copilot Chat拡張機能もインストール（対話型支援用）
|
||||
|
||||
## 主要な活用シーン
|
||||
|
||||
### 1. コード補完とインライン生成
|
||||
```javascript
|
||||
// コメントを書くだけで実装を生成
|
||||
// ユーザーのメールアドレスをバリデートする関数
|
||||
function validateEmail(email) {
|
||||
// Copilotが正規表現とバリデーションロジックを提案
|
||||
}
|
||||
```
|
||||
|
||||
### 2. インラインチャット（Cmd+I / Ctrl+I）
|
||||
コードを選択して、自然言語で指示：
|
||||
- 「このコードをTypeScriptに変換して」
|
||||
- 「エラーハンドリングを追加して」
|
||||
- 「より効率的に書き直して」
|
||||
|
||||
### 3. チャットビュー（サイドパネル）
|
||||
より複雑な質問や、プロジェクト全体に関する相談：
|
||||
- 「このプロジェクトの認証フローを説明して」
|
||||
- 「新しいAPIエンドポイントを追加する手順は？」
|
||||
|
||||
### 4. スラッシュコマンド
|
||||
- `/explain`: 選択したコードの説明
|
||||
- `/tests`: ユニットテストの自動生成
|
||||
- `/fix`: バグの修正提案
|
||||
- `/optimize`: パフォーマンス改善の提案
|
||||
|
||||
### 5. エージェント
|
||||
- `@workspace`: プロジェクト全体を理解した上での回答
|
||||
- `@vscode`: VS Codeの使い方に関する質問
|
||||
|
||||
## 実践的な使用例
|
||||
|
||||
### Issue駆動開発での活用
|
||||
```markdown
|
||||
# GitHub Issueの内容をCopilotに渡す
|
||||
「Issue #35: ユーザー検索機能を実装する。メールアドレスまたは名前で検索可能にする」
|
||||
|
||||
# Copilotへの指示
|
||||
@workspace この機能を実装するために必要なファイルと手順を教えて
|
||||
```
|
||||
|
||||
### テスト駆動開発（TDD）での活用
|
||||
```javascript
|
||||
// 1. まずテストを書く（Copilotが補完）
|
||||
describe('UserSearch', () => {
|
||||
it('should find users by email', async () => {
|
||||
// Copilotがテストケースを提案
|
||||
});
|
||||
});
|
||||
|
||||
// 2. 実装を生成
|
||||
// Copilot: 「このテストをパスする実装を作成して」
|
||||
```
|
||||
|
||||
### コミットメッセージの生成
|
||||
VS Codeのソース管理パネルで、Copilotアイコンをクリックして変更内容に基づいたConventional Commits形式のメッセージを生成。
|
||||
|
||||
# GitHub Actions - CI/CD自動化
|
||||
|
||||
## 基本的なCI/CDパイプライン
|
||||
|
||||
### 1. 継続的インテグレーション（CI）
|
||||
```yaml
|
||||
# .github/workflows/ci.yml
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ develop, 'feature/**' ]
|
||||
pull_request:
|
||||
branches: [ develop, main ]
|
||||
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20'
|
||||
cache: 'npm'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Run linter
|
||||
run: npm run lint
|
||||
|
||||
- name: Run tests
|
||||
run: npm run test
|
||||
|
||||
- name: Build
|
||||
run: npm run build
|
||||
```
|
||||
|
||||
### 2. 自動デプロイ（CD）
|
||||
```yaml
|
||||
# .github/workflows/deploy.yml
|
||||
name: Deploy
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ main ]
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20'
|
||||
|
||||
- name: Install and Build
|
||||
run: |
|
||||
npm ci
|
||||
npm run build
|
||||
|
||||
- name: Deploy to GitHub Pages
|
||||
uses: peaceiris/actions-gh-pages@v3
|
||||
with:
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
publish_dir: ./dist
|
||||
```
|
||||
|
||||
### 3. 自動Issue管理
|
||||
```yaml
|
||||
# .github/workflows/issue-automation.yml
|
||||
name: Issue Automation
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
types: [opened, closed]
|
||||
|
||||
jobs:
|
||||
update-issue:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Move issue to In Progress
|
||||
if: github.event.action == 'opened'
|
||||
uses: peter-evans/create-or-update-project-card@v2
|
||||
with:
|
||||
project-name: Development
|
||||
column-name: In Progress
|
||||
issue-number: ${{ github.event.pull_request.number }}
|
||||
|
||||
- name: Close linked issues
|
||||
if: github.event.pull_request.merged == true
|
||||
uses: peter-evans/close-issue@v2
|
||||
with:
|
||||
issue-number: ${{ github.event.pull_request.number }}
|
||||
comment: Completed in PR #${{ github.event.pull_request.number }}
|
||||
```
|
||||
|
||||
### 4. 依存関係の自動更新
|
||||
```yaml
|
||||
# .github/dependabot.yml
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
open-pull-requests-limit: 10
|
||||
labels:
|
||||
- "dependencies"
|
||||
- "automated"
|
||||
```
|
||||
|
||||
## worktreeワークフローとの統合
|
||||
|
||||
1. **feature/**ブランチへのpush** → CI実行
|
||||
2. **PRの作成** → テスト実行 + Issueステータス更新
|
||||
3. **developへのマージ** → ステージング環境へのデプロイ
|
||||
4. **mainへのマージ** → 本番環境へのデプロイ
|
||||
|
||||
# Alternative: Jujutsu (jj) を使った革新的アプローチ
|
||||
|
||||
## 概要
|
||||
Jujutsuは「ワーキングコピーは常にコミット」という革新的な思想のVCSです。GitHubとの完全互換性を保ちながら、ローカル開発体験を劇的に改善します。
|
||||
|
||||
## 主な特徴
|
||||
|
||||
### 1. ステージングエリアが不要
|
||||
```bash
|
||||
# Gitの場合
|
||||
git add file.js
|
||||
git commit -m "feat: 新機能追加"
|
||||
|
||||
# jjの場合（ファイルを保存した時点で自動的にコミットに含まれる）
|
||||
jj describe -m "feat: 新機能追加"
|
||||
```
|
||||
|
||||
### 2. git stashが不要
|
||||
```bash
|
||||
# 別の作業を始めたい時
|
||||
# Gitの場合
|
||||
git stash
|
||||
git checkout -b other-feature
|
||||
|
||||
# jjの場合（現在の作業は自動的に保存される）
|
||||
jj new -m "feat: 別の機能"
|
||||
```
|
||||
|
||||
### 3. 直感的な履歴編集
|
||||
```bash
|
||||
# 過去のコミットを修正
|
||||
jj edit <change-id>
|
||||
# ファイルを修正
|
||||
jj edit @ # 最新に戻る（間のコミットは自動リベース）
|
||||
```
|
||||
|
||||
### 4. 強力なundo
|
||||
```bash
|
||||
# どんな操作も一発で取り消し
|
||||
jj undo
|
||||
```
|
||||
|
||||
## GitHubワークフローとの統合
|
||||
|
||||
```bash
|
||||
# 1. 既存のGitリポジトリでjjを使用開始
|
||||
cd my-project
|
||||
jj git init --colocate
|
||||
|
||||
# 2. 新機能の開発
|
||||
jj new -m "feat: ユーザー認証機能 #40"
|
||||
# コーディング...
|
||||
|
||||
# 3. コミットの分割（必要に応じて）
|
||||
jj split
|
||||
|
||||
# 4. GitHubにプッシュ
|
||||
jj bookmark create feature/40-auth
|
||||
jj git push --bookmark feature/40-auth
|
||||
|
||||
# 5. GitHub上でPR作成（通常通り）
|
||||
```
|
||||
|
||||
## worktreeとjjの使い分け
|
||||
|
||||
| 状況 | worktree | jj |
|
||||
|-----|----------|-----|
|
||||
| チーム開発 | ◎（Gitの知識で十分） | △（チーム全体の学習が必要） |
|
||||
| 個人開発 | ○（並行作業に最適） | ◎（最高の開発体験） |
|
||||
| 複雑な履歴操作 | △（rebaseが面倒） | ◎（直感的） |
|
||||
| GitHub統合 | ◎（完全にGit） | ○（変換が必要） |
|
||||
|
||||
## まとめ
|
||||
|
||||
現在のworktreeベースのワークフローは十分に効率的ですが、以下の追加により更に強化されます：
|
||||
|
||||
1. **Conventional Commits**: 履歴の可読性と自動化
|
||||
2. **GitHub Copilot**: AI支援による高速開発
|
||||
3. **GitHub Actions**: 完全自動化されたCI/CD
|
||||
4. **Jujutsu（オプション）**: 究極のローカル開発体験
|
||||
|
||||
これらを段階的に導入することで、個人開発の生産性を最大化できます。
|
||||
|
||||
# 新規開発ワークフロー 詳細設計書（jj版）
|
||||
|
||||
## 概要
|
||||
Jujutsu（jj）を使用した新規開発ワークフローです。「ワーキングコピーは常にコミット」という革新的な思想により、git stashやステージングエリアの概念から解放され、よりシンプルで直感的な開発体験を実現します。
|
||||
|
||||
## 1. 計画フェーズ：思考を外部化し、道筋を立てる
|
||||
|
||||
### 概要
|
||||
基本的にはGit版と同じです。GitHubのIssueとProjectsを使ってタスクを管理します。
|
||||
|
||||
### 流れ
|
||||
|
||||
1. **リポジトリの作成**: GitHub上でリポジトリを作成し、ローカルにクローン
|
||||
|
||||
2. **jjの初期化**:
|
||||
```bash
|
||||
# Gitリポジトリでjjを使用開始
|
||||
cd my-project
|
||||
jj git init --colocate
|
||||
```
|
||||
|
||||
3. **ブランチ戦略**:
|
||||
- jjでは「ブランチ」の概念が薄く、「変更（change）」が中心
|
||||
- GitHubとの互換性のため、mainとdevelopの概念は維持
|
||||
- ただし、ローカルではブックマークとして管理
|
||||
|
||||
4. **仕様書の作成**: README.mdに記載（Git版と同じ）
|
||||
|
||||
5. **全タスクのIssue化**: GitHub上で管理（Git版と同じ）
|
||||
|
||||
## 2. 開発フェーズ：摩擦のない開発体験
|
||||
|
||||
### 概要
|
||||
jjの真価が発揮されるフェーズです。ステージングやstashを意識することなく、自然な流れで開発を進められます。
|
||||
|
||||
### 流れ
|
||||
|
||||
1. **Issueの選択**: GitHub Projectsから取り組むIssueを選択
|
||||
|
||||
2. **新しい変更の開始**:
|
||||
```bash
|
||||
# mainの最新から新しい変更を開始
|
||||
jj new main -m "feat: ログイン機能を実装 #11"
|
||||
```
|
||||
- ブランチ名を考える必要なし
|
||||
- 即座に作業開始可能
|
||||
|
||||
3. **開発の進行**:
|
||||
```bash
|
||||
# ファイルを編集すると自動的に現在の変更に含まれる
|
||||
# エディタでlogin.jsを編集
|
||||
|
||||
# 現在の差分を確認
|
||||
jj diff
|
||||
|
||||
# 変更の説明を更新（git commit --amendに相当）
|
||||
jj describe -m "feat: ログインフォームのUIを追加 #11"
|
||||
```
|
||||
|
||||
4. **作業の中断と再開**（jjの最大の利点）:
|
||||
```bash
|
||||
# 急にバグ修正が必要になった場合
|
||||
# 現在の作業は自動的に保存されているので、単に新しい変更を開始
|
||||
jj new main -m "fix: 認証エラーの修正 #12"
|
||||
|
||||
# バグ修正...
|
||||
|
||||
# ログイン機能に戻りたい時
|
||||
jj edit <ログイン機能のchange-id>
|
||||
# または、jj logで履歴を見て選択
|
||||
```
|
||||
|
||||
5. **コミットの整理**:
|
||||
```bash
|
||||
# 大きすぎる変更を分割
|
||||
jj split
|
||||
|
||||
# 複数の変更を1つに統合
|
||||
jj squash
|
||||
|
||||
# 過去の変更を修正（超簡単！）
|
||||
jj edit <過去のchange-id>
|
||||
# ファイルを修正
|
||||
jj edit @ # 最新に戻る（自動リベース）
|
||||
```
|
||||
|
||||
6. **GitHubへの共有準備**:
|
||||
```bash
|
||||
# GitHub用のブックマーク（ブランチ）を作成
|
||||
jj bookmark create feature/11-login
|
||||
|
||||
# リモートにプッシュ
|
||||
jj git push --bookmark feature/11-login
|
||||
```
|
||||
|
||||
## 3. レビュー＆統合フェーズ
|
||||
|
||||
### 概要
|
||||
GitHub上でのプロセスは従来と同じですが、レビューフィードバックへの対応がjjでは格段に簡単になります。
|
||||
|
||||
### 流れ
|
||||
|
||||
1. **Pull Request作成**: GitHub上で通常通りPRを作成
|
||||
|
||||
2. **自動テスト**: GitHub Actionsが実行（Git版と同じ）
|
||||
|
||||
3. **フィードバック対応**（jjの利点）:
|
||||
```bash
|
||||
# レビューで「3つ前のコミットのタイポ」を指摘された場合
|
||||
|
||||
# 該当のコミットに直接ジャンプ
|
||||
jj edit <3つ前のchange-id>
|
||||
|
||||
# タイポを修正
|
||||
|
||||
# 最新に戻る（間のコミットは自動的にリベース！）
|
||||
jj edit @
|
||||
|
||||
# 更新をプッシュ（自動的にforce-push）
|
||||
jj git push --bookmark feature/11-login
|
||||
```
|
||||
|
||||
4. **マージ**: GitHub上でPRをマージ
|
||||
|
||||
5. **後片付け**:
|
||||
```bash
|
||||
# ローカルの状態を更新
|
||||
jj git fetch
|
||||
|
||||
# 不要になったブックマークを削除
|
||||
jj bookmark delete feature/11-login
|
||||
|
||||
# mainを最新に
|
||||
jj new main
|
||||
```
|
||||
|
||||
## jj特有の便利な操作
|
||||
|
||||
### 1. 実験的な変更
|
||||
```bash
|
||||
# 実験的なアプローチを試したい
|
||||
jj new -m "実験: 新しいアルゴリズム"
|
||||
|
||||
# うまくいかなかった場合
|
||||
jj abandon @ # この変更を破棄
|
||||
# 自動的に前の変更に戻る
|
||||
```
|
||||
|
||||
### 2. 並行作業の可視化
|
||||
```bash
|
||||
# 現在進行中の全ての作業を確認
|
||||
jj log
|
||||
|
||||
# グラフィカルに表示
|
||||
jj log --graph
|
||||
```
|
||||
|
||||
### 3. 究極のセーフティネット
|
||||
```bash
|
||||
# どんな操作もやり直し可能
|
||||
jj undo # 直前の操作を取り消し
|
||||
jj op log # 操作履歴を確認
|
||||
jj op restore <operation-id> # 特定の時点に戻る
|
||||
```
|
||||
|
||||
## worktreeワークフローとの比較
|
||||
|
||||
| 観点 | worktree | jj |
|
||||
|------|----------|-----|
|
||||
| 作業の切り替え | 物理的にフォルダを移動 | 論理的に変更を切り替え |
|
||||
| 並行作業の管理 | 複数のフォルダ | 1つのフォルダ内で完結 |
|
||||
| 学習コスト | Gitの延長線上 | 新しい概念の理解が必要 |
|
||||
| ディスク使用量 | 作業数×リポジトリサイズ | 1リポジトリ分のみ |
|
||||
| 作業の可視性 | lsコマンドで確認 | jj logで確認 |
|
||||
|
||||
## まとめ
|
||||
|
||||
jjを使った新規開発ワークフローの特徴：
|
||||
|
||||
1. **ブランチ管理からの解放**: ブランチ名を考える必要なし
|
||||
2. **stash不要**: 作業の中断・再開が自然
|
||||
3. **履歴編集が簡単**: 過去のコミット修正が直感的
|
||||
4. **安全性**: すべての操作がundo可能
|
||||
|
||||
特に個人開発や小規模チームでは、jjの「摩擦のない」開発体験により、創造的な作業により集中できるようになります。
|
||||
1
leaked-system-prompts
Submodule
1
leaked-system-prompts
Submodule
|
|
@ -0,0 +1 @@
|
|||
Subproject commit d03ab51b39bab41443da50f988141d5a00382609
|
||||
251
worktree-vs-jj-comparison.md
Normal file
251
worktree-vs-jj-comparison.md
Normal file
|
|
@ -0,0 +1,251 @@
|
|||
# Git Worktree vs Jujutsu (jj) 徹底比較
|
||||
|
||||
## はじめに：なぜこの比較が重要なのか
|
||||
|
||||
Git worktreeとJujutsu（jj）は、どちらも**開発者の最大の悩み「作業の切り替えコスト」を解決する**ためのツールです。しかし、アプローチが根本的に異なります。
|
||||
|
||||
- **Git worktree**: Gitの上に構築された「物理的分離」による解決策
|
||||
- **Jujutsu (jj)**: Git自体を置き換える「概念的革新」による解決策
|
||||
|
||||
## 基本概念の違い
|
||||
|
||||
### Git worktree: 物理的分離戦略
|
||||
|
||||
```
|
||||
プロジェクトのディレクトリ構造:
|
||||
../my-project/ # メインの作業場（develop）
|
||||
├── .git/ # 共通のGitデータ
|
||||
├── src/
|
||||
└── package.json
|
||||
|
||||
../feature-login/ # ログイン機能用作業場
|
||||
├── .git → ../my-project/.git # リンク
|
||||
├── src/
|
||||
└── package.json
|
||||
|
||||
../bugfix-urgent/ # 緊急バグ修正用作業場
|
||||
├── .git → ../my-project/.git # リンク
|
||||
├── src/
|
||||
└── package.json
|
||||
```
|
||||
|
||||
**特徴**:
|
||||
- 各作業場は**物理的に独立したフォルダ**
|
||||
- 同じリポジトリの異なるブランチを**同時に複数の場所で**展開
|
||||
- `cd`コマンドで作業場を移動
|
||||
|
||||
### Jujutsu (jj): 概念的革新戦略
|
||||
|
||||
```
|
||||
プロジェクトのディレクトリ構造:
|
||||
my-project/ # 単一の作業場
|
||||
├── .jj/ # jjのメタデータ
|
||||
├── .git/ # Gitとの互換性維持
|
||||
├── src/
|
||||
└── package.json
|
||||
|
||||
変更の概念的管理:
|
||||
change-abc123: feat: ログイン機能
|
||||
change-def456: fix: 緊急バグ修正 ← 現在ここで作業中
|
||||
change-ghi789: feat: UI改善
|
||||
```
|
||||
|
||||
**特徴**:
|
||||
- **単一のフォルダ**ですべてを管理
|
||||
- 「変更（change）」という概念で作業を分離
|
||||
- `jj edit <change-id>`で瞬時に作業を切り替え
|
||||
|
||||
## 具体的な作業フローの比較
|
||||
|
||||
### シナリオ: ログイン機能開発中に緊急バグ修正が発生
|
||||
|
||||
#### Git worktreeの場合
|
||||
|
||||
```bash
|
||||
# 1. ログイン機能を開発中
|
||||
cd ../login-work
|
||||
# コーディング中...（未コミットの変更あり）
|
||||
|
||||
# 2. 緊急バグ修正が必要に！
|
||||
cd ../my-project
|
||||
git worktree add -b hotfix/urgent-bug ../bugfix-work develop
|
||||
cd ../bugfix-work
|
||||
|
||||
# 3. バグ修正
|
||||
# 修正作業...
|
||||
git add .
|
||||
git commit -m "fix: 緊急バグを修正"
|
||||
git push origin hotfix/urgent-bug
|
||||
|
||||
# 4. PR作成してマージ後、クリーンアップ
|
||||
cd ../my-project
|
||||
git worktree remove ../bugfix-work
|
||||
git branch -d hotfix/urgent-bug
|
||||
|
||||
# 5. ログイン機能に戻る
|
||||
cd ../login-work
|
||||
# 以前の作業がそのまま残っている！
|
||||
```
|
||||
|
||||
#### Jujutsu (jj)の場合
|
||||
|
||||
```bash
|
||||
# 1. ログイン機能を開発中
|
||||
# my-project/で作業中...（change-abc123）
|
||||
|
||||
# 2. 緊急バグ修正が必要に！
|
||||
jj new main -m "fix: 緊急バグを修正"
|
||||
# → 瞬時に新しい変更に切り替わり、以前の作業は自動保存
|
||||
|
||||
# 3. バグ修正
|
||||
# 修正作業...（git addは不要、ファイル保存で自動的に変更に含まれる）
|
||||
jj bookmark create hotfix/urgent-bug
|
||||
jj git push --bookmark hotfix/urgent-bug
|
||||
|
||||
# 4. PR作成してマージ後、クリーンアップ
|
||||
jj bookmark delete hotfix/urgent-bug
|
||||
|
||||
# 5. ログイン機能に戻る
|
||||
jj edit change-abc123
|
||||
# → 瞬時に以前の作業に戻る！
|
||||
```
|
||||
|
||||
## 詳細比較表
|
||||
|
||||
| 項目 | Git worktree | Jujutsu (jj) |
|
||||
|------|-------------|--------------|
|
||||
| **基本思想** | 物理的分離による並行作業 | 概念的な変更管理 |
|
||||
| **ディスク使用量** | 作業場数 × リポジトリサイズ | 1リポジトリ分のみ |
|
||||
| **作業切り替え** | `cd ../other-work`（数秒） | `jj edit <id>`（瞬時） |
|
||||
| **未コミット変更** | 各作業場で独立して保持 | 自動的に変更として保存 |
|
||||
| **ステージング** | 各作業場でgit add必要 | 概念自体が存在しない |
|
||||
| **stash** | 不要（物理的分離のため） | 不要（概念的分離のため） |
|
||||
| **学習コスト** | Gitの延長（低） | 新しいVCS（高） |
|
||||
| **チーム対応** | 全員Gitを知っていればOK | 全員がjjを学ぶ必要 |
|
||||
| **IDEサポート** | フォルダ単位で自然に分離 | 同一フォルダ内での変更切り替え |
|
||||
|
||||
## それぞれの利点・欠点
|
||||
|
||||
### Git worktreeの利点
|
||||
1. **学習コストが低い**: 既存のGit知識で十分
|
||||
2. **直感的**: フォルダ = 作業場という分かりやすい概念
|
||||
3. **IDEフレンドリー**: VS Codeなどで複数ウィンドウを開ける
|
||||
4. **チーム互換性**: 他のメンバーは普通のGitブランチとして見える
|
||||
5. **デバッグしやすい**: どのフォルダで何をしているか一目瞭然
|
||||
|
||||
### Git worktreeの欠点
|
||||
1. **ディスク容量**: 大きなリポジトリだと容量を食う
|
||||
2. **パスの管理**: 複数のパスを覚えておく必要
|
||||
3. **クリーンアップ**: 作業完了後の削除作業が手間
|
||||
4. **ファイルシステム依存**: Windows等でのパス問題
|
||||
|
||||
### Jujutsu (jj)の利点
|
||||
1. **究極の効率性**: 瞬時の作業切り替え
|
||||
2. **ディスク効率**: 1リポジトリ分の容量のみ
|
||||
3. **自動管理**: ステージング、stash等の概念が不要
|
||||
4. **強力なundo**: あらゆる操作が取り消し可能
|
||||
5. **履歴編集**: 過去のコミット修正が超簡単
|
||||
|
||||
### Jujutsu (jj)の欠点
|
||||
1. **学習コスト**: 全く新しい概念の理解が必要
|
||||
2. **チーム導入障壁**: 全員が新しいツールを覚える必要
|
||||
3. **エコシステム**: Git周辺ツールとの互換性問題の可能性
|
||||
4. **成熟度**: 比較的新しいツールで、長期的な安定性が未知
|
||||
|
||||
## 使い分けの指針
|
||||
|
||||
### Git worktreeを選ぶべき場合
|
||||
- **チーム開発**が中心
|
||||
- **既存のGitワークフロー**に大きな変更を加えたくない
|
||||
- **VS Codeなどのエディタ**で複数ウィンドウを開いて作業したい
|
||||
- **学習コストを最小限**に抑えたい
|
||||
- **Windows環境**でのパス問題が許容範囲
|
||||
|
||||
### Jujutsu (jj)を選ぶべき場合
|
||||
- **個人開発**が中心
|
||||
- **最高の開発体験**を求めている
|
||||
- **頻繁な作業切り替え**が必要
|
||||
- **実験的な開発**を多く行う
|
||||
- **新しいツールを学ぶ意欲**がある
|
||||
|
||||
## 具体的な導入シナリオ
|
||||
|
||||
### シナリオ1: フリーランス開発者（個人開発中心）
|
||||
**推奨**: Jujutsu (jj)
|
||||
- クライアントワークでの頻繁な作業切り替えに最適
|
||||
- 最新技術への投資として価値あり
|
||||
- 個人の生産性向上が直接収入に影響
|
||||
|
||||
### シナリオ2: スタートアップのCTO（小規模チーム）
|
||||
**推奨**: Git worktree
|
||||
- チーム全体での学習コストを考慮
|
||||
- 新しいメンバーの onboarding を重視
|
||||
- 安定性と実績を重視
|
||||
|
||||
### シナリオ3: 大企業のシニア開発者（複雑な開発環境）
|
||||
**推奨**: 状況による
|
||||
- 個人作業が多い → jj
|
||||
- チーム調整が多い → worktree
|
||||
- 実験環境でjjを試してから判断
|
||||
|
||||
## 重要な制約：並列開発の観点
|
||||
|
||||
### Git worktree: 真の並列開発が可能
|
||||
```bash
|
||||
# 3つの機能を本当に「同時に」開発できる
|
||||
Terminal 1: cd ../feature-A && npm run dev # localhost:3000
|
||||
Terminal 2: cd ../feature-B && npm run dev # localhost:3001
|
||||
Terminal 3: cd ../feature-C && npm run dev # localhost:3002
|
||||
|
||||
# 各作業場で独立したサーバーが起動し、ブラウザでタブを切り替えながら開発
|
||||
```
|
||||
|
||||
### Jujutsu: 高速切り替えだが同時実行は不可
|
||||
```bash
|
||||
# 同時には1つしか実行できない
|
||||
jj edit feature-A
|
||||
npm run dev # localhost:3000
|
||||
|
||||
# feature-Bを見たい場合
|
||||
# Ctrl+C でサーバー停止
|
||||
jj edit feature-B
|
||||
npm run dev # 再度起動が必要
|
||||
```
|
||||
|
||||
### 並列開発が必要なケース
|
||||
|
||||
| シナリオ | worktree | jj |
|
||||
|---------|----------|-----|
|
||||
| **複数機能の同時比較** | ◎ 複数ブラウザタブで並べて確認 | ✗ 切り替えが必要 |
|
||||
| **APIサーバー + フロントエンド** | ◎ 別ポートで同時起動 | ✗ 1つずつしか起動できない |
|
||||
| **A/Bテスト開発** | ◎ 2つのバージョンを並行実行 | ✗ 切り替えて確認 |
|
||||
| **性能比較** | ◎ 同時にベンチマーク実行 | ✗ 順番に実行 |
|
||||
| **マイクロサービス開発** | ◎ 複数サービスを同時起動 | ✗ 実質不可能 |
|
||||
|
||||
### 実例：リアルタイム比較が必要な開発
|
||||
|
||||
```bash
|
||||
# Git worktree: UIの新旧比較
|
||||
../current-ui/ # 現在のUI（localhost:3000）
|
||||
../new-ui-design/ # 新しいUIデザイン（localhost:3001）
|
||||
# → ブラウザで2つのタブを開いて、リアルタイムで比較しながら調整
|
||||
|
||||
# jj: 同じことをやろうとすると...
|
||||
jj edit current-ui
|
||||
npm run dev
|
||||
# スクリーンショットを撮る
|
||||
jj edit new-ui-design
|
||||
npm run dev
|
||||
# メモリに頼って比較... 😓
|
||||
```
|
||||
|
||||
## まとめ：どちらも素晴らしいソリューション
|
||||
|
||||
Git worktreeとJujutsu (jj)は、どちらも「作業の切り替えコスト」という共通の問題を解決する優れたツールです。
|
||||
|
||||
- **Git worktree**: 安全で実用的、チーム開発に最適
|
||||
- **Jujutsu**: 革新的で効率的、個人開発に最適
|
||||
|
||||
重要なのは、**あなたの開発環境と目標に最も適したツールを選ぶこと**です。どちらを選んでも、従来の「1ブランチずつ切り替える」ワークフローより大幅に生産性が向上することは間違いありません。
|
||||
|
||||
始めるなら、学習コストの低いGit worktreeから試して、個人開発でより高い効率性を求めるならJujutsuに挑戦する、という段階的なアプローチもおすすめです。
|
||||
Loading…
Add table
Add a link
Reference in a new issue