git の master ブランチは取り込み専用で、ブランチの作成はほどほどに2018年08月02日 17時26分23秒

git は分散管理の履歴管理システム。それゆえ、使い方や信条などもどうしても多岐に渡ってしまう。両極端な master ブランチ強行派や、変更毎のブランチ作成必須派。master ブランチは触らないが、ほどほどブランチ作成派。単独での利用であれば、一人で好きな様にやって良いが、複数での開発になると、それぞれの流派の得手不得手が出て来る。

まずは、絶対に避けたいのが master を直接変更すること。pull リクエストなどを使いコードリビュー等を行う場合には大概不便な使い方。自分の master ブランチからの pull リクエストが、即座に受け入れられない場合は git pull --rebase の merge の原因になる。他の誰かの変更が、自分の変更よりも先に受け入れられてしまうと、自分のレポジトリでは既にコミットされている変更の前に他人の変更が加わることになる。その為、手元に沢山の merge を溜めることなり、git log に役に経たない情報が増える元になる。

それに比べると一つの変更毎にブランチを作成するのはそんなに悪くない。ブランチを作成して pull リクエストをするので、master には全てが綺麗に git pull --rebase で戻って来る。ただ、何百も変更を行い、ブランチの数も多くなってくると、名前の重複に困ったり、最近作業したブランチ名を忘れてしまったりといった弊害はある。ブランチはもちろん消すことはできるのだが、あれこれ二度手間になる部分も。

結局のところ、最近はほどほどの数のブランチを使い回すやり方に収束してきた。大きめの変更の時は、専用のブランチを作ったりはする。小さな細かい修正などは、幾つかのブランチを git pull --rebase で更新しつつ、使い回している。例えば、簡単な古いコードの削除などは cleanup ブランチでチョコチョコと行う。

pull リクエストの squash merge 等を行うと、また違った問題と解決策が必要になってくる。ただ、個人的には squash merge はあまり好まない。