（初心者向け）仕事で Git を使う場合の注意点、コツ等

弊社に入社する人は、実務経験豊富な人もいれば、実務経験が無い人もいます。ただ、実務経験が無い人でも、大半は入社前に学校や独学などでプログラムを勉強していてプログラムの知識は十分な事が多いのですが、そうした人達でも意外と Git で躓く事が多いので、今回はそうした人向けに「仕事で Git を使う場合の注意点、コツ等」を教えようと思います。

注意点: main ブランチなどに直接コミットしない

「何を当たり前の事を」と思われた方もいるかもしれませんが、Git の入門者向けの記事では意外にこれを明記しているものは少なかったです。当然、feature ブランチや pull request の説明はあり、feature ブランチを main (or master、以降 main と表記します) にマージするという流れも説明してあるのですが、main ブランチに直接コミットしてはいけないとは書いていないです。

ちなみに、随分前から GitHub の設定で main ブランチに直接コミットをすることを禁止することも出来るのですが、昔からあるレポジトリでその設定をし忘れているものも結構あると思いますので、開発者側でも main への直接コミットは基本的には行ってはいけない、と周知するのは意味があると思います。

コツ: git add -p

Git に不慣れな方が良くやってしまうのが、2つ以上の関係ない修正を1つのコミットにまとめてしまうことです。もちろん、Git 入門者向けの記事では、

• 1つのコミットに複数の修正を入れるのは良くない
• （それと関連して、）1つの PR に複数の機能追加・バグ修正を入れるのは良くない

ということは記載されていますが、実際に開発をしていると、ある部分を直しているうちに、それに関連する部分も直した方が良いことに気づいて直したり、という事がよくあります。

そうした時に使えるのが git add -p です。知らなかった人は試して欲しいのですが、このコマンドを打つことで、修正した内容を実際に add するかどうか1つ1つ聞かれるので、まずは1つの修正に関連する変更点のみを add してコミットし、それ以外は別のコミットにするか別ブランチにコミットするかすると良いです。

コツ: git rebase -i

Git の特徴の一つが、過去の履歴を簡単に書き換えることができるというものです。

feature ブランチを作って進めている時に、1回何かの変更をしてコミットした後に、やっぱりその変更が良くない（あるいは不十分だった、など）事に気づき、そのコミット内容をさらに変更する、あるいは取り消すために別のコミットをする事がよくあります。

もちろんそれをそのままにしておいても良いのですが、git rebase -i を使うと

• 複数のコミットを1つのコミットにまとめる
• 不要なコミットを無かったことにする
• 1つのコミットを分割する

という事が出来ます。GitHub などに push する前であれば、どんどん git rebase -i を使って履歴を綺麗にして、その上で git push すると良いです。

また、Git の運用ルールはプロジェクトによって違いますが、多くのプロジェクトでは push した後だったとしても PR が WIP の状態であれば git rebase -i → git push -f を許容しているように思えます。

コツ: git push -f

前項の最後で何も説明せずに git push -f の事を書きましたが、git push -f は、リモートブランチの過去の履歴を強制的に書き換えることが出来ます。WIP 状態の PR であれば git push -f を許容するプロジェクトが多いというのは先ほど書いたとおりです。実装方針を大きく変えた場合などは、

• 一度ブランチを消して、同じ名前でブランチを作り直して git push -f をする
• あるいは git rebase -i で履歴を書き換えた上で git push -f する

という方が、無駄に PR の残骸が増えなくて分かりやすいと思います。

git push -f を知らない人の場合、WIP PR を作った後で実装方針を大きく変える必要があった場合などに、その PR をクローズし、新たなブランチ・WIP PR を作り直す、という事が多いですが、そういう面倒なことをする必要がなくなります。

補足: –force-with-lease と –force-if-includes

-f は --force の略なのですが、それの親戚に --force-with-lease と --force-if-includes があります。それらが何をするか（もう少し Git に詳しくなってから）公式ドキュメントや解説しているページなどを参照してもらえれば良いと思いますが、簡単に説明すると -f は危険なので、それを緩和するためにそれらのオプションが存在します。基本的には -f の代わりに --force-with-lease を使っておけば問題は無いです。

さらに言うと、上の方で書いたような、自分が開発中の feature ブランチを書き換える目的であれば（他の人がそのブランチにコミットを追加することが無いので）、 -f でも別に問題は無いのですが、 -f の代わりに常に --force-with-lease を使っておいた方が余計なことを考えなくて済むので良いかもしれません。（オプション名が長いので alias を使うと良いと思いますが、alias とは何かは調べてもらえればと思います。）

最後に

Git を仕事であまり使ったことが無い人は、公式のドキュメントや、入門者向けの記事、書籍などで勉強すると共に、上に書いたような事を気をつけてもらうと良いと思います。

The Git logo file is licensed under the Creative Commons Attribution 3.0 Unported license.