どうも、Kohei(@koheinishino_)です。
エンジニアの御用達のGitですがポートフォリオ作成や個人開発などチームメンバーがいない場合、どのように運用していけばよいか迷うかと思います。
そこで今回は現役エンジニアの私が個人開発時に定めているGitの運用ルールについて解説していきます。
この記事を読むことで、ポートフォリオ作成や個人開発などの際にGitの運用ルールが定まってブランチの切り方が統一されたり、適切なタイミングでコミットやプッシュを実施したりすることができます。
Gitの使い方は何となくわかったけど、どのように運用していけばいいかわからない…。
Gitのオススメの運用方法を知りたい！
とお悩みの方はぜひ最後までご覧ください。
今回の記事作成にあたり、下記のサイトを参考にさせていただきました。
個人開発時のGitの使い方
有名な使い方として「git-flow」や「GitHub Flow」がありますが、どちらかというと「GitHub Flow」に近い使い方になります。
全体の流れは下記です。
事前にGitHub上にリモートリポジトリが作成済みで、既に最新のソースがローカルにプルされていることが前提となります。
- GitHubにてタスクごとにIssueを作成する
- ローカル環境にてIssueに対応する名前でブランチを切る
- 作業終了後、コミット前に変更したファイルと差分を確認する
- 問題がなければコミットしてリモートブランチにプッシュする
- 自分に向けてプルリクエストを作成する
- 内容を確認後マージする
- マージ完了後、ローカル環境にてmainブランチをプルしておく
順番に解説していきます。
GitHubにてタスクごとにIssueを作成する
まず、該当のGitHubリポジトリでIssueを作成します。例えば、「Usersテーブルにnameカラムを追加」などです。
Issueを作成することで、それがそのままTodoリストになるので便利です。
以降も、「Usersテーブルにnameカラムを追加」というタスクを実施する例で話を進めていきますね。
ローカル環境にてIssueに対応する名前でブランチを作成
ローカル環境にて先程作成したIssueに対応する名前でブランチを作成します。日本語で作成すると文字コードの関係でエラーの原因にもなるため、英数字+記号でブランチを作成するのが無難です。
命名規則も統一しておいたほうが良いので、キャメルケースで記述します。このへんはお好みで。
また、現場にもよりますが改修時は「feature/」というプレフィックス付きでブランチを作成することもあるので、ここでも採用します。
というわけで、ローカルで下記のコマンドを実行してブランチを作成します。「-m（–move）」オプションによって、ブランチの作成と同時にそのブランチに移動します。
$ git branch -m feature/add_name_column
作業終了後、コミット前に変更したファイルと差分を確認する
上記が完了した後は作業に取り掛かり、完了後は下記のコマンドを実行して変更されているファイルの一覧を確認します。変更する予定のないファイルが紛れ込んでいたら、この段階で変更を取り消しておきます。
$ git status
また、変更の内容をファイルごとに確認する場合は下記のコマンドを実行します。
$ git diff ファイル名
問題がなければコミットしてリモートブランチにプッシュする
コミットする内容を確認後、下記コマンドですべてのファイルをステージングエリアに追加します。
$ git add -A
その後、下記コマンドでコミットを実行します。
$ git commit
「-m（–message）」オプションをつけてそのままコミットメッセージを書いてもいいのですが、私の場合は割と長々書くのでオプションをつけずにエディタを開きます。
コミットメッセージの書き方については下記の記事で解説していますので、こちらの記事も確認してみてください。
そして、下記コマンドでリモートリポジトリにプッシュします。
$ git push origin HEAD
ブランチ名ではなくHEAD（現在の作業場所を示すポインタ）とすることで、ブランチ名を指定しなくてもカレントブランチをリモートブランチにプッシュできます。
自分に向けてプルリクエストを作成する
プッシュした後はGitHubの該当リポジトリを開き、プッシュしたブランチからプルリクエストを作成します。
現場ではプルリクエスト用のテンプレートが存在することもありますが、特にレビュワーがいない場合は自由に記載します。
私の場合、「close #Issue番号」と記載してプルリクエストを作成します。
例えば「close #1」とすることで、プルリクエストがマージされたときに#1のIssueが自動的にクローズします。数字は最初に作成したIssueの番号を指定します。
内容を確認後マージする
レビュワーが自分一人の場合はそのまま自分でマージすることになります。事前に差分は確認していると思うので、ここでは特に何もせずマージしてしまいます。
マージ後は作業ブランチが必要なくなるので削除します。事前に該当のGitHubリポジトリの「Settings > Options > Merge button」から「Automatically delete head branches」にチェックを入れておくことで、マージされるときに自動的に作業ブランチが削除されます。
マージ完了後、ローカル環境にてmainブランチをプルしておく
GitHub上でマージが完了した後は、ローカル環境で下記のコマンドを実行して、mainブランチに移動します。
$ git checkout main
そして、下記コマンドを実行してmainブランチを更新します。
$ git pull origin main
ローカルの作業ブランチも必要なくなる場合が多いので、下記のコマンドを実行して削除して完了です！
$ git branch -d feature/add_name_column
まとめ：個人開発でもチーム開発を意識しよう
改めて私が使っているGitの運用ルールは下記となります。
- GitHubにてタスクごとにIssueを作成する
- ローカル環境にてIssueに対応する名前でブランチを切る
- 作業終了後、コミット前に変更したファイルと差分を確認する
- 問題がなければコミットしてリモートブランチにプッシュする
- 自分に向けてプルリクエストを作成する
- 内容を確認後マージする
- マージ完了後、ローカル環境にてmainブランチをプルしておく
逆に運用ルールを定めていないとブランチがめちゃくちゃだったり、コミットやプッシュのタイミングが適当だったりと後から自分で見ても理解できないリポジトリになってしまいます。
エンジニア転職の際に企業へのアピール材料としてGitHubを利用されることも多いと思いますので、是非Gitの運用ルールを定めておきましょう！
