依存ライブラリを利用する場合RubyGemsやらCocoaPodsといったツールで万事解決するケースがほとんどだと思いますが、たまーにGitに上がっているライブラリを直接自分のリポジトリに追加しないといけない場合もあったりします。 こういった時に使うGitのサブコマンドそれぞれの特徴と使いどころをまとめてみました。 一番スタンダードな外部リポジトリ追加方法です。たぶん大抵の依存管理ではこれを使えば十分でしょう。git-submoduleを利用すると、外部リポジトリのコード自体は自プロジェクトの管理下に取り込まれず、リポジトリの特定コミットへの参照情報のみが登録されます。外部リポジトリのcommit hashへのポインタが追加されるようなイメージです。 $ git submodule add git@github.com:Alamofire/Alamofire.git $ git diff
全文検索エンジンGroongaはmrubyを組み込んでいます。理由は、速度はそれほど必要ではなく込み入った処理をCではなくRubyで書けると開発が捗るからです。 この記事ではどのようにmrubyを組み込んでいるかについてビルド周りだけを説明します。(ビルド周り以外には、バインディングをどうやって書くか、.rbファイルをどこに置くか、実装をCにするかRubyにするかの判断基準などの話があります。) 方針 mrubyはRakeを使ったビルドシステムを使っています。GroongaはGNU AutotoolsまたはCMakeを使ったビルドシステムを使っています。(どちらでもビルドできます。) mrubyはRakeを使ってビルド、GroongaはGNU Autotoolsを使ってビルド、とするとコンパイルオプションの統一・クロスコンパイルあたりで面倒になります。また、Rakeを使ってビルドするために
みなさんgitのsubmoduleって理解して使ってますか? 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか? 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか? 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
「ふたつのプロジェクトはそれぞれ別のものとして管理したい。だけど、一方を他方の一部としても使いたい」Git – サブモジュールの冒頭にこうありました。まさにこれがしたいと思っていたのでちょっと手を動かしてみました。今まで避けていたので。。 サブモジュールとは サブモジュールとは主な管理対象(管理対象A)に別のgit管理対象(管理対象B)を追加することです。ただし、管理対象Bの中身までは管理しません。あくまでも、管理対象Bの特定のコミットを記録するだけです。 サブモジュールの追加 $ git submodule add git://github.com/chneukirchen/rack.git rack これを行うと、.gitsubmodulesと、rackがAの管理対象に追加される。 $ cat .gitmodules [submodule "rack"] path = rack url
こんにちは。 今回は個人的に最初ちょっと扱いづらかった git submodule について基本的な使い方をメモしておきたいと思います。 git submoduleは外部のgitリポジトリを自分のリポジトリのサブディレクトリとして扱うことができるようになるものです。 cloneせずにsubmoduleとすることで、対象のリポジトリが更新されたときも追従することが可能となります。 最初は使いづらいしよく分からなかったのでcloneしてましたが、慣れると便利です。 それでは使い方を見てみましょう。 サブモジュールの追加 サブモジュールは git submodule add コマンドで追加出来ます。 $ git submodule add <gitリンク> 追加すると、Gitリポジトリのルートに .gitmodules が作成されます。 中身を見てみると、追加したリポジトリの名前やパスが記述され
git submodule 使い方 サブモジュールについて サブモジュールは外部のリポジトリをソースツリーのサブディレクトリに埋め込むために使用する。 リモートリポジトリとは異なる(リモートリポジトリはソースツリーに埋め込めない) 二つのプロジェクトのヒストリは完全に分かれている サブモジュールに対しては編集できない 外部リポジトリのヒストリを取り込みたい場合は、サブモジュールではなくsubtree merge strategy を使う メインリポジトリはサブモジュールのリポジトリのあるコミットを参照している サブモジュールを追加する <git://example.com/repo.git> を サブモジュールとして追加するには git submodule add git://example.com/repo.git git submodule add git://example.com/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く