Edited at

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

More than 1 year has passed since last update.


はじめに

サル以下な存在にも関わらず、ちょっと社内で説明する場面があるので、まとめておく。(当日もこれ見ながら説明するつもり)

30分以内に喋りきって、質疑応答を少しやって、合計45〜60分くらいのコースを想定した資料。

(実際には使わないんだけど、ざっくり知りたい人に向けた情報。)


内容


Git概要

参考:こんなGitの教え方をするエンジニアはデザイナーからモテるぞ!

この図のイメージ はとても分かりやすい!

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

ポイント

SVNはファイル自体をやりとりしている1

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