Git 2.0.0がリリースされる 73
ストーリー by hylom
今後も頻繁にアップデートが行われるのだろうか 部門より
今後も頻繁にアップデートが行われるのだろうか 部門より
M-FalconSky 曰く、
Linuxのソースコード管理ツールとして誕生したGitですが、ついにバージョン2.0.0がリリースされました（マイナビニュース、SourceForge.JP Magazine）。
主な特徴（タレコみ者主観）は以下の通り：
- git pushのデフォルトセマンティクスがsimpleに
- git addの細かい挙動の変更
- remote-hg/bzrがメインから切り離される
- コミットが生成される色々なコマンドに--gpg-signオプション追加
- バグフィックスたくさん
などなど。
そういえばメンテナとして日本人の方が加わってたりしてましたね。
みなさんはgit使ってますか？
Officeファイルの管理 (スコア:2)
どこにぶら下げようか迷ったんですが、新規に。
MS Office系のファイルの管理、どうされていますか？
ワードやエクセルの場合、装飾を無視していいのならテキスト化したらいけると思うんですが、それができない部分、たとえばVBAとか、Excelならマクロとか。
(docxとかxlsxならちょっとはましなのかな…。)
特に、.accdbについてはいろいろ試していますがなかなかこれぞという方法が見つかりません。
VBAの部分だけテキストファイルにコピペしたり、ダンプするコマンド(名前失念)で出力されたファイルを管理するのもやりかけたのですが、ものすごく煩わしくて…。
よい知恵ありましたら是非。
聞くは一時の恥。聞いたら一生の恥？
Re:Officeファイルの管理 (スコア:2)
docx、xlsxについては教えていただいた方法で何とかなりそうです。
後はAccessがなぁ。
VBA、クエリなどのSQLはまぁ何とかなるにしても、フォームとか…。
ぶっちゃけ、手元ではDatabase1.20140531.accdb、Database1.20140601.accdbみたいな感じで保存しています。我ながら無粋なのは承知しているのですが。
聞くは一時の恥。聞いたら一生の恥？
hamanoさんは2005年からメンテナだよ (スコア:1)
http://en.wikipedia.org/wiki/Junio_Hamano [wikipedia.org]
Re:hamanoさんは2005年からメンテナだよ (スコア:1)
いやまあ、その話題があがったことはなかったかなぁ、と追記してみたりしました。
不要なら削除してもらうということで。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
hylomなら「Git 2.0.0リリース、メンテナに日本人参加」というタイトルに付け替えるくらいのことはしてくれると信じている。
Re: (スコア:0)
むしろ「Gitのメンテナに日本人が参加、バージョン2.0.0がリリース」ぐらいしてくれそう
Re:hamanoさんは2005年からメンテナだよ (スコア:1)
どこに誤字があるんだと探してしまったじゃないか。
LIVE-GON(リベゴン)
an availableのところを (スコア:1)
一瞬unavailableと読ませたいのかと思ったけど、そんなことはなかった
# an available のかわりに is available もしくは単に available でいいような。
# 何か元ネタあったらごめんなさい。
Re: (スコア:0)
hylomの英語力を試したんじゃない？
Re: (スコア:0)
available は形容詞だから
an available は文法的に間違っていると思います
よく有る見出は
Git v2.0.0 is now available
ですね
いよいよ2.0か (スコア:1)
これはじっとしていられませんね。
Re:いよいよ2.0か (スコア:1)
ぎっとぎっとの油まみれで挙動不審なおっさんが目に浮かぶ。
# おれは「ぎっと」派
git-svn (スコア:0)
うちは現在svn使ってるんで、個人的にはgitいいねと思いつつ
会社全体の移行はできてない。
git-svn何度か試したけど、なんでかうちの環境だと全く動かないんだよねえ、これ。
このへんもデフォでさくっと連携できるぐらいになって欲しいなあ。
世間にはうちみちたいなsvnのとこまだまだ多いはずだし。
Re: (スコア:0)
git-svnが動かなかったことがないので、なんで動かないのか興味がある。
でも、全く動かないんじゃ、理由なんて分からないよね…
git-svnが動くと、共有リポジトリはsvnでいいよという気になる。
最初の一発目は全リビジョンを取ってくるので歴史のあるところだと遅いのと、
svnのプロパティを扱えない以外は全く問題なし。
遅いのは最初の1回目だけだし、プロパティはsvnでチェックアウトした方で扱えばよいし。
Re: (スコア:0)
svn はソフトウェア資材の変更履歴の追跡ツール
git はプログラムコードのパッチ清書ツール
svn では最終的にうまくいかなった試みを「なかったことにする」のが困難。
git ではそれは大して難しいことではない。
Re: (スコア:0)
svnのプロパティを扱えない以外は全く問題なし。
Windowsで使うならそのプロパティが問題。.gitattributesでは力不足。
GitはWindowsやバイナリファイルのことをあまり考えていないから、改行コードやバイナリファイルの破壊問題で苦労するよ。
Re: (スコア:0)
バイナリファイルの扱いはほんと苦手ですよねえ。
Subversionから移行して失敗 (スコア:0)
開発のソースツリーが
プロジェクトごとでなく
会社で１つのツリーになっていて
web/proj1
/proj2
みたいになっていた場合
Subversionなら
下位のだけでいけるけれど,Gitはそれが出来ないのが難点
それとも今はできるようになったのかな？
Re:Subversionから移行して失敗 (スコア:2)
SVN と比べて、Git の何がいいんでしょうね？という。
私は自転車とトラックのように共存するものだと思いますが、サーバーをGit に移行しようぜ！と勧める Git 屋さんの気持ちがわかりません。二段階commitがイイとか、ＡＴの車で満足している人にＭＴに移行しようぜとアピールするもんじゃないかなと。
Re:Subversionから移行して失敗 (スコア:5, 参考になる)
完全な主観ですが。
pros:
- とにかくブランチが手軽に作成でき、マージも (SVN と比較すれば) 楽ちん
- commit, log, diff などの基本操作がローカルで完結するため高速
- GitHub などの周辺サービスが洗練されており使いやすい
- GitHub が発明した Pull request ベースでの開発が、コードレビューと一体となって効率的
- rebase, filter-branch など歴史の改ざんが可能（もちろん remote 側の設定次第で reject もできるから悪用は防げる）
- git-flow に代表されるワークフローや、権威型など、プロジェクトの都合に合わせて運用しやすい
cons:
- git clone 時に歴史を丸ごとダウンロードするため、歴史が長いリポジトリだと時間がかかる（ただし最近の git なら --depth で省くこともできる）
- リポジトリが肥大化しがち（特に大きな画像等の asset 類を扱う場合）
- コマンドが非直感的（git reset や git checkout 等 git の内部構造を把握していないと理解しづらいコマンドがある）
Re:Subversionから移行して失敗 (スコア:1)
...
- リポジトリが肥大化しがち（特に大きな画像等の asset 類を扱う場合）
...
diff 出力表示など内容そのものの履歴管理が必要ないのであれば git-annex [branchable.com] などはいかが?
Re:Subversionから移行して失敗 (スコア:1)
git の外部で大きいファイル管理するための類似プロジェクト色々ありますよね。
- git-annex [branchable.com]
- git-fat [github.com]
- git-media [github.com]
- git-largefile [github.com]
ただ、やはり git だけで上手いこと取り扱ってほしいものですが、アーキテクチャ的に難しそうですね。
Facebook による [facebook.com]と、git はスケールしない (we concluded that Git's internals would be difficult to work with for an ambitious scaling project.)、という結論に至ったようですし、git 3.0.0 ではこの辺りの改善を期待したいところです。
Re: (スコア:0)
巨大なバイナリファイルを使うプロジェクトに参加していることもあって、gitがスケールしないってを痛感しています。
ソースコードなんかだと分散型バージョン管理以外あり得ないよねと言えるくらいに便利だと思ってますが、画像とかがががが
Re: (スコア:0)
今使っているバージョン管理システムに何の不満もなく完全に満足している人にはそりゃどんなアピールだろうと意味ないでしょう。
Re: (スコア:0)
分散リポジトリでもあるので、マスターが死んでも直ぐに再構築可能というところが売りだったような
そのせいで途中からチェックアウトが出来ないのかも・・・？
とりあえず簡単なリポジトリの分割ができれば特に言う事もないんだけど
Re: (スコア:0)
# て主張したのにTFSになった…何を言ってるのか分からねーと思うが俺も何をされたのか分からなかった
Re: (スコア:0)
他の言語も同じリポジトリに入れたいならともかく、Visual Studioから使うだけならTFSでいいじゃん。
Subversion的な欠点はTFSにはないし、Gitだとゲートチェックインとか一部機能が使えないから一長一短だぞ。
Re: (スコア:0)
Vssじゃないだけまし
Re: (スコア:0)
バージョン管理システムなんでどれも対して変わらない。
新しいのいちいち覚えるのは面倒だ。
そう思ってた時期が自分にもありました。
しかし、ブランチの圧倒的な軽さ、次元の違うマージの賢さ
コードレビューを含めての分散開発のやりやすさなど、
今ではgit以外使う気になりません。
> ATの車で満足している人にMTに移行しようぜ
逆でしょ。
MT使ってる人にAT薦めてるんですよ。
しかもそのAT、あなたがMTで運転した時より格段に燃費良かったりする。
Re:Subversionから移行して失敗 (スコア:2)
が、仮にGitが良いとして問題は・・・。まぁ 会社における OS の移行みたいなもんでしょうね。
新しいソース管理システム使うとなると、移行が必要です。履歴を含めて変換が正しく成功するかリスクもあります。
既にSVN に百人規模でぶら下がってて、彼らの再トレーニングが必要。
Win XP -> Vista でわざわざ移行した会社さんがあったかどうかしりませんが、
3.1 -> 95 ぐらいのインパクトがあって、移行による効率アップが明白にならないと
わざわざ人員リソースを手配して１ヵ月単位で移行することはないでしょう。
Re: (スコア:0)
git svnでいいじゃん。使いたい奴だけ。
git svnでダメな理由が知りたい。
つまり、共有リポジトリをgitにする理由が。
Re:Subversionから移行して失敗 (スコア:1)
Gitのブランチでの履歴がgit svn dcommitで一つにまとまってしまってGitのメリットが生かせないから、共有リポジトリもGitにしてしまった方がいいと思う。
Git でのブランチに関する問題 [git-scm.com]
SubGitならなんとかなるみたいだけど。
Re: (スコア:0)
基本的には同意。
まあ、マージはマージとして残したいなぁと思う事もままある。
ただし、そもそもgitについていけない人と仕事したくないとも思う。
Re: (スコア:0)
何のための分散型だと思っているんですか。移行したい人/できる人から順次移行していけばいいでしょうに。
Re: (スコア:0)
ローカルで気軽にコミットして作業できる（ローカルでどんだけ間違おうがどんだけ実験しようがサーバーに影響でない）とことか、
リポジトリの移動が楽とか、コンフリクトが起きたときにマージ明日でいいやと帰れるとか、
SVNのタグとかブランチって機能じゃなくてローカルルールなとことか。
ロックしたいバイナリファイルなんかはSVNも使いますけど、ソース管理はSVNには戻りたくないかなー。
コミットして平気かなって思わずとりあえずローカルでコミットしておけるのが大きいですかね。
その後失敗しても履歴はローカルに残ってますし。
基本機能しかつかってないですけど便利に感じています。
（まぁ私はMercurialですけど）
Re: (スコア:0)
vss使ってた会社にsvn入れさせて、svnから移行させるの簡単そうだからと個人的に使ってたhgから乗り換えてbzr1年ぐらい試してたんだけど、
gitlabのおかげでgitに移行しました。あのブランチの軽さやgitlabで簡単にレポジトリ作れるのがすごい便利。
特にアカウントの管理がすごい楽。公開鍵を一人ずつ手作業で登録してたssh+svnからだいぶ楽になりました。
他の社員とか自分じゃアカウント登録できないから派遣さんに同じ秘密鍵共有とかさせてたし。
なんつーか、gitlab(github)がすごい便利。
Re: (スコア:0)
GitLabいいですよね
ブラウザベースで履歴見るとき
たまにエンコーディングエラーで表示できない履歴がでたりするけど…
Re: (スコア:0)
svnなんて単なるバックアップツールであって、gitにおける履歴とは全く別物。
どちらも車という例えからして的外れ。
「きれいな履歴を残す」ことこそが重要であり、
それを最大限サポートするという哲学でgitは設計されている。
例えば、コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、
svnは1コミットにしかできない。
しかも、その段階で、適切なコミットメッセージを考えなければならない。
これはプログラミングの思考を大きく阻害するし、
結果、コミットメッセージも、1コミットで行われて修正の粒度も、
後から履歴を見たときに役に立たなくなる。（だから単なるバックアップツール）
これを問題と思えないであれば、プログラマーとしての経験が足りないだけ。
ブ・・・ (スコア:0)
ブランチで出来ないの・・・(震え声)
Re:ブ・・・ (スコア:1)
1.diffを書き出す
2.変更を取り消し
3.diffからAに関する部分だけ抜き出して適用してコミット
4.diffの残りを適用してコミット
とか？
gitはよく知らないのでちょっと検索してみただけなんですが、
gitなら git add -p を使うと簡単ってことでしょうか？
# emacsって差分ファイルを変更するとき行を調節してくれて便利です
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:ブ・・・ (スコア:1)
どちらかと言うと、今回 git add -p を知って Git いいな、と思いました。
逆に、Git派の意見でよく見るのは「分散型でブランチ簡単だよ」で、
「git add -p 便利」って書いてあるのを見たことが無かったので、
Git派にこの機能を推すよう広めたらどうでしょうか。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:ブ・・・ (スコア:1)
git add -p なんて面倒くさいことになる前に、最初から分けて修正して分けてコミットしないとダメというか、たとえgit add -p がどれだけ便利だとしても、
> コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、svnは1コミット
にしかできない。
これは、そもそも「同じファイルにAとBと別の観点の修正」をしてしまった時点で負けてるかな、と。
で、そういう複数の修正が同一ファイルに行われた時の管理の便利さ、という点で、私はMercurial + mq [hatena.ne.jp]派。
修正を「パッチ」という形で管理するので、後から適用順番の入れ替えとかが自由自在。
まあ、mq 自体は、単独のパッチ管理システム quilt をMercurial に取り込んだもので、自分はやったことないけどquiltはsvnでも使用可能 [srad.jp]みたい。
mq は mercurial に標準で付いてくるのが強みですかね。同様のものはgit にもいくつかある [kernel.org]みたいです。
#こないだ、何年かぶりぐらいにコード修正することになったプロジェクトは、コード管理がCVSでした。2002年に作ったプロジェクトで前回更新が2007年…。どうしたものか思案中。
Re:ブ・・・ (スコア:1)
mq(quilt)の機能というかメリットは、
A1、A2、B、Cいう4つのチェンジセットを作ってしまえば、あとから
「A1とA2とBとC」として扱えるだけでなく、「A1+A2+Bと、C」でも「A1+A2と、B+C」でも、
あるいは、コミットの順番すら入れ替えて「A2+Cと、A1+B」にすることすら、自由自在に組み替え直せるところです。
これができる前提として割とこまめにとりあえず分割してチェンジセットを作る必要があるわけですが、
私自身の意見としては、そもそもAが実はA1とA2に分けられる…と言ってるレベルでは粒度が荒すぎると思ってる、ってことで。
#とはいえ、後からチェンジセットをさらに分割したくなることもたまにはあるのは確かですが、
#mqが管理しているチェンジセットとは差分(パッチ)ファイルそのものですので、git add -p で edit で処理する程度のことは、差分ファイルそのものの手修正である程度は可能です。
Re: (スコア:0)
OSSに関して言えば、「みんなが使っている」につきる。
# WindowsとかExcelの何がいいんですかね。
バージョン管理システムがマイナーなものだとコントリビューターに参加してもらうための障壁が1つ増える。
つい数日前にインストールしたばかりなのに…… (スコア:0)
またインストールしなおして設定しなおさないかんのか……
Re: (スコア:0)
# ソースコード管理ツールでバグフィックスたくさんって響きはやだなぁ。
大きいファイル (スコア:0)
1GB超のファイル（TheCard）複数を管理しようとして、PUSHしようとしたら、
その断面のファイル全部を（Zipで？）圧縮して送信する処理の途中で、
仮想記憶オーバーで落ちました。
おのおのの人の断面を固めて置いておいて、ブランチをたどる際に負担のかかる
処理をしているから、あんなに柔軟性が高いのですかね。
置き方がそんななら、サブバージョンでも（VSSですらも）そちらの方が良いように
思えてきてしまいました。
Re:大きいファイル (スコア:2)
ほかのコメントにもあるけど、 Git は大きなファイルの扱いが苦手、というか大きなファイルをコミットするような利用方法に合わせて作られてはいないから、そういう使い方なら他のソフトウェアの方がいいんじゃないかな。何だと適しているのかよく知らないけど。
Re:大きいファイル (スコア:1)
それと、そのTheCard のファイルの形式をよく知らないが、テキストファイルでなければ、git や svn のようなdiff中心のバージョン管理システムでの管理には向かないように思うのだが。
Re:大きいファイル (スコア:1)
VSS は使ったことありませんが、言語のシンタックスまで踏み込んだ diff を求め始めると、言語レベルを超えて、フレームワークのシンタックスや、さらには実際のアプリのロジックとかまで際限がないことになります。
diff中心のバージョン管理だけですべての修正記録が効率良く表せるわけではないのは確か。それを補うためにコメントを工夫したり、ドキュメントや修正ログを書くのは、ある程度の規模以上のシステムでは当然。
ただ、git や svn は、汎用で幅広く使えるのがポイント。