名前はよく聞くけれど、手を出せていなかった “Git”.
勉強会に参加して、ようやく全貌が見えてきたのでシェアします。

といっても、ハンズオンで手を動かしながらメモったものなので、大変分かりにくくなっております。
分かりやすい記事はまた気が向いた時に書くとして、今回は大して工夫もせず、ログ的なものを公開します。

概要

名古屋駅の “basecamp nagoya” という場所で開催された勉強会に参加してきました。
講師は株式会社アップルップルの Atsushi Ito @atsu666さま。

今日のテーマは Git と呼ばれるバージョン管理システム。
黒い画面（ターミナル）を使うことなく、一連の流れを把握して使えるようにしようという会です。

git（バージョン管理システム）とは

• gitでの作業の流れをつかもう
• 環境を準備しよう
• まずはコミットをしてみよう
• コンフリクトを解消しよう
• ブランチとマージを理解しよう →大規模
• どのように運用するか プラクティス

gitとは

変更履歴の管理システムです。

バージョンごとにバックアップをとれたり、複数人で作業した時に発生するコンフリクト（後述します）を解消したり。一緒にさわってて自分の書いたのが消えてしまう悲しさからさよならできるちゅうことです((((；ﾟДﾟ))))))) やったね！

今日は、CVS, Subversion, github など、いろんなソフトがあるなかで、bitbucket というソフトを使って勉強します。

bitbucketの特徴

特徴の前に、とりあえず１個言葉の解説させてください。
「リポジトリ」＝変更管理を保存するデータベースのこと。
　→サーバーとローカルの両方にリポジトリがある：分散型。オフラインで作業して同期。
　→サーバーにしかリポジトリがない：集中型。オンライン作業。

はい。bitbucketは分散型なので、ローカルにリポジトリの完全複製を持って完全オフラインで作業し、好きな時に同期をとります。あと他のサービスに比べて動作が速いらしい。
また、無料で５ユーザまで利用でき、リポジトリの中身は非公開にできます。

ユーザが多いGithubについても触れておきます。ユーザが多い＝情報源が豊富でコミュニティ活動も活発。ただ、無料アカウントは１ユーザまで、リポジトリの中身は公開になっちゃいます。

bitbucket（分散型）利用の大まかな流れ

ローカルにPull → 変更を保存 → IndexにAdd → コミット → サーバーにプッシュ。

実際に使ってみましょう！

ごめんなさい、こっからが肝心なのに編集間に合わずスカスカですwww
そのうちスクリーンショットとかべたべた貼りますので…

登録してみましょう！

bitbucket で無料アカウント登録 → テストレポジトリを作成
次に、クライアントソフト SourceTree を導入。アカウントを作成。

bitbucket に戻り、左上の「＋」→ 「クローン」内「ソースパス/URL → 右端の “Hosted Repositories”」 → 「アカウントを編集 / Edit Accounts」で良きに計らう → サーバーリポジトリのクローンができました( ´ ▽ ` )ﾉ

コミットしてみよう！

とりあえず適当にHTMLファイルを作って、ローカルレポジトリん中に放り込みます。
そしたらSourceTreeを開いて、addを使ってインデックスに「追加」します。
インデックスに追加されたものを選択して「コミット」します。
これでローカルレポジトリにバージョンが保存されました。

その次はサーバーレポジトリに「プッシュ」します。
これでサーバーレポジトリにバージョンが保存されました。

まとめ：基本の流れ

変更して、addして、commitする
ローカルからリモートへプッシュする。

コンフリクトを解消しよう

コンフリクトが起こるとプッシュ時に通知してくれる
→プルする
→ファイルの中にコンフリクト内容があるので修正
→再プッシュ（解消しましたコメントがつく）

ブランチとマージを理解しよう

ブランチの利用
ブランチを切ってバグフィックスや機能を追加して本体に追加

マージ
ブランチとブランチの差分を合体
コンフリクトが発生する可能性あり。
つまりレベル高い。

Fast-Forward マージ
マスターには手を加えず、ブランチの最終コミットをそのままもってくる。
元ブランチに変更がない場合。マージコミットが作成されない。きれいな履歴を保つ。マージコミットを作る場合は –no-ff オプション

リベース（重要！）

コンフリクトの解決の責任
　リベースせずにマージ
　　元ブランチ（マスター）の責任になる
　リベース後にマージ
　　修正ブランチの責任になる

ブランチの運用

feature branch フューチャーブランチ
例） feature/sns-login-support
新しい機能の追加時にブランチを切る。
開発ブランチから派生。
リベースしてマージできる形に。開発終了後開発ブランチにマージ

トピックブランチ
bug/ topic/ issue branch
例）
バグフィックスなど。いろんなブランチ元がある。
リベースしてマージできる形に。開発終了後開発ブランチにマージ

開発ブランチ
develop branch
例）
日々開発中の最新のブランチ
ここからfeatureブランチなどが派生、新機能を追加していく
時期リリース準備がある程度整ったら安定ブランチにマージ

安定ブランチにマージ
master, release/16x
例）
リリースに向けた作業。大きな変更は行わない。
バージョン情報をタグとして追加していく

最後に！

いちいち変更してコミット…めんどくさいので
　長期的に保守が必要なもの
　複数人でのプロジェクト
におすすめ。

ALMunium, readmine, backlogのようなプロジェクト管理ツールと組み合わせるとよい。

※コンフリクトの解消まで覚えれば、全員がそれ以上理解する必要はないそうです。ひと安心ですね。

おまけ

ツールやサービスをご紹介くださいました。
※これは各々で違ってもOK

Git Gui win/,mac
入門

github for mac
直感的。でも裏で何が行われているかわからない…

SourceTree win/mac
おすすめ。

Tower mac
おすすめ。ただし有料。

bitbucket, backlog, redmine
組み合わせてプロジェクトを進めるのに便利。上級。

質疑応答でも勉強は続きました…

基本的にマスターにはコミットしない。
マージが集まってくるもの。

Pullは基本的にコンフリクトが発生する！！！
「マージの代わりにリベース」にチェック

Githubの良さ…ユーザが多くてコミュニティが活発なことすかね？笑
subversion…分散型じゃない（ローカルリポジトリがない）

…はふぅ。