気ままなつぶやき

おべんきょしたこととか

【git】入門git

git 読書

なんか周りでgit色が強まってきた( `◔ω◔)
てかgithub色？

まあひとまず、gitの復習。

もともとざくっとしか知らないので、入門書読んでみた。
コマンドについては触れない

入門git

さらさらさらりと。。

1章：Git流バージョン管理入門

さらりと概要

cvs,svnとか集中型リポとの違い

  • Gitはローカルリポもつよ
  • マージトラッキング機能あるよ
  • masterブランチ(svnでいうところのtrunk)
  • ディレクトリは追跡しない

とかとか(ry

用語

  • push:公開リポに、ローカルリポの変更を共有
  • fetch:公開レポから、変更情報を取得
  • marge:ローカルの履歴と取得した変更をマージ
  • pull:fetch&marge (svnでいうところのupdate)

gitの利点

  • ストレージの節約

gitはファイルの履歴を追ってるのじゃなくて、
コンテンツ自体の履歴を追っているので容量がsvnみたいに大きくならない

ストレージの節約は、管理者からすると魅力的☆ﾍ(￣∇￣ ﾍ)

2章 Gitのセットアップ、3章 最初のプロジェクトを作る

ローカルにリポジトリ作ったら初期化してね

mkdir testproject
cd testproject
git init

コミット名にSHA-1

gitは、コミット管理をするためにコミット名をSHA-1ハッシュ値を使ってる。
svnとかみたいにリビジョン番号とかじゃないのは、
ローカルから複数人でマージしたときにコンフリクトが発生しないようにするため。

コミットログには「なぜ」をかこう

gitに限らないけども。

git archive

アーカイブつくれるお

4章 追加とコミット：Gitの基本

  • hunk(ハンク):ファイル内の変更のこと。用語・・・
  • git commit:ローカルリポにコミット。中央リポにはコミットしないよ
  • .gitignoreまたは.git/info/exclude:無視するものを指定する

5章 ブランチを理解して使う

git使っておいてブランチ切らないとか、レーシングカーで通勤するのと同じだぜ♪

的なw

ブランチって？

  • gitではすべてがブランチ
  • ブランチでは、最新のコミットのみ記録。過去に遡るには、記録されている直前のリンクをたどっていく

いつブランチきる？

著者曰く

ブランチ間のマージ

  • 直接マージ
  • 圧縮コミット：履歴をまとめるかんじ
  • チェリーピック（つまみ食い）：色んな履歴をつまみぐい

6章 Gitの履歴を使った作業

VCSの管理してるとログを見ることがあるので、個人的にここ重要だ(｀・ω・´)ｷﾘｯ
でもコマンドまとめは、また次回(｡´・ε・｀｡)

gitのlogは、リビジョン範囲でもみれるし、○時間前、とか日にちの期間指定とかもできるよ。
個人的には、svnとかでいうと、日にちの期間指定が一番使う

git blame

行指定、正規表現などを使って、該当する部分を、「誰が」変更したかを
調べることができる。

blame:非難する、とがめる、責める

・・・( ｡-ω-)-ω-)-ω-) ｼｰﾝ

コマンドベースで調べることはないかな。。。

履歴の書き換え

  • コミットの順番を変更する
  • 複数コミットを1つのコミットにする
  • 1つのコミットを複数コミットに分割する

ほむ。使うかなー。。。(｡´-ε-｀｡)

7章 リモートリポジトリを使った作業

この章は個人的には面白かった。

ネットワークプロトコル

  • ssh：セキュリティ重視
  • git：速度重視
  • http/https

ssh

いったんサーバにログインしてからリポジトリのcloneを作ろうとする。

えー・・・(・Д・｀；)

でもこれがセキュリティ的には一番良いっぽい。
サーバ側でうまく権限管理できたらいいかな。

git

独自プロトコル。最速。9418番（TCP）

匿名のプロトコルなので、自分のリポを読み取り専用のアクセス権で公開したい場合は良いが
書き込み専用だと危険。

gitプロトコルを使ってるリポは、「読み取り専用」と思ってよい

http/https

非効率。困ったときの最後のプロトコル。

8章 リポジトリを整理する

複数プロジェクトの管理

gitで複数プロジェクトを扱う2通り

結局のところ、
「同時にリリースする」可能性がある場合
複数プロジェクトを1つのリポで管理してもいい。

その場合に限る。

svnの管理してるけど、複数プロジェクトを1つのリポにしている(。 _ _)。o○グー
1プロジェクトに1リポにはせずに、ある程度まとまった複数プロジェクトを1つのリポにしている


リポ管理面からすると、適度にはまとめた方が楽・・。
結局のところプロジェクト単位で履歴みる程度ならそれでもいい。


でもプロジェクト開発者側からするとコミットフックで何かしたい場合に弊害が出たりするから
正直全然ベターじゃないんだけどね。。。

サブモジュール

複数リポをすべて同じリポ内にあるかのようにできる

svn:externalsみたいなもん

9章 基礎を越えて

git gc

履歴の格納方法を変更する。
☆ディスク容量が節約☆できる。定期的に実行するのがベター

(∩´∀｀)∩ワーイ (∩ﾟ∀ﾟ)∩ﾜｰｲ

gitは速度と効率を重視しているので、最適化については一部後回し。

git gcは
デルタとよばれる格納部分に保存している変更内容を圧縮する。
圧縮された部分の、変更履歴の追跡は遅くなる。

    • aggressiveオプションを利用するとデルタの再計算をする

git reflog

参照ログ

まちがえてgit resetとかしちゃったときに復旧するときに使える

                                        • -

第3部 git管理のおはなし。

移行

git-svnとかcvs2gitとかあるよ

第11章 GitosisでGitサーバを動かす

gitosis

gitサーバとリポを管理するツール。
python



総括

git管理まわりのおはなしを読みたかったんだけど、
管理まわりはあんまり載ってなかったな。

でも、svnとの比較のお話をちらほら見つけて
かなり読みやすい本だった。

「入門」て意味では良い本だった(｡´・ε・｀｡)