Gitについて説明する時に使う資料

#はじめに
サル以下な存在にも関わらず、ちょっと社内で説明する場面があるので、まとめておく。（当日もこれ見ながら説明するつもり）
30分以内に喋りきって、質疑応答を少しやって、合計45〜60分くらいのコースを想定した資料。
（実際には使わないんだけど、ざっくり知りたい人に向けた情報。）

#内容
##Git概要
参考：こんなGitの教え方をするエンジニアはデザイナーからモテるぞ！
この図のイメージ はとても分かりやすい！

こんなイメージなんだなーと理解してくれれば良い。

ポイント
SVNはファイル自体をやりとりしている¹。
Gitは差分情報をやりとりしている。

##Gitのメリット
参考：SVNを捨ててGitを使うべき5つの理由

上記を受けて個人的に解釈した結果の簡易な説明

1. ローカルコミット
   • 個人作業の区切りと、サーバーへのアップ（全体影響）を分けることができる。
2. ブランチが簡単に切れる
   • SVNよりも、過去経緯が辿りやすい。（樹形図を見えるようにするツールも豊富）
   • 分岐させやすく、マージしやすい。（分岐元からの差分取り込みが可能）
3. 機能充実(SVNよりも)
   • 細やかなコマンドが多い（教育コストがかかる点はややデメリット）
   • レビューが可能（何をどう修正したかも分かり、指摘箇所も明瞭）
     • わざわざコンペアして差分を色で塗って・・・とかしない。
4. Github
   • いろいろなソースコードがこのGithubで公開されている。
5. 世界標準
   • もうSVNは古いべ。

だから「Gitは良いぞ」という話。
（バイナリファイルの管理は少し苦手なので、原則的にはケースバイケース。でも、ソース管理なら迷わずGitやぞ。）

##A successful Git branching model
参考：【日本語訳】A successful Git branching model
Gitに触れるなら押さえておく必要がある。
ざっくり言えば、だいたいこんな使われ方。

1. メインブランチ
   1. master
      • 製品として出荷可能な状態の資源
   2. develop
      • 開発中の最新版（結合テスト中な感じ）
2. サポートブランチ
   1. feature
      • 機能の開発（開発〜単体テストとか）
      • developから分岐して、developにマージされる。
      • どのタイミングでdevelopにマージさせるかはPJ毎に再定義が必要。
        • 担当PJ（保守ではない）では、単体テスト完了時にマージ。
   2. release
      • リリースための準備作業（設定ファイル内のバージョン情報修正とか）
      • developから分岐して、developとmasterにマージされる。
      • リリース可能な状態になったら分岐させるという曖昧な定義なので、PJ毎に再定義が必要。
        • 担当PJでは、pom.xmlのバージョン情報を更新するためだけのブランチ。
   3. hotfix
      • 本番不具合で急遽直すタイプ
      • masterから分岐して、developとmasterにマージされる。
        • developから分岐させると、開発途中の機能が乗った状態でリリースされてしまうので、masterから分岐させる。

##Gitの使い方
サル以下の存在がまとめた「Git用語」図解
手前味噌な記事ですが。

図を見ながら、実際の流れについて軽く説明するつもり。
→以下の実操作を見せる時は、印刷してホワイトボードに貼って、磁石で説明すればよかった。（2端末操作するので、2枚ほど用意して）

##実操作を見せる1
基本操作
A端末：clone→修正→stage→commit→push

最新化
B端末(clone済み)：fetch→pull
※fetchとpullの違いを理解してもらうため、別々に実施する。

分散型の理解
A端末：修正→stage→commit
B端末：修正→stage→commit→push
※互いに同じファイルを修正して見せる
※後々、コンフリクトするように同一行を修正する

##実操作を見せる2
以下の実操作は、「質問があったら説明する」で良いかも。
いきなり全部説明しても伝わらなかった。。。

マージの理解
B端末：push（上述の「分散型の理解」で済んでいる操作）
A端末：push→エラー→fetch→pull→手動マージ→stage→commit→push
※互いに同じファイルを修正して見せる
※コンフリクトが発生しない場合は、「エラー」以降はしなくてもやってくれる。
※fetchとpullの違いを理解してもらうため、別々に実施する。

ついでにjenkins
jenknisジョブの設定を見せる。
※現状は「SCMをポーリング」＝「定期的に見に行って、差分があれば実行する」

ついでに「破棄」
※これは時間あれば（時間足らず説明できず）
commit後の戻し作業：sourcetreeで右クリック（打ち消すコミットを新規作成する形）
commit前の戻し作業：破棄（stash）

#ツールの違い
非常にざっくり
Git：コマンドラインで使うモノ
Bitbucket：Gitをブラウザで見やすくしてくれるツール（リモートリポジトリを見やすくしてくれるツール）
SourceTree：Gitのコマンド発行とかを代理してくれるツール（ローカルリポジトリを見やすくしてくれるツール）

#最後に
自分の記事でもコメントいただいてますが、試しに触ってみるのが、一番早いっすね。
gihub に自分のリポジトリを作って、 sourcetree を使いながら学びましょう。

それ以外の見た方がいい系の資料は以下にまとめてあるので、どうぞ。
サル以下の存在がまとめた「Git用語」図解

---

1. サーバ側では差分管理しているっぽいが未検証。クライアント-サーバ間では「ファイル自体」をやりとりしていると理解した方が早いので、こういう表現にしてみた。 ↩