パスワードを忘れた? アカウント作成
11015869 story
プログラミング

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使ってますか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by prevet (8921) on 2014年05月31日 10時54分 (#2612413)

    どこにぶら下げようか迷ったんですが、新規に。

    MS Office系のファイルの管理、どうされていますか?
    ワードやエクセルの場合、装飾を無視していいのならテキスト化したらいけると思うんですが、それができない部分、たとえばVBAとか、Excelならマクロとか。
    (docxとかxlsxならちょっとはましなのかな…。)

    特に、.accdbについてはいろいろ試していますがなかなかこれぞという方法が見つかりません。
    VBAの部分だけテキストファイルにコピペしたり、ダンプするコマンド(名前失念)で出力されたファイルを管理するのもやりかけたのですが、ものすごく煩わしくて…。

    よい知恵ありましたら是非。

    --
    聞くは一時の恥。聞いたら一生の恥?
    • by prevet (8921) on 2014年06月02日 20時30分 (#2613698)

      docx、xlsxについては教えていただいた方法で何とかなりそうです。

      後はAccessがなぁ。
      VBA、クエリなどのSQLはまぁ何とかなるにしても、フォームとか…。
      ぶっちゃけ、手元ではDatabase1.20140531.accdb、Database1.20140601.accdbみたいな感じで保存しています。我ながら無粋なのは承知しているのですが。

      --
      聞くは一時の恥。聞いたら一生の恥?
      親コメント
  • by Anonymous Coward on 2014年05月30日 0時30分 (#2611330)
  • 一瞬unavailableと読ませたいのかと思ったけど、そんなことはなかった

    # an available のかわりに is available もしくは単に available でいいような。
    # 何か元ネタあったらごめんなさい。

    • by Anonymous Coward

      hylomの英語力を試したんじゃない?

    • by Anonymous Coward

      available は形容詞だから
      an available は文法的に間違っていると思います

      よく有る見出は
      Git v2.0.0 is now available
      ですね

  • by Anonymous Coward on 2014年05月30日 23時42分 (#2612260)

    これはじっとしていられませんね。

  • by Anonymous Coward on 2014年05月30日 20時31分 (#2612111)

    うちは現在svn使ってるんで、個人的にはgitいいねと思いつつ
    会社全体の移行はできてない。

    git-svn何度か試したけど、なんでかうちの環境だと全く動かないんだよねえ、これ。
    このへんもデフォでさくっと連携できるぐらいになって欲しいなあ。
    世間にはうちみちたいなsvnのとこまだまだ多いはずだし。

    • by Anonymous Coward

      git-svnが動かなかったことがないので、なんで動かないのか興味がある。
      でも、全く動かないんじゃ、理由なんて分からないよね…

      git-svnが動くと、共有リポジトリはsvnでいいよという気になる。
      最初の一発目は全リビジョンを取ってくるので歴史のあるところだと遅いのと、
      svnのプロパティを扱えない以外は全く問題なし。
      遅いのは最初の1回目だけだし、プロパティはsvnでチェックアウトした方で扱えばよいし。

      • by Anonymous Coward

        svn はソフトウェア資材の変更履歴の追跡ツール
        git はプログラムコードのパッチ清書ツール

        svn では最終的にうまくいかなった試みを「なかったことにする」のが困難。
        git ではそれは大して難しいことではない。

      • by Anonymous Coward

        svnのプロパティを扱えない以外は全く問題なし。

        Windowsで使うならそのプロパティが問題。.gitattributesでは力不足。
        GitはWindowsやバイナリファイルのことをあまり考えていないから、改行コードやバイナリファイルの破壊問題で苦労するよ。

        • by Anonymous Coward

          バイナリファイルの扱いはほんと苦手ですよねえ。

  • by Anonymous Coward on 2014年05月30日 20時58分 (#2612138)

    開発のソースツリーが
    プロジェクトごとでなく
    会社で1つのツリーになっていて
    web/proj1
              /proj2
    みたいになっていた場合
    Subversionなら
    下位のだけでいけるけれど,Gitはそれが出来ないのが難点
    それとも今はできるようになったのかな?

    • ここにでもぶら下げます。SVN と Git の比較となると Off - Topic 認定される恐れも承知しつつなんですが、
      SVN と比べて、Git の何がいいんでしょうね?という。
      私は自転車とトラックのように共存するものだと思いますが、サーバーをGit に移行しようぜ!と勧める Git 屋さんの気持ちがわかりません。二段階commitがイイとか、ATの車で満足している人にMTに移行しようぜとアピールするもんじゃないかなと。
      親コメント
      • by Anonymous Coward on 2014年05月30日 23時12分 (#2612242)

        完全な主観ですが。

        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 の内部構造を把握していないと理解しづらいコマンドがある)

        親コメント
        • by Anonymous Coward on 2014年05月31日 0時09分 (#2612276)

          ...
          - リポジトリが肥大化しがち(特に大きな画像等の asset 類を扱う場合)
          ...

          diff 出力表示など内容そのものの履歴管理が必要ないのであれば git-annex [branchable.com] などはいかが?

          親コメント
          • by Anonymous Coward on 2014年05月31日 0時43分 (#2612294)

            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 ではこの辺りの改善を期待したいところです。

            親コメント
            • by Anonymous Coward

              巨大なバイナリファイルを使うプロジェクトに参加していることもあって、gitがスケールしないってを痛感しています。
              ソースコードなんかだと分散型バージョン管理以外あり得ないよねと言えるくらいに便利だと思ってますが、画像とかがががが

      • by Anonymous Coward

        今使っているバージョン管理システムに何の不満もなく完全に満足している人にはそりゃどんなアピールだろうと意味ないでしょう。

      • by Anonymous Coward

        分散リポジトリでもあるので、マスターが死んでも直ぐに再構築可能というところが売りだったような
        そのせいで途中からチェックアウトが出来ないのかも・・・?
        とりあえず簡単なリポジトリの分割ができれば特に言う事もないんだけど

      • by Anonymous Coward
        速くて柔軟、VisualStudioが標準で対応している、と来たら新規のプロジェクトであえてgitを避けてsubversionにする理由がないと思います。
        # て主張したのにTFSになった…何を言ってるのか分からねーと思うが俺も何をされたのか分からなかった
        • by Anonymous Coward

          他の言語も同じリポジトリに入れたいならともかく、Visual Studioから使うだけならTFSでいいじゃん。
          Subversion的な欠点はTFSにはないし、Gitだとゲートチェックインとか一部機能が使えないから一長一短だぞ。

        • by Anonymous Coward

          Vssじゃないだけまし

      • by Anonymous Coward

        バージョン管理システムなんでどれも対して変わらない。
        新しいのいちいち覚えるのは面倒だ。
        そう思ってた時期が自分にもありました。

        しかし、ブランチの圧倒的な軽さ、次元の違うマージの賢さ
        コードレビューを含めての分散開発のやりやすさなど、
        今ではgit以外使う気になりません。

        > ATの車で満足している人にMTに移行しようぜ

        逆でしょ。
        MT使ってる人にAT薦めてるんですよ。
        しかもそのAT、あなたがMTで運転した時より格段に燃費良かったりする。

        • なかなか良さげな列挙ありがとうございます。
          が、仮にGitが良いとして問題は・・・。まぁ 会社における OS の移行みたいなもんでしょうね。
          新しいソース管理システム使うとなると、移行が必要です。履歴を含めて変換が正しく成功するかリスクもあります。
          既にSVN に百人規模でぶら下がってて、彼らの再トレーニングが必要。
          Win XP -> Vista でわざわざ移行した会社さんがあったかどうかしりませんが、
          3.1 -> 95 ぐらいのインパクトがあって、移行による効率アップが明白にならないと
          わざわざ人員リソースを手配して1ヵ月単位で移行することはないでしょう。
          親コメント
          • by Anonymous Coward

            git svnでいいじゃん。使いたい奴だけ。

            git svnでダメな理由が知りたい。
            つまり、共有リポジトリをgitにする理由が。

            • by Anonymous Coward on 2014年05月31日 2時17分 (#2612325)

              Gitのブランチでの履歴がgit svn dcommitで一つにまとまってしまってGitのメリットが生かせないから、共有リポジトリもGitにしてしまった方がいいと思う。

              Git でのブランチに関する問題 [git-scm.com]

              SubGitならなんとかなるみたいだけど。

              親コメント
            • by Anonymous Coward

              基本的には同意。
              まあ、マージはマージとして残したいなぁと思う事もままある。

              ただし、そもそもgitについていけない人と仕事したくないとも思う。

          • by Anonymous Coward

            何のための分散型だと思っているんですか。移行したい人/できる人から順次移行していけばいいでしょうに。

      • by Anonymous Coward

        ローカルで気軽にコミットして作業できる(ローカルでどんだけ間違おうがどんだけ実験しようがサーバーに影響でない)とことか、
        リポジトリの移動が楽とか、コンフリクトが起きたときにマージ明日でいいやと帰れるとか、
        SVNのタグとかブランチって機能じゃなくてローカルルールなとことか。

        ロックしたいバイナリファイルなんかはSVNも使いますけど、ソース管理はSVNには戻りたくないかなー。
        コミットして平気かなって思わずとりあえずローカルでコミットしておけるのが大きいですかね。
        その後失敗しても履歴はローカルに残ってますし。
        基本機能しかつかってないですけど便利に感じています。
        (まぁ私はMercurialですけど)

      • by Anonymous Coward

        vss使ってた会社にsvn入れさせて、svnから移行させるの簡単そうだからと個人的に使ってたhgから乗り換えてbzr1年ぐらい試してたんだけど、
        gitlabのおかげでgitに移行しました。あのブランチの軽さやgitlabで簡単にレポジトリ作れるのがすごい便利。
        特にアカウントの管理がすごい楽。公開鍵を一人ずつ手作業で登録してたssh+svnからだいぶ楽になりました。
        他の社員とか自分じゃアカウント登録できないから派遣さんに同じ秘密鍵共有とかさせてたし。

        なんつーか、gitlab(github)がすごい便利。

        • by Anonymous Coward

          GitLabいいですよね
          ブラウザベースで履歴見るとき
          たまにエンコーディングエラーで表示できない履歴がでたりするけど…

      • by Anonymous Coward

        svnなんて単なるバックアップツールであって、gitにおける履歴とは全く別物。
        どちらも車という例えからして的外れ。

        「きれいな履歴を残す」ことこそが重要であり、
        それを最大限サポートするという哲学でgitは設計されている。

        例えば、コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、
        svnは1コミットにしかできない。
        しかも、その段階で、適切なコミットメッセージを考えなければならない。
        これはプログラミングの思考を大きく阻害するし、
        結果、コミットメッセージも、1コミットで行われて修正の粒度も、
        後から履歴を見たときに役に立たなくなる。(だから単なるバックアップツール)

        これを問題と思えないであれば、プログラマーとしての経験が足りないだけ。

        • by Anonymous Coward

          ブランチで出来ないの・・・(震え声)

      • by Anonymous Coward

        OSSに関して言えば、「みんなが使っている」につきる。
        # WindowsとかExcelの何がいいんですかね。
        バージョン管理システムがマイナーなものだとコントリビューターに参加してもらうための障壁が1つ増える。

  • by Anonymous Coward on 2014年05月30日 23時41分 (#2612259)

    またインストールしなおして設定しなおさないかんのか……

    • by Anonymous Coward
      2.0を使いたいのでなければ少し様子を見た方がいいと思う。

      # ソースコード管理ツールでバグフィックスたくさんって響きはやだなぁ。
  • by Anonymous Coward on 2014年05月31日 9時42分 (#2612397)

    1GB超のファイル(TheCard)複数を管理しようとして、PUSHしようとしたら、
    その断面のファイル全部を(Zipで?)圧縮して送信する処理の途中で、
    仮想記憶オーバーで落ちました。

    おのおのの人の断面を固めて置いておいて、ブランチをたどる際に負担のかかる
    処理をしているから、あんなに柔軟性が高いのですかね。

    置き方がそんななら、サブバージョンでも(VSSですらも)そちらの方が良いように
    思えてきてしまいました。

    • 1GB超のファイル(TheCard)複数を管理しようとして、PUSHしようとしたら、

      ほかのコメントにもあるけど、 Git は大きなファイルの扱いが苦手、というか大きなファイルをコミットするような利用方法に合わせて作られてはいないから、そういう使い方なら他のソフトウェアの方がいいんじゃないかな。何だと適しているのかよく知らないけど。

      親コメント
      • by USH (8040) on 2014年05月31日 20時55分 (#2612680) 日記

        それと、そのTheCard のファイルの形式をよく知らないが、テキストファイルでなければ、git や svn のようなdiff中心のバージョン管理システムでの管理には向かないように思うのだが。

        親コメント
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...