チーム開発におけるGit/GitHubの使い方まとめ #初心者脱却
はじめに
これまで、ハッカソンやインターンでGit/GitHubに慣れていない方向けにハンズオンやドキュメントを作成していましたが、せっかくなので記事にしてみました。
対象者
- cloneしてadd~commit~pushをしたことはあるが、チーム開発でのGit/GitHubの使い方がわからない人
- チーム開発におけるGitHubの流れが知りたい人
GitHubの大まかな流れ
- イシューを立てる
- 作業ブランチを切る
- コードを作成・編集してpush
- プルリクエストを投げる
- レビューする/してもらう
- mainブランチにマージ
- 作業ブランチを削除
コマンドや画面操作などの細かい流れ
1. イシューを立てる
「issues」の緑色の「New issue」を押す。
イシューのタイトルや説明を書き、場合に応じてアサインする人やラベル、作成していた場合はProjectsなどを追加します。
最後に右下緑ボタンの「Submit new issue」を押してイシューを立てます。
2. 作業ブランチを切る
ここからローカルのターミナルにうつります。
- まず最初に現在のbranchを確認
git branch
アスタリスクがついている部分が現在のブランチです。
もし作業ブランチにいる場合はmainに移動してください。
git switch main
- mainブランチを最新状態に更新
git pull
- 作業ブランチを作成して移動
git switch -c <作成したいブランチ名>
ブランチ名はfeature/hogeやdevelop/foo/barなどが多い気がします。
詳しくはgit-flowで検索してください。
とはいえ開発中に他人のブランチ名を気にしたことはほとんど無いため、そんなに考えなくてもいい気がします。
3. コードを作成・編集してpush
- 作業ブランチでコードの作成・編集を行う
機能ごとにgit addとgit commit -mの流れを繰り返してください。
その際必ず以下2つのコマンドで状態を確認するようにしてください。
git status
git log
細かいcommitはいずれ人を救うため、もし余裕があればcommitメッセージやcommitの間隔を考えてもいいかもしれません。
とはいえ悩む時間があったら開発に時間を使ってほしいため最初は適当でも大丈夫です。
- pushする前に最新のmainを取り込む
git switch main
git pull
pull後、もしコンフリクトした場合は解消してcommitしてください。
その後、作業ブランチに戻ってください。
git switch -
元いたブランチは-で解釈されます。
もしmainに変更があれば作業ブランチにmergeしてください。
git merge main
- githubのリモートリポジトリにpushする
git push origin HEAD
4. プルリクエストを投げる
ここからGitHubにうつります。
リポジトリのサイトを開き、緑ボタンの「Compare & pull request」を押します。
基本的にはissueと同じですが、プルリクエストでは右のReviewsからレビューしてもらいたい人を設定することができます。
またdescriptionの中でClosesと書いて作成しておいたissueと紐付けをすると、プルリクエストがマージされた場合、自動でイシューもクローズします。
右下の緑ボタン、「Create pull request」を押すと作成が完了します。
5. レビューする/してもらう
レビュワーは「Pull requests」欄からレビューしたいプルリクエストを選択します。
「Files changed」を押し、コードを確認してください。
GitHubの便利機能は以下の記事がわかりやすかったので共有させていただきます。
一番右にある緑色の「Review changes」を開きます。
適当なコメントを書いて「approve」を押します。
もしプルリクエストにコメントだけしたい場合は「Comment」、差し戻したい場合は「Request changes」を押します。
最後に緑の「Submit review」を押して完了です。
6. mainブランチにマージ
approveしてレビューを完了後に出てくる 「Merge pull requet」を押して、
「Confirm merge」を押すことでmainブランチにマージされます。
7. 作業ブランチを削除
最後に「Delete branch」を押してリモートの作業ブランチを削除する。
ターミナルに戻り、mainブランチに移動してリモートの更新をローカルにも反映させます。
git switch main
git pull
pushした人は忘れずにローカルの作業ブランチも消しておきましょう。
git branch -D <作業していたブランチ名>
お役立ち情報
commitコメントの書き方
一目で何をしたのかわかるようにprefixをつけましょう。
- 機能追加
add: - 機能修正
update: - バグ修正
fix: - 削除
remove: - 仕様の変更
change: - 整理(リファクタリングなど)
clean:
例）
git commit -m 'add: ログイン機能を追加'
実装中にブランチを切り替えたい場合
git stashコマンドがオススメです。
以下の記事がわかりやすいのでそのまま貼り付けます。
たまにgit commitしてgit resetで元に戻す派もいるらしいですが、個人的にはstashでいいと思ってます。
リモートのブランチを取得したい場合
プルリクエストのレビューなどで、他者のブランチをローカルに持ってきて動作確認をしたい場合などに、以下のコマンドを実行するとリモートのブランチを取得できます。
git switch -c <リモートブランチ名> origin/<リモートブランチ名>
gitのドットファイルを活用
.gitignore
Gitの追跡対象にしたくないものを.gitignoreファイルに書きます。
はじめてのチーム開発だと.envやキャッシュディレクトリまで追加されていることがあるので注意してください。
ちなみに.gitignoreファイルは複数作成可能です。
.gitkeep
空のディレクトリは追跡対象に入らないため、もし追跡させたい場合はそのディレクトリの中に.gitkeepファイルを作成します。
GitHubの返信テンプレートの設定
GitHubの返信テンプレートを設定しておくと以下のような返信が簡単にできるようになります。
詳しくは以下の記事をご覧ください。
チームリーダーがすべきこと
GitHubにルールを設ける
mainブランチを保護する
mainブランチの直接変更を禁止し、いついかなる時も正しく動作する状態に保ちます。
mainブランチを保護するメリットは主に2つあります。
-
コードの品質を保証することができる
mainブランチに変更を加えるには、レビューが必要になるため、他者目線でコードの品質を保証し、問題を事前に検出することができます。 -
チーム開発の進捗をコードベースで追跡することができる
コードレビューの通知をしておけば、メンバーのどの機能がどの段階にあるかを追跡することができます。
設定方法
リポジトリの「Settings」欄に移動します。
サイドバーの「branches」から「Add branch ruleset」を押します。
「Ruleset Name」に適当なルール名を入力します。
「Enforcement status」をActiveに設定します。
「Targets」の欄でinclude default branchを押します。
その後「Rules」欄のRequire a pull request before mergingにチェックを入れます。
addtional settingsのRequired approvalsは1以上に設定しつつ、他のオプションはチームの意向によって適宜変更してください。
マージ後に自動でリモートブランチを削除する
毎回マージした後にDelete brachで削除するのは面倒なので自動で削除してもらうように設定しましょう。
設定方法
「Settings」欄のサイドバーの「General」に移動します。
「Pull Requests」欄にあるAutomatically delete head branchesにチェックをつけます。
GitHub Projectsを作成
タスク管理ツールは色々ありますが、リポジトリのコードと連携できるGitHub Projectsがオススメです。
以下の記事が取っ掛かりとしてわかりやすいです。
プルリクエストテンプレートを作成する
リポジトリのルートディレクトリに.githubディレクトリを作成します。
mkidr .github
.githubディレクトリ配下にPULL_REQUEST_TEMPLATE.mdという名前のファイルを作成します。
touch .github/PULL_REQUEST_TEMPLATE.md
PULL_REQUEST_TEMPLATE.mdファイルにMarkdown形式でテンプレートを記入してください。その際Closesを入れてissueと紐づけるようにすると便利です。
おわりに
この記事が少しでも参考になりましたら幸いです！
感想
はじめてチーム開発をしたときに書いた記事が以下です。このときに比べると自分もだいぶ成長できた気がします。
Discussion