WindowsへGitとSourceTreeのインストール＆セットアップ

STINGERテンプレートへの独自の修正が多くなってしまったので、変更箇所の目的とソース差分をセットで管理しないと、すぐに大変なことになりそうだったため、ソースを管理するツールの導入が必要になりました。

どのような方法で管理しようか考えた結果、Windowsマシン上にてGitとSourceTreeを使うことに決めました。
しばらく使ってみて支障がないぐらいになったので、STINGERへの修正を行う事ができるまでの、その導入部分についてまとめたいと思います。

Information

• SourceTreeをしばらく使ってみましたが、どうしても納得の行かない動作をする箇所がありました。詳細はこちらの記事にまとめました。
• また後日、代替ツールとしてSmartGitを導入することにしました。詳細はこちらの記事にまとめました。

実現するブランチモデル

バージョン管理システムを使ってソースコードを管理するのですが、はじめにブランチモデルのベストプラクティス(以降、Git-Flow)について、以下のサイトで勉強しました。
Git ワークフローだからGit-Flowっていう単語なんだと思いますが、正確な用語の出典元は見つけられず・・・。

• A successful Git branching model を翻訳しました
• A successful Git branching model
• git-flow cheatsheet
• Git チュートリアル – Git ワークフロー

ここで紹介されているGit-Flowは、以前この記事(GitHub実践入門)で読んでみた書籍でも紹介されていましたが、結構有名で昔からある考えなのだそうです。
古くから使い込まれているという意味では、採用する価値が十分あると思いますので、今回はこのGit-Flowに従った構成で管理していきたいと思います。

前提

やりたいことは、難しい設定を使わない簡易的なソース管理環境とします。
そのため、Gitであれば分散リポジトリもやってみたい気もしますが、リモートへのクローン機能は使わず、リポジトリも簡易的に管理します。

• ローカルリポジトリのみ
• ソースコードへのアクセスは一人だけ

Gitのインストール

まずはバージョン管理システムについて。
Gitは、最近人気があるという点と、次にセットアップするSourceTreeを使っておきたかったという点から、採用しました。

SourceTreeのセットアップにてわかったのですが、実はSourceTreeだけでもGitを内蔵していることがわかりました。
よって、このセクションを飛ばして、SourceTreeのインストールからやっても問題ないでしょう。

Windows版のインストーラは以下より取得します。

1. http://msysgit.github.io/
2. [Download]リンク
   ※今回入手したインストーラは、Git-1.9.4-preview20140815.exe

インストーラでは色々と質問されますが、普段SourceTreeで作業するので、お好みで良いと思います。
なお、インストーラは管理者として実行しないとよくわからないエラーになるのでご注意。

インストール後、コマンドラインでGitコマンドが使用できることが確認できれば、とりあえず完了となります。

 SourceTreeのインストール

続いてSourceTreeですが、Windows版インストーラは以下より取得します。

https://www.atlassian.com/ja/software/sourcetree/overview

こちらは特に意識すべきことはないインストーラでした。

SourceTreeのセットアップ

インストール後SourceTreeを起動して、セットアップします。

まずは必須であるユーザ情報を登録。
ユーザ情報は名前とメールアドレス、これがないとコミット時にエラーになります。
「ツール -> オプション」で開くオプションダイアログより設定できます。

• 「全般」タブ
  デフォルトユーザー情報の、「フルネーム」「Eメールアドレス」

STINGER管理用のリポジトリ作成

ソースを管理するためのディレクトリに対してGit用の初期化をします。
概ね以下の様に操作します。

1. Windowsにて、新規ディレクトリを作成する
2. 「新規/クローンを作成する」ボタンを押すと開くダイアログより、
   「リポジトリを作成」タブの「保存先のパス」へ先程作成したディレクトリを指定して、「作成」ボタン

この状態でリポジトリの準備は整っていて大元のmasterブランチができているかと思います。
あとは、次のように日々の作業をこなしていけばよいでしょう。

Git-Flowの設定

SourceTreeにはGit-Flowに準拠した運用に縛る機能が提供されてました。
この設定は簡単で「Git Flow」ボタンを押してブランチ名の規則を確認したらOKボタンを押して完了です。

あとは、以下に示す操作契機で「Git Flow」側の操作ボタンを使っていればGit-Flowに従ったブランチモデルができる模様です。

• 新規フィーチャーを開始
  フィーチャーブランチの作成
• 新規リリースを開始
  リリースブランチの作成
• 新規ホットフィックスを開始
  ホットフィックスブランチの作成
• 他の操作 – フィーチャーブランチを完了
  フィーチャーブランチの成果をdevelopにマージ、このフィーチャーブランチを削除
• 他の操作 – リリースを完了
  リリースブランチの成果をmasterにマージ、masterにタグをつける、このリリースブランチを削除
• 他の操作 – ホットフィックスを完了
  ホットフィックスブランチの成果をmasterにマージ、masterにタグをつける、このホットフィックスブランチを削除

SourceTreeに対する個人的なカスタマイズ

必須ではないものの個人的に、SourceTreeに対して以下の設定をしています。

• 「全般」タブ
  コミットメッセージに等幅フォントを使う　[オン]
• 「Diff」タブ
  フォントを変更　[MS Gothic 10.5pt]
• 「Git」タブ
  マージ時にファストフォワードせず、常に新規コミットを作成する　[オン]　※

※これは樹形図にマージ元での修正とわかる履歴を残すための設定です。
Git-Flow機能のみで運用していれば不要ですが、個別にマージが発生するときのために設定しておきます。

SourceTreeでの操作をしてみて気になったところ

ある程度テスト用ブランチにて動作確認が取れたら本番を開始できるかと思います。
今のところ、ここまで出来たら他考えないといけないことはなさそうな感じです。

すべての機能を使ってない段階ですが、気になったポイント。

• 樹形図がわかりやすくて綺麗！
  確かSubversionは、ブランチした時にはブランチ元から先へ線がつながっているけど、マージについては図示してくれなかったと思います。
  その点マージ線もきちんと描かれているのでとても見やすい。
• feature/xxxというブランチ名のxxxに与えた意味以外にブランチの目的を書く場所がない
  結局フィーチャーブランチは完了時に削除するので、コミットメッセージにつけた説明がすべて、そっちを見るという運用なのでしょう。
  またdevelopへのマージの際、「Merge branch ‘feature/xxx’ into develop」という記録が出るので、見るべき情報はこの時のコメントを照らし合わせるというイメージ。
• ブランチはアルファベット順になるので、しばらく放置するブランチがあるなど同時進行で複数フィーチャーを開発する場合は、面倒だけどfeature/日付-xxxで統一したほうが見やすい気がします。