ひげろぐ » Git http://brass.to/blog 技術者として仕事人としての思うところや覚え書きやらです Fri, 30 Jul 2010 10:07:43 +0000 http://wordpress.org/?v=2.8.4 ja hourly 1 デフォルトの.gitignoreを設定する http://brass.to/blog/default-gitignore.html http://brass.to/blog/default-gitignore.html#comments Wed, 09 Jun 2010 03:29:07 +0000 akahige http://brass.to/blog/?p=488 *.swpとか.DS_Storeとかを指定した.gitignoreをプロジェクトごとに作るのがいい加減面倒になってきたので重い腰を上げて設定してみた。
自分のホームディレクトリに.gitignoreを作成して以下のコマンドを打てばよい。

git config --global core.excludesfile ~/.gitignore

やればすぐなのになー。
こういうのつい先送りにしてしまう。

参考:~/.gitignoreを複数プロジェクトで使い回す – satoko’s blog – s21g

]]> http://brass.to/blog/default-gitignore.html/feed 0 SubversionからGitに移行 http://brass.to/blog/subversion_to_gi.html http://brass.to/blog/subversion_to_gi.html#comments Wed, 10 Jun 2009 12:44:25 +0000 akahige http://brass.to/blog/?p=314 実はちょっと前にしてました。
今ではすっかりGitしか使わなくなってます。

移行の理由は世間の流行に乗って、という部分もあるのだけど主な理由はクライアントソフトの不在。
MacでいいGUIのSVNクライアントがなくて結局コマンドラインで使っているので、そんだったらGitでいいじゃんといったノリで移行。

WindowsだとTortoiseSVNがかなりいい感じだけど、Macではそれに匹敵する物が見つからなかったのが理由。
svnXはMacでもイマイチなUIなソフトはあるんだなー、と言う残念さ教えてくれたし、SCPluginは後一歩だったけどやや機能的に物足りず使い続けるには至らなかった。
人に何かいい物ないかと聞いてもコマンドライン派が多かったような気がする。

でコマンドラインでも使い始めてみれば実のところそんなに不便はなかったのだが、ただignoreするファイルの設定がいちいちめんどくさくて死にそうだった。
（svn propsetとかコマンドラインでやるもんじゃねえって個人的に思いました）

Gitは以前から実験的に触ったことはあったので移行は割とスムーズに。
ただsvnとrevertの意味が違うのでそこだけちょっと戸惑ったくらい。

リポジトリの移行も簡単で

$ sudo port install git-core +svn

とかでgit-svn込みのGitを入れて

$ git svn clone svn://hoge_repos/hoge_project/trunk hoge_by_git

これをリポジトリサーバ上ににまんまコピーするなり–bareオプションを付けてcloneするなりして完了。
さくっと移行できてしまった。
詳しいところはぐぐればたくさん出てくるので詳細は割愛。

しかし使い始めてみると分散管理の必要がなくてもGitは使いやすい。

  • オフラインでも使える（やはり区切りごとにコミットできるのは精神衛生上よい）
  • サーバ上のマスターリポジトリに何かあっても手元のリポジトリをさくっとマスターにできる（これはひとり開発だからか）
  • （上に関連して）.git/configをいじれば簡単に参照しているマスターを変更できる
  • ブランチ切ったりマージするのが簡単（まあブランチ切らないけど）
  • ignoreするファイルの設定が簡単（.gitignoreに書くだけでいい）
  • .svnファイルがディレクトリごとにできないので煩わしくなくていい
  • githubがある

ざっと思いつく限りでこんなかんじ。
サーバ上のリポジトリに縛られない軽快さが予想以上に良い。

あとはGUIのクライアントでいいものが出ればSubversionのアドバンテージはなくなってしまう気がするね。

]]> http://brass.to/blog/subversion_to_gi.html/feed 2 Mercurialの勉強会に参加してきた http://brass.to/blog/bpstudy_11_mercurial.html http://brass.to/blog/bpstudy_11_mercurial.html#comments Mon, 21 Jul 2008 09:16:11 +0000 akahige http://brass.to/blog/?p=145
  • BP Study ≫ Blog Archive ≫ BPStudy #11

    • これは恵比寿にあるビープラウドさんという会社が主催してやっている勉強会で、MCの用意したネタをもとに参加者がいろいろ意見を出し合うという形式の会。
    たまたまmoongift氏に声をかけてもらったので行って参りました。

    ちなみに7/11にやったのにいまさらレポするのは、富士登山準備 → 富士登山 → 空前の筋肉痛で精神的にスリップダメージを受け続けて死亡状態という鬼コンボでしばらく書く余裕がなかったという事情による・・・

    さてセッションのタイトルは「高1からのMercurial入門」
    分散バージョン管理システムであるMercurialについて概要の説明から実際の操作までを見ていった。

    表題は「CVSは小学生まで」 → 「Subversionの次は分散バージョン管理システム」 → 「じゃあSubversionは中学生までで高校生からはMercurial」という流れを汲んでの半ばネタ的なもの。

    実際に仕事などでバリバリ使っている人たちの意見が聞けて面白かった。
    なおこの次のセッションにコードレビューツール宍道湖の話もする予定であったが、Mercurialのセッションが白熱して長引いたため時間が足りずに終了。居酒屋になだれ込んだ。

    以下当日のメモより抜粋。聞き違えている可能性もあるのでなにかツッコミどころがあれば指摘してもらえるとこれ幸い。

    分散バージョン管理システムのメリットとデメリット

    メリット
    • リポジトリがローカルなので操作が高速
    • オフライン開発可能
    • 安定してない変更もローカルにならガンガンコミットできる
    • リポジトリのセットアップが簡単
    • マージが簡単
    • Subversionと違って.svnがディレクトリごと増えないので気持ちいい
    デメリット
    • リポジトリが大きすぎるとcloneで手元に持ってくるのが大変
    • ツールサポートが少ない（Windowsクライアントとかないかあっても微妙とか）
    • 使いこなせる人が少ない
    • ワーキングディレクトリ、ローカルのリポジトリ、リモートのリポジトリと場所が増えるのでどこに対して操作しているのか混乱しやすい
    • バイナリの差分は取れない
    • メインリポジトリを決めるなどの運用ルールが必要
    • ブランチやマージが多発しない環境ではあんまりメリットを感じられないかも

    MercurialとGitの比較

    Mercurial
    • Pythonで出来ていていじりやすい。機能拡張も楽
    • TortoiseHgというWindowsクライアントがある（でも微妙）
    • Java系、Python系のプロジェクトでよく使われている
    Git
    • リーナスが作った
    • SVNとの連携がしっかりしてて移行が楽
    • GitHubがすげぇ
    • 速い
    • Linux、Rails界隈でよく使われている
    • 日本語リソースがしっかりしてる
    どっち使ったらいいの？

    好きな方使え。

    実際どっちを使ったらいいのかという疑問に関してGitもMercurialも両方使い込んでいるらしい人が「Git」と言ったときにMCから「今日の発表全否定っすか」という声があがったのにはワラタ。
    発言の意図としてはGitHubがすごいのと日本語リソースが手厚いのでGitオススメらしい。

    Subversionは本当に中学生まで？

    というのはネタ。
    分散してないバージョン管理システムで8割の人のニーズは満たせるだろう、という意見もあるようで。

    不特定多数が参加してブランチやマージが多発するようなオープンソース的な開発は分散バージョン管理システムとの相性がよいので、オープンソース開発ではそちらがメインで使われることになりそう（すでになってる？）
    でも企業内における開発環境としては今のところそこまで分散バージョン管理システムの方に決定的なアドバンテージがあるわけではない。

    その他の話題

    みんな銘々に自分のリポジトリにコミットしていったらマージが多発するのではないか？

    その通り。
    だがマージも簡単なのでそれほど問題ではないそうだ。

    大きなプロジェクトにはマージの専門家がいるという話

    直接pushはせずにパッチを投げてスペシャリストにマージしてもらう。
    マージスペシャリストのマージの鮮やかさはすごいらしい。

    小さいプロジェクトでもうまく回るらしい。
    開発者は好き勝手ガンガンコミットしてマージスペシャリストがうまくマージしていくという流れになる。（でもマージスペシャリストって能力高くないと務まらなそうだし、そういう人が務めるにはマージ作業って物足らなくない？というツッコミもあり）

    品質管理を厳格にやるという用途にも使えるのかも。
    というか厳格にしないとしても品質管理に使いやすいな。

    BranchとTag

    Branchの機能は基本的に使わないでコピーした別のリポジトリをBranchとして使うそうだ。

    Tagは前のリビジョンから何も変更のないチェンジセットが作られるだけ、という話だった。たしか。自信なし。まあ問題なくできるよと。

    参加しての感想

    面白い会だった。

    プロジェクタにPCをつないで実際にMercurialの操作をしながら見せてくれたのでわかりやすかったし、久しぶりに技術者の集まりに参加できたのも有意義だったなぁと。

    スキあらばまた押しかけたい。

    ]]>     http://brass.to/blog/bpstudy_11_mercurial.html/feed 0     CentOS 5.1にGitをパッケージで入れる http://brass.to/blog/centos_git.html http://brass.to/blog/centos_git.html#comments Mon, 21 Apr 2008 21:13:54 +0000 akahige http://brass.to/blog/centos_git.html 2010年の昨今はExtra Packages for Enterprise Linux (EPEL)から入れるのがおすすめ。
    EPELに関しては追記参照。

    最近Gitが幅をきかせているので重い腰を上げて入れてみた。
    特に何も考えず以下のコマンドを打ってみる。

    $ sudo yum install git

    なんだか入った。

    でも標準リポジトリには入ってないようだ。
    標準のリポジトリじゃなくて外部リポジトリとして登録してあるDagのところから入った。
    外部リポジトリ登録がない環境でもパッケージはあるのでRPMを落としてきて入れられるね。

    参考：YUMで便利な外部リポジトリを使う – ひげろぐ

    あとは以下のページとかみながらちょっと触ってみますかね。

    Git入門 – トップページ

    とりあえずチュートリアルの最初だけ試してみた。

    $ git config --global user.name "akahige"
$ git config --global user.email akahigeg@gmail.com

    ちゃんと登録されているのかな？

    $ git config --global --list
user.name=akahige
user.email=akahigeg@gmail.com

    されてた。ぐっど。

    2010/7/30追記

    EPELの方がなんとなく安心度高い。

    $ sudo wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
$ sudo rpm -ivh epel-release-5-3.noarch.rpm

    で、yumでEPELのリポジトリが有効になる。

    ]]>     http://brass.to/blog/centos_git.html/feed 0