巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Git Submodules: コアコンセプト、ワークフロー、コツ | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git を使った開発では、サブモジュールを使うことによって、他のプロジェクトを自分のコードベースに取り込めるようになります。それも、他のプロジェクトの履歴を分離しつつ、あなたのプロジェクトの履歴と同期できるようになるのです。これはベンダーライブラリ問題や依存関係問題を解決する便利な方法です。git に関してはいつもそうですが、このアプローチもかなり自己流なのでうまく出来るようになるまで少しばかり研究することをお勧めします。submodules に関する好例や詳しい説明はすでに公開されているので、ここでまた繰り返すのはやめることにします。この記事では submodule という機能を最大限に活用するのに役立つであろういくつかの面白い情報を共有したいと思います。 目次 コアコンセプト 考えられるワークフロー 初めての人向けの役に立つコツ サブモジュールを自分のフォークしたリポジトリで置き換える
git submoduleはコミットへのシンボリックリンクである説 - hell0againのチラ裏
個人的にgitで思った通りの挙動をしないコマンドナンバー2、それがsubmodule。ちなナンバー1はrebase。 submodule自体、使い込むとたいへん便利な機能なのは間違いないものの、誤解をされやすい挙動をするので扱いにくい感じがある。特にチームで使うとなると全員がsubmoduleを理解していないとハマる人が続出しがち。 なので最近はあれはコミットへのシンボリックリンクだ、と説明してごまかしていたりする。 例えばひとつのリポジトリからライブラリ的なものだけを切り出したり、アセット的なものだけを切り出して別途管理したくなることがよくありまして。そういうときにsubmoduleを使って複数のリポジトリに分割すればスッキリするんじゃね、って考えるわけです。 で、いざsubmoduleを使って分割してみたら submodule 配下がなぜか空だったり、なぜか更新されてなかったり、なぜか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
