「Git入門」を聞いてきた！

１月２５日JJUGナイトセミナー Git入門を聞いてきた。その内容をメモメモ

---

■Ｇｉｔはじめの一歩
今日はＧｉｔを始めるための準備

Ｇｉｔとは
・バージョン管理ツール

バージョン管理とは
・変更履歴の把握
・バックアップ
・複数人で作業

バージョン管理のない世界を考えてみよう
・元に戻せない
・ファイルの新旧がわからない

これはちょっといやだよね

歴史だいじに

管理に使うもの
・リポジトリ＝歴史の保管庫

バージョン管理の種類
・集中バージョン管理システム
　みんなで使うリポジトリが１つ

・分散バージョン管理システム
　作業者がローカルでリポジトリが持てる
　→Ｇｉｔ

分散バージョン管理の便利なところ
・自分専用リポジトリが作れる
　精神的にもやさしい
・ローカルだけで作業できる

改めてＧｉｔとは
・大事な瞬間を切り取ってリポジトリで管理！
　スナップショットで保存
　　ファイルの状態、歴史の操作であり、
　　ファイルそのもののアップロードとは違う

操作の流れ
　使うもの
　　・ワークツリー
　　・ローカルリポジトリ
　　・リモートリポジトリ

ローカルでの操作
・ローカルリポジトリ作成
　　クローン git clone
　　作成　　 git init
　→.gitという隠しフォルダができる

・コミットまで
　Gitの管理している状態
　　リポジトリ：ローカルリポジトリ

　　　　　git add
　　　　ステージにのせる
　　　　　git commit
　　　　コミット

　　どうなっている？
　　　　git status

・続いてリモートでの操作
　　ヒモづける：git remote
　　→デフォルトだとorigin

　　歴史のやりとり
　　　git push

　　もってくる：２とおり
　　　１ git pull
　　　２　git fetch/git merge
　　→使い分けはフローによる

ブランチ
・過去のどの時点からでも
・ブランチに名前をつけられる（デフォルトはmaster）

必要によって使い分けたい
　　ブランチの切り替え Head
　　Headの位置を切り替える get checkout

複数つくったブランチを統合
　　マージ　masterにヘッド git marge
　　りベース取り込みたい上にHead git rebase

マージにもいくつか種類（２種類を紹介）
　fast-forward
　non-fast-forward
→マージコミットが作られるかどうか
　--no-ffオプション

コマンド
・歴史の確認
　　git log
　　コミットのログが見れる

・差分の確認
　　git diff

・歴史の名前付け
　　タグ git tag

Git初心者がやりがちなこと
・余計なものまでコミット
　　jar,war,クラスファイル
　　.classpass
　　ログファイル
　→.gitignoreファイルを作る
　　　サンプル https://github.com/github/.gitignore

・GitとGitＨｕｂを混同

・コンフリクト恐怖症
　　該当箇所をさがす
　　＞＞＞＞＞
　　＜＜＜＜＜＜

Ｇｉｔで困った時のＴｉｐs
・予期せぬコンフリクト
　直前（実施中）のマージ取り消し
　　git marge --abort

・間違ってコミット
　コミットを取り消し
　　１． git revert　：記録する
　　２． git reset　：なかったことにする（避けたほうがいい）
　
・間違えたコミット内容
　直前のコミットを編集しよう
　　　git commit --amend

・間違ってadd / 編集
　　　git status
　どうしたらいいかは書かれている

・きえたあ
　　git reflog
　→gitのＧＣが走ると消える

一番危険なのはあわててよくわからないまま操作を続けること

実際手を動かすと、迷子になるかも
・イメージ大事
・progit https://progit-ja.github.io/

何を使うも自由
　自分が使いやすいと思う方法を試してみること！
　みんなちがって、みんないい

まとめ
・gitを使って楽しく開発しよう

・全体を捉える
・困っても元に戻せるので安心して使い倒そう
・自分に合った方法で習得しよう


質問
・ステージング
　２つファイルがあって。１つだけaddして問題ない？問題ない

・ブランチ
　ファイルではなく、コミットへのポインタ

---

■Git実践入門

基盤チーム：開発プロセス
少人数：やりやすい
大規模：運用フロー、らいぶらりあん・構成管理をしないと→大惨事になる

ソースコードを管理するための基本的開発スタイル
　　ぎっとぱけっと、じぇんきんす、アーティファクトリーをつかってる
　→Jenkinsで最新のソースでデプロイ・テスト
　　mavenで依存関係を解決しているのでartifactory上で解決
　→全部無料
　　RedMine以外はJVMで動く
　　ブログに書いた

・GitBucket
　インストール簡単
　Githubに似ている
　localhost:8080で root/rootで入れる

・warを直接起動できる・簡単

困ったこと
・すごいたまにデータが飛ぶことがある
　　→バックアップ大事

トラブル対応のコストはかかる

プロジェクト構成とブランチモデル
・体制、要員スキルに合わせて考える
【ケース１】
　小規模、構成管理の大切さが分かる人は１人はいる→変更の取り込みを主体的に管理
【ケース２】
　小～中、Ｇｉｔや構成管理をあまり知らない
【ケース３】
　中～大、Ｇｉｔや構成管理をあまり知らない

○ケース１（理想の形）
・プロジェクト構成
　　拠点ごとにリポジトリが分かれている
　　　画面、バッチ、基盤等が拠点に対応
　　　ベースリポジトリからフォークしてサイトリポジトリ
　　　らいぶらりあんだけがベースリポジトリをコミット
　　　サイトリポジトリは開発者がpush,pull
　　　共通リポジトリを作る
　　ブランチ運用
　　　フューチャーブランチを作成
　　　できたら、フューチャーブランチプッシュ
　　　らいぶらりあんはＵＴ後、ベースへ

　　共通リポジトリにフレームワークを入れ、
　　これを取り込むタイミングを自由にする→落ちない

　　運用コスト高い

○ケース２　アプリチーム複数Ｘ基盤チーム１つ
　　リポジトリ１個、画面、バッチ、基盤
　　ブランチを分ける
　　リリース用ブランチを作る
　　プルリクエスト：変更を取り込みたいリクエスト

　　どのチームにいて、何を開発しているかが明確になる

○ケース３　アプリ１つ(オフショア）Ｘ基盤１つ
　svnと同じdevelopブランチへの直接commit,直接push
　教育、運用コストはかからない
　オフショアは開発フローを指定できない場合あり
　まちがいでpush,
　レビューしてないものもリリース対象
　フレームワークをすぐに受け入れないと・・

導入・運用してみて思ったこと
・ガイドを用意するとスムーズ
　　文化に合わせてメンバーが使いやすいツールを
・ややこしいことはさせない
　　よくわかっていない人がよくわからないまま何かすると死ぬ
・使い方を変えるぐらいの柔軟性
・とにかくやってみるとイイ
　　なんとかなる
https://uga.gitbooks.io/mastering-builder/content/
・featureブランチは息短めに
・はじめにデモしてあげる
・ちゃんとトレーニングを重ねていく

One more thing
　　ギットクエスト
https://www.atlassian.com/ja/git/tutorial/git-basics
にチュートリアルはまるなげ
gitコマンドで戦う

質問
・細かい修正は？
　細かい単位で切る
・共通部品は？
　リリース後に確認
・導入するには
　上司に言わずに入れる
・GitBucketは
　ローカルでおける
・SVNでいいところ
　ファイルロック
　Gitはマージで解決する
　Gitのほうがいいんじゃない？
・Gitのおいしいところだけ受け取るには？（どのくらいからはじめる？）
　リポジトリ
　フューチャーブランチ
　→おなじところにコミット