入門Git (Chapter7)

git 書評

Chapter 7 ブランチを使った開発

「git checkout -b branch_name」でブランチを作る
% git checkout -b test1
  • これは下記のようにブランチを作ってそれを使用するのと同じ結果になります。
% git branch test1
% git checkout test1
  • ブランチの名前は関数名と同じで目的をわかりやすく！
「git branch」で現在のブランチを確認
  • 下記のような感じで「*」がついているブランチが現在のブランチになります。
% git brach
  master
* test1
ブランチを使って開発してみる
  • なんか編集してコミットする。
% git checkout test1
〜なんか編集する〜
% git commit -a -m 'commit test branch'
  • masterブランチに移動してコミットしてみる。
% git checkout master
〜なんか編集する〜
% git commit -a -m 'commit master branch'
  • test1ブランチでのコミットをマージする。
% git merge test1

# これでもいい
% git pull . test1
ブランチを理解するには
  • 何か操作をする度にgitkでコミットツリーを確認すると理解しやすくなるとありました。
  • 恥ずかしながらgitkを知らなかったので早速使ってみたときは「おぉっ」と思いました。
    • 使ったことない人は是非下記コマンドを実行してみてください。
% gitk --all

後からブランチを作る

  • masterブランチで作業をしていてすでにいくつかコミットをしている状態で、「これブランチ作って作業したほうがよかったんじゃね？」と思ったときの方法です。
  • ちなみにmasterブランチは常に安定した状態にしておくのがいいとは思います。
〜新しいブランチに移したいと思っているコミットが３つされている状態とする〜
# masterブランチにいる状態でブランチを作る
% git branch new-branch
# masterブランチのコミットをワークツリーも含めて3つ前までを取り消す
% git reset --hard master~3
  • これでmasterブランチはきれいになって、変更はnew-branchに記録されています。

コミットしていない変更を退避する「git stash」

  • 例えば新しい機能を「new-feature」というブランチで作業している時に、急に本番でバグが発生してすぐに対応する必要がある場合を考えてみます。「new-feature」ブランチには、まだコミット出来る状況でない変更されたファイルがワークツリーにあるとします。
  • 流れとしてはmasterブランチをもとにバグ対応用のブランチを作って、そこでバグ対応してリリースしたいと思います。
  • というわけで、まずはmasterブランチに戻ってみたいと思います。
% git checkout master
error: Your local changes to the following files would be overwritten by checkout:
	hogehoge.txt
Please, commit your changes or stash them before you can switch branches.
Aborting
  • というようにチェックアウトすることが出来ません。
  • ですので、このメッセージにもあるようにstashして再度masterブランチに戻ってみます。
% git stash
% git checkout master
  • 今度はエラーが出なかったと思います。ですのでブランチ作ってバグ対応してmasterにマージしてpushすることが出来ます。
  • その後、またnew-featureの作業を続きをやりたいときは、new-featureブランチに戻って「git stash pop」してやれば、退避していたコミットしていない変更を復活させることが出来ます。
% git checkout new-feature
% git stash pop

トピックブランチを使ったワークフロー

トピックブランチ
  • トピックブランチによる開発とは、masterブランチは常に安定した状態にしておいて、簡単な変更以外は全てブランチを作って作業してmasterブランチに統合する方法で行う開発のことをいいます。
  • トピックブランチでは１つのテーマ以外の作業はしないようにします。masterに反映されたバグ対応であってもその修正がそのトピックにどうしても必要な場合以外は統合しません。
  • この方法の利点としては変更が管理しやすいことや、gitでは後から複数のコミットを１つにまとめることが出来るので、トピックブランチの作業が終わってmasterに統合する際に、細々したコミットを１つにまとめることでmasterのログをすっきりさせることが出来ます。
  • これはまさにgitの利点だなと思います。
  • masterだけを観察している場合に、急に新機能やバグ対応が不具合のない１つのコミットとして現れるように出来れば成功だとされています。なるほど。
統合ブランチ
  • 統合ブランチとはトピックブランチを作る元であり統合する先になるブランチのことです。
  • 通常はmasterが使用されます。
  • ですが統合ブランチが１つになる必要はなく、新機能を開発しながらリリース版のメンテナンスも行う必要があるときは、新機能を開発しているブランチをmasterに、メンテナンスを行うブランチをmaintとして開発する方法が考えられます。
  • その場合は、バグ対応はmaintブランチから新しいブランチを作って作業しmaintブランチに統合します。そして最終的にmaintブランチをmasterブランチに統合すれば、masterブランチは新機能追加とバグ対応がされた状態となっています。
  • この辺りを理解して柔軟に対応出来るようになれば本当便利だなと思います。

リリースブランチ

  • 統合ブランチを全てのベースとしながら、そこからさらにリリースする環境に応じてリリース用ブランチを作成します。
  • 統合のブランチを持ちながら環境ごとにリリースブランチを持って、共通の変更は統合ブランチから、環境に依存するような変更はそれぞれのリリースブランチからブランチを作成することで複数環境があっても柔軟に対応出来るようになります。
  • その場合に、統合ブランチをリリースブランチに統合することはあっても、リリースブランチを統合ブランチに統合することはないようにします。リリースブランチの変更を統合ブランチに反映したい時は、その変更のトピックブランチを統合ブランチに統合するようにします。

まとめ

  • gitだとブランチをどんどん作って開発していくことになると思うので、この章は本当に勉強になる章でした。
  • トピックブランチを使った開発など、gitを使う意味とか便利さを感じることが出来た章でした。
  • 次は「分散環境とブランチとの関連」です。ちょっと見た感じこの章もとても勉強になりそうな章で楽しみです。