前回の【環境構築・ブランチ運用編】に引き続き、開発・Merge手順について解説していきます。
前回の記事を見ていない方は↓からどうぞ〜
開発を始めたら
こまめにCommitをしよう
こまめにcommitはしておきましょう。
業務で開発を行う場合、ブランチの切り替えの頻度は個人開発の比ではなく増えます（割り込みタスクが入るからですね！😭）
何かを実装しているときにブランチを切り替えようとすると、
error: The following untracked working tree files would be overwritten by checkout:
hoge
Please move or remove them before you switch branches.
Abortingというメッセージが出ることがあります。
編集中のファイルが変更先のブランチでも編集されていてどちらを正とするか分からず切り替えることが出来ないために起きるエラーです。
この場合、2つの方法があります。
- stashを使い一時的に変更を退避させる
- 一時的にcommitを行い、編集を確定させてしまう
です。
stashを使い一時的に変更を退避させる
stashとは一時的にファイルを退避するコマンドです。
git stash -u で新しく追加したファイルまで退避することも出来ます。
欠点としては、stash をしたことを忘れてしまうことです
退避したファイルを戻すのを忘れて開発を行い、あとで実装したことを思い出し、「やっちまった…！」と気付くことが多々。。。
そのため一時的にcommitをするのをオススメしてます。
一時的にcommitを行い、編集を確定させてしまう
一時的にcommitするとブランチに途中までの実装が残ります。
ブランチを切り替えて戻ってきたときに、stash pop で戻す必要がなく編集中の状態に復帰できます。
無駄なコミットを残したくない人でも git commit –amend でコミットを上書きすることも出来ます。
commitを残すメリットとして、git reflog を使い、過去の状態に戻すことも出来ます。
色々とコマンドが出てきて戸惑ってしまったかもしれませんが、ひとつひとつ調べてみましょう！
stashとcommitどちらも退避という役割として使えますが、個人的にcommitをこまめに行うことをオススメします！
開発ブランチが古くなっていないか確認しよう
開発に夢中になっていると、数日、数週間と時間が経ち、「もう新しい機能が入っていて検証にならない…！」なんてことがあります。
運良く実装に支障がなかったとしても「mergeをしようとしたら大量のコンフリクトが…」なんてこともあります。
それを防ぐために開発ブランチがmasterブランチから離されていないか定期的にリモートのmasterブランチを確認しておきましょう。
masterブランチと離されてきたと思ったら、
Rebase運用であれば
git rebase masterMerge運用であれば
git merge masterで最新のmasterの状態を現在のブランチに取り込むことができます。
コミットを綺麗にしよう
開発を行う上でコミットを綺麗にしておくと後ほどの開発の効率が良くなります。
少しの気遣いで自分も仲間もメリットがあるのでコミットを綺麗にすることは常に意識しておくと良いでしょう。
綺麗なコミットを作るために個人的に気をつけていることを3つ紹介します。
- コミットメッセージは「何をどうしたか」を書く
- 不要な変更ファイルを入れない
- コミットは必要最低限にまとめる
コミットメッセージは「何をどうしたか」を書く
開発をしているとコミットメッセージを適当に付けている人がいます（ fix だけなど）
開発を行って「どうしてこんな実装をしたのだろう？」と思った時に使用するコマンドに
git blame [ファイル名]でファイル名の過去の編集履歴を確認することが出来ます。
その時にコミットメッセージを見て、実装者や実装の意図を調べることが出来ます。
その時にコミットメッセージが適当だと正直わかりません。勘弁してください😭
というわけでコミットメッセージはしっかり意味が伝わるように書きましょう。
不要な変更を入れない
不要な変更とはログ出力コードやテストコードなどを指します。
無駄にログを圧迫させたり、不具合の原因にもなります。
改行1つだけの変更をコミットに入れてしまった状態でコードレビューを出す人がいますが、それも良くないです。
前述した git blame で目的の編集履歴を探す時のノイズになるためです。
改行1つでも気を遣うなんて、非効率だと思われてしまいそうですが、次に書くコミットをまとめる作業を行うと不要な変更が簡単に見つかるようになるので、是非参考にしてください。
コミットは必要最低限にまとめる
コミットを必要最低限にまとめるとこれまでの編集をまとめて1つのコミットとすることが出来ます。これで過去に入れたデバッグコマンドを1つの差分の中で探せるようになるため確認がぐっと楽になります。
ただし、これはRebase運用で有効なテクニックです。Merge運用でも可能ですが、masterブランチを定期的にmergeしていると上手くまとめられません。
コミットを纏める方法ですが、2つの方法があります。
- git rebase -i [ブランチ名 or ハッシュ値] → squash
- git reset [ブランチ名 or ハッシュ値] → 再コミット
git rebase -i [ブランチ名 or ハッシュ値] → squash
git rebase に -i オプションを付けると以下の画面に遷移をして、どのようにRebaseするかを設定することが出来ます。
なおデフォルトではvimの操作なのでpickをsに書き換えたら :wq で保存してください
git reset [ブランチ名 or ハッシュ値] → 再コミット
こちらはかなり豪快ですが、git reset でファイルの状態を保ったままブランチの位置を戻し、改めてコミットを行うことでファイルをまとめます。
git rebase のようにコミットを細かくまとめることは出来ませんが、とりあえずコミットをまとめればOKな場合はこちらの方が圧倒的に早いです。
注意点としては、癖で –hard オプションを付けないことです。–hardをした瞬間にファイルの状態も戻るのでコミットをしてない場合は編集中のファイルは全て消えてしまうので…！
ある程度開発が進んだら
コードレビューをお願いしよう
実装が終わった！と思ったらコードレビューをお願いしましょう。
コードレビューに必要なものは
- ブランチ名
- 対応内容（文章で。見られるものがあれば画像があると尚良い。）
- 対応内容の動作確認手順
- 差分確認用コマンド（git diff master ブランチ名）
などがあればレビュアーは嬉しいです。
gitlabなどを使用している場合はMergeリクエストを作るのも良いでしょう。
コードレビューを行う意義は
- 不具合になりそうなコードを指摘してもらえる
- 正しい実装方法を教えてもらえる
- 思わぬ見落としに気付く
- コードへの責任を分散することが出来る
があります。
上の3つは説明が無くともなんとなく納得が行くと思います。
なので、会社で開発を行うときは、特にコードへの責任を分散することが出来るということを意識してほしいです。
どんな仕事でも報連相を大事にしようと言われますが、報連相の目的はアドバイスをもらうことではなく、責任を分散させることです。
コードレビューも、レビュアーが一度確認したという太鼓判があれば問題が起きたときも修正対応がスムーズになります。
コードレビュー ≒ 報連相です。エンジニア初心者は確実に行っておきましょう！
コードを修正しよう
レビューが終わったら、修正を行います。
注意するポイントは、絶対にレビューしてもらった時点のコミットは消さないことです。
コミットをまとめるテクニックに慣れてくるとSquashなどをやりたくなります。
でもぐっとこらえてレビュー時点のコミットを残しましょう。
なぜなら
- 修正によって万が一不具合が発生した場合に、すぐに戻ることが出来る
- 再レビューした時にどこが修正されたかを確認できる
- 自分自身の振り返りになる
といった理由があるからです。
修正が終わったら再度レビューをしてもらいましょう。
Mergeしよう
完全に問題がないと判断されたらMergeをします。
自分で行う場合もあれば、責任者がMergeすることもあります。
その開発チームのルールに従いましょう。
コンフリクトが起きた場合は、解消後のデバッグをしっかり行いましょう
Rebase運用ではMergeでのコンフリクトは100%発生しないのでそういった点でやはりRebase運用はオススメです。
お疲れさまです！これでタスクが1つ完了しました！
さいごに
郷に入りては郷に従え
これまで延々と会社における開発時のGitの使い方を説明してきましたが、自分の周りの一例に過ぎません。
その会社それぞれでGitの使い方にルールがありますので、開発チームでルールを確認して使っていってほしいです。
何でも聞けるのは最初だけ
本当に大事なことです。
エンジニアとして入社をすると、「Gitを触れて当たり前」という雰囲気で質問しにくいことがあります。
でも、雰囲気でGitを使うこと以上に怖いことはありません。
この記事もそういった雰囲気Gitユーザーが少しでも減ればと思い書きました。
質問しにくい空気があれば、信頼できそうな先輩にこっそり聞いてみる価値は十分にあります。
今、あなたがインターンや新卒であれば本当にチャンスです。
今のうちに分からないことはどんどん潰していきましょう！
まとめ
2部作に渡ってお届けした Gitを使う会社で働き始める時に気をつけるポイント は如何でしたでしょうか？
僕もまだまだ若手のエンジニアで注意されることは多いですが、Gitに関しては口酸っぱく指導されてきたので、少しでも参考になれば幸いです。
分からないことやご指摘があれば、Twitterやってるので絡んでいただければと思います！
長文になりましたがここまで読んで頂きありがとうございました！
コメント