marketing-shibata50
5870194f33
- site.title と site.description を追加 - SEO最適化のためのメタタグを強化 - ページの可読性向上を図るための設定調整
173 lines
No EOL
8 KiB
Markdown
173 lines
No EOL
8 KiB
Markdown
越後さんの活用方法
|
||
|
||
mainを軸にするがいじるときはすべてbranchにしてる
|
||
|
||
issueごとにbranchを切って、完了後にmainにmergeする→同時に動かしている場合はどうすればいいのかな？
|
||
ステージング環境・開発環境のbranchも構築しておく
|
||
|
||
main
|
||
↓
|
||
開発環境
|
||
↓
|
||
issueごと
|
||
|
||
ってイメージ
|
||
|
||
PRは開発環境にmergeして確認を行うとのこと
|
||
|
||
|
||
worktree
|
||
→リポジトリと同レベルの階層にworktreeのフォルダが作られるとのこと
|
||
|
||
|
||
|
||
開発の流れを考えたい
|
||
1. 新規
|
||
2. 機能追加
|
||
3. テスト
|
||
|
||
シナリオ1：新規開発（ゼロからプロジェクトを始める）
|
||
これは、新しいアイデアを形にする最初のステップです。
|
||
|
||
計画フェーズ（何をやるか決める）
|
||
|
||
Issueを作成: まず、この新規プロジェクトで達成したいことの全体像を、一つの大きなIssueとして作成します。「ユーザー管理機能を持つブログアプリを作る」などです 。
|
||
|
||
タスクを分解: その大きなIssueの本文に、チェックリスト形式で必要な機能（「ユーザー登録」「記事投稿」「記事一覧表示」など）を書き出します。これが最初のタスクリストになります 。
|
||
|
||
プロジェクトボードに追加: 作成したIssueをGitHub Projectsのカンバンボードに追加し、「Todo」カラムに配置します 。
|
||
|
||
開発フェーズ（コードを書く）
|
||
|
||
リポジトリを作成: GitHub上に新しいリポジトリを作成します。
|
||
|
||
初期開発: この段階ではブランチはmain（またはdevelop）一本で進めることが多いです。まずは基本的な土台（フレームワークの導入、ディレクトリ構成の決定など）を構築します。
|
||
|
||
コミット: ある程度キリの良いところでコミットを重ねていきます。
|
||
|
||
テストフェーズ（品質を保つ仕組みを作る）
|
||
|
||
自動テストを設定: GitHub Actionsを使い、「mainブランチにコードがプッシュされたら、自動でテストを実行する」というワークフローを設定します。これにより、今後の開発で土台が壊れていないかを常にチェックできます。
|
||
|
||
シナリオ2：機能追加（最も一般的な開発サイクル）
|
||
ここからがgit worktreeの真価が発揮される場面です。
|
||
|
||
計画フェーズ
|
||
|
||
Issueを作成: 追加したい機能（例：「記事にコメントを付ける機能」）をIssueとして作成します 。バグの可能性や仕様などを詳細に記述し、
|
||
|
||
featureラベルを付けます。
|
||
|
||
プロジェクトボードで管理: 作成したIssue（#123とします）をGitHub Projectsのカンバンボードの「Todo」カラムに配置します。
|
||
|
||
開発フェーズ
|
||
|
||
作業場を準備 (git worktree): 今、別の作業をしていたとしても問題ありません。stashは不要です。ターミナルで以下のコマンドを実行し、新しい作業場を瞬時に用意します。
|
||
|
||
Bash
|
||
|
||
# feature/comment-function という新しいブランチを作り、
|
||
#../comment-work という新しいフォルダに展開する
|
||
git worktree add -b feature/comment-function../comment-work
|
||
開発に着手: cd../comment-workで新しい作業場に移動し、コーディングに集中します。
|
||
|
||
Issueと連携: コミットメッセージにIssue番号を含めることで、進捗を自動で連携させます 。
|
||
|
||
Bash
|
||
|
||
git commit -m "feat: コメント投稿フォームを作成 #123"
|
||
レビュー＆テストフェーズ
|
||
|
||
プルリクエストを作成: 作業が終わったら、feature/comment-functionブランチをプッシュし、GitHub上でmainブランチへの**プルリクエスト（PR）**を作成します 。PRのタイトルや本文にもIssue番号を記載すると、関連性が一目瞭然になります 。
|
||
|
||
自動テストを実行 (GitHub Actions): PRが作成されると、GitHub Actionsが自動的に起動し、この変更によって既存の機能が壊れていないかをテストします。
|
||
|
||
コードレビュー: 他のメンバー（あるいは未来の自分）がPRを見て、コードに対するフィードバックをコメントします。
|
||
|
||
修正: 指摘があれば、comment-workフォルダで修正し、再度プッシュします。PRは自動で更新されます。
|
||
|
||
マージ＆デプロイ
|
||
|
||
マージ: レビューで承認（Approve）され、すべてのテストが通ったら、PRをマージします。これで新機能がmainブランチに統合されます。
|
||
|
||
後片付け: 不要になった作業場とブランチを片付けます。
|
||
|
||
Bash
|
||
|
||
# まずはメインの作業場に戻る
|
||
cd../my-project
|
||
# 作業場を削除
|
||
git worktree remove../comment-work
|
||
# ブランチを削除
|
||
git branch -d feature/comment-function
|
||
シナリオ3：バグ修正（緊急の割り込み作業）
|
||
git worktreeが最も輝くシナリオの一つです。
|
||
|
||
計画フェーズ
|
||
|
||
Issueを作成: 発見されたバグ（例：「特定の条件下でコメントが投稿できない」）をIssueとして作成します。再現手順などを詳しく書き、bugラベルと高い優先度を設定します。
|
||
|
||
開発フェーズ
|
||
|
||
割り込み作業の開始 (git worktree): あなたが「機能追加」の作業に集中している真っ最中でも、今の作業を一切中断する必要はありません。
|
||
|
||
Bash
|
||
|
||
# hotfix/comment-bug という新しいブランチをmainから作り、
|
||
#../bugfix-work というフォルダに展開する
|
||
git worktree add -b hotfix/comment-bug../bugfix-work main
|
||
修正作業: cd../bugfix-workでバグ修正用の作業場に移動し、迅速に修正を行います。コミットメッセージにはfix:という接頭辞とIssue番号を入れます。
|
||
|
||
Bash
|
||
|
||
git commit -m "fix: コメント投稿時の認証エラーを修正 #124"
|
||
レビュー＆テスト、マージ
|
||
|
||
ここからの流れは「機能追加」とほぼ同じです。PRを作成し、自動テストとレビューを経て、迅速にmainブランチにマージします。
|
||
|
||
まとめ
|
||
シナリオ 計画（どこで？） 開発（どうやって？） レビュー（どうやって？） テスト（いつ？）
|
||
新規開発 GitHub Issueで全体像を定義 mainブランチで土台を構築 不要 mainへのプッシュ時
|
||
機能追加 GitHub Issueでタスク化 git worktreeで独立した作業場を作成 Pull Requestで議論 PR作成・更新時
|
||
バグ修正 GitHub Issueで問題を報告 git worktreeで緊急避難的に作業場を作成 Pull Requestで迅速に確認 PR作成・更新時
|
||
|
||
Google スプレッドシートにエクスポート
|
||
この3つの流れを基本の型として持っておくことで、どんな状況でも迷うことなく、ADHDの特性を活かした柔軟でスピーディーな開発を進めることができるようになります。
|
||
|
||
|
||
|
||
|
||
1. 新規開発
|
||
1. 計画フェーズ
|
||
1. 概要
|
||
1. どんなものを作るのかの仕様書を作ってすべてのタスクをissueを作成する
|
||
2. 流れ
|
||
1. リポジトリを作る
|
||
2. 開発用ブランチを作る
|
||
3. 仕様書を作成する
|
||
4. タスクを一覧化する
|
||
5. issueに記載する
|
||
2. 開発フェーズ
|
||
1. 概要
|
||
1. 計画で決まったissueを進めていき完成させる
|
||
2. 流れ
|
||
1. 開発用ブランチを起点に各issue用のブランチを作る
|
||
2. 各issue用のブランチにcheckoutして開発を進める
|
||
3. 開発完了後に〇〇する→ここがわからない
|
||
4.
|
||
3. テストフェーズ
|
||
1. 概要
|
||
1. 開発完了した後にテストを実行する
|
||
2. 流れ
|
||
1. ここもわからない
|
||
|
||
2. 機能追加
|
||
1. 計画フェーズ
|
||
2. 開発フェーズ
|
||
3. レビュー＆テストフェーズ
|
||
4. マージ＆デプロイ
|
||
|
||
3. バグ修正
|
||
1. 計画フェーズ
|
||
2. 開発フェーズ
|
||
3. レビュー＆テスト・マージ |