GitHub Issues と Pull request を使って疑似チーム開発を行う
私が個人でポートフォリオを作成していて、疑似チーム開発に慣れといた方がいいと思って開発の後半から導入。
※自分ためのメモ用と、まだやり方がわからない向け。
流れとしては、
Issues作成 → ローカルで作業用branch作成 → 作業をcommit → リモートにpush → Pull request作成 → main(master)ブランチにmerge
Issues作成
- New Issuesをクリック。
- タイトルとコメントを記入。
- タイトルは課題の内容(〜の機能が欲しい、〜という問題がある)を端的に表現して、コメントの部分で仕様やバグの再現手順などを詳細に書いていく。
- [Submit new Issue]をクリックしてIssues作成。
ローカル環境で作業用branchを作成
-
git branchで現在のBranch確認。 -
git checkout -b feature/作業名(ブランチ名)#issue番号で作業ブランチ作成。- checkout -b ブランチ名 とする事で、新ブランチの作成とブランチの変更を同時に行ってくれる。
-
git branchでブランチが作成・変更されたか確認 -
git push origin HEADでリモートにpush- これによってチームがいたと仮定した場合、みんなが作業の開始を把握できる。
- git push origin HEAD で現在のbranchにpushできる。
作業をadd、commit
- Issuesにある作業をローカル環境で変更したら、
git statusで変更ファイルを確認。 -
git diffで差分を確認し、git add ファイル名。-
git add .で全ての変更をaddできる。
-
-
git commit -m "コミットメッセージ"でコミット。- 1機能ごとにコミットするといったように、コミットの間隔を狭めて変更点をわかりやすくする。
- コミットメッセージも、メッセージから変更内容がわかるようにわかりやすく書く。
リモートにpush
-
git push origin HEAD。
Pull request作成
- GitHubで自分のリポジトリのページへいき、上に出ている緑色の[Compare & pull request]をクリック。
- 修正点を一言で表すようなタイトルを付け、実装内容や補足をコメント欄に書いて、[Create pull Request]をクリック。
- コメント欄の最後に
close #issue番号と記載する事で、mergeされた時、自動的にその番号のissueがcloseする。 - 緑色の[Merge pull request]をクリックし、[Confirm merge]をクリックで完了。
最後に
githubまだまだ私も勉強中ですが、一緒に頑張りましょう。
参考
チーム開発を変える「GitHub」とは？〜Pull Requestの使い方〜【連載第2回】
チーム開発を変える「GitHub」とは？〜Issuesの使い方〜【連載第3回】