Git の疑問。トピックブランチで作業中に、master ブランチで重要な変更が加えられた。どうすればよい？
タイトルの疑問がチーム内で発生して、それに対する答えが、なかなかウェブ上で見つけられなかったので、メモしておきます（Git 公式ページの説明のなかで、少し触れられてはいます）
*答え
作業中のトピックブランチにいる状態で
$ git merge master <<
すればよい。
*なぜそのような疑問が生じるのか？
そもそも、なぜそのような疑問が生じるのか？というと、チームでいわゆる GitHub Flow を使って開発していることが関係しているように思われます。
-GitHub Flow (Japanese translation)
つまり、普段行うマージが「作業用ブランチ -> master ブランチ」であるため、その逆方向のマージについては、「え？それってやっていいの？ルール違反じゃないの？」と思ってしまう（というか、僕も以前、思っていました）
現在自分が作業しているブランチにも関係するような、重要な変更が master ブランチに対して行われたときは、その変更内容を取得するために「git merge master」しても良いということをチーム内で確認しておくと良いかもしれません。
*リリース前にコンフリクトを事前に解消しておく
上では、git merge master「しても良い」という書き方をしましたが、積極的に git merge master「すべき」ケースもあります。
というのも、以前、チーム内で Subversion を使っていた時期は、リリース直前に、作業用ブランチを trunk にマージすると、盛大にコンフリクトが発生して死亡、というケースが散見されていました。
そのようなケースに対応するためにも、特に大きめのリリースの場合は、事前に（時にはこまめに）git merge master しておいて、リリース直前のコンフリクトを回避すべきだと思います。
このあたり、下記スライドが参考になります（149 〜 156 ページ。黄色の丸が master ブランチ）
こわくない Git from Kota Saito
*git rebase との違いは？
master の変更内容を取得したいときには、
「git rebase」使った方が、コミットログがキレイになって見やすいのでは？ <<
という疑問もあるかもしれませんが、端的にいうと、既にサーバーへプッシュしている作業用ブランチで「git rebase master」すると、コミット履歴が書き換わってしまうので、以降プッシュできなくなります。
それを無理矢理「git push -f」とかすると、チーム内で溜め息が漏れるのでご注意ください。
このあたりのハナシも前述のスライドがすごく分かりやすく説明してくれているので、git rebase をよく理解できていない人は、確認しておくと良いと思います（リベースの功罪 100 〜 181 ページ）
こわくない Git from Kota Saito
*参考サイト
