goo blog サービス終了のお知らせ 

ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

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

2016-01-26 01:34:38 | Weblog
1月25日JJUGナイトセミナー Git入門を聞いてきた。その内容をメモメモ




■Gitはじめの一歩
今日はGitを始めるための準備

Gitとは
・バージョン管理ツール

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

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

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

歴史だいじに

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

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

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

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

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

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

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

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

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

  どうなっている?
    git status

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

  歴史のやりとり
   git push

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

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

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

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

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

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

・差分の確認
  git diff

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

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

・GitとGitHubを混同

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

Gitで困った時のTips
・予期せぬコンフリクト
 直前(実施中)のマージ取り消し
  git marge --abort

・間違ってコミット
 コミットを取り消し
  1. git revert :記録する
  2. git reset :なかったことにする(避けたほうがいい)
 
・間違えたコミット内容
 直前のコミットを編集しよう
   git commit --amend

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

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

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

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

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

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

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


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

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




■Git実践入門

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

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

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

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

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

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

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

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

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

  運用コスト高い

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

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

○ケース3 アプリ1つ(オフショア)X基盤1つ
 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のおいしいところだけ受け取るには?(どのくらいからはじめる?)
 リポジトリ
 フューチャーブランチ
 →おなじところにコミット

この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« エドワード・ヨードン博士が... | トップ | マービン・ミンスキー氏も亡... »
最新の画像もっと見る

Weblog」カテゴリの最新記事