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


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

#内容
##Git概要
参考：[こんなGitの教え方をするエンジニアはデザイナーからモテるぞ！](https://qiita.com/gilly/items/aed8eab37d0f72d6106d)
[この図のイメージ](https://qiita.com/gilly/items/aed8eab37d0f72d6106d#%E3%81%9D%E3%81%AE2git%E3%81%A7%E5%B9%B8%E3%81%9B%E3%81%AA%E4%B8%96%E7%95%8C%E3%82%92%E5%85%B1%E6%9C%89%E3%81%99%E3%82%8B) はとても分かりやすい！

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

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

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

##Gitのメリット
参考：[SVNを捨ててGitを使うべき5つの理由](https://qiita.com/YusukeHosonuma/items/14c59f3878d640a401a1)

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

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

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

##A successful Git branching model
参考：[【日本語訳】A successful Git branching model](http://keijinsonyaban.blogspot.jp/2010/10/a-successful-git-branching-model.html)
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用語」図解](https://qiita.com/nh321/items/6517b0964c6ed1685ecf)
手前味噌な記事ですが。

図を見ながら、実際の流れについて軽く説明するつもり。
→以下の実操作を見せる時は、印刷してホワイトボードに貼って、磁石で説明すればよかった。（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](https://github.com/) に自分のリポジトリを作って、 [sourcetree](https://ja.atlassian.com/software/sourcetree) を使いながら学びましょう。

それ以外の見た方がいい系の資料は以下にまとめてあるので、どうぞ。
[サル以下の存在がまとめた「Git用語」図解](https://qiita.com/nh321/items/6517b0964c6ed1685ecf)

---