ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり
submodule の中身を必要な部分だけ持ってくるようにする sparse checkout でリポジトリの一部を持ってくる でリポジトリの一部分だけ取得することができた。それを submodule に応用してみる。 参考: Git 特定のフォルダのみcloneする submodule編 - Qiita submodule を sparse checkout する 前回 Gitで特定フォルダのみクローンする方法を書いたが、これはsubmoduleの場合も使用可能。 というか、submoduleの時にこそ使用する機会が多いだろう(dllだけ取るなど)。 ただ、ファイルを置く場所がちょっと異なる。submodule関連の設定は .git/modules 配下にあるため、 sparse-checkoutもこちらに置く必要があるのだ。 git submodule add https://some
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
これ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ commit 3a8461e04c04ed94a64df5d2cd7adbe764a2b8d8 Author: bigwheel <hogehoge@gmail.com> Date: Tue May 2 02:50:19 2017 +0900 Fix Process output method 同僚に「ちょっとそのコミットのこれ、slack DMで送ってー」なんて言うとき、あると思います。 これをなんと呼ぶか。 自分はコミットハッシュないしコミットIDと呼んできましたがどうやら正しい呼称ではなさそう。 先に結論 Git manual的には コミットのSHA-1 ないし コミット(オブジェクト)?の(オブジェクト名|SHA-1)が正しい。 もしくはPro Git - Bookには以下の表現もある。 コミッ
このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ
自前のブログからの転載。 (Qiitaにスライドってどう載せればよかったんだろうか。) このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO'Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェ
Steins;GitはSteins;Gateを用いてGitを解説する薄い本です。 Steins;GitはSteins;Gateの二次創作物です。そのため貢献をする前に次に挙げるページを読み、これらに遵守した形で貢献をしていただけるようお願いします。 著作物転載ガイドライン｜ニトロプラスNitroplus 二次創作活動における同人誌等の活動に関する取り扱いについて｜ニトロプラスNitroplus Steins;Gitの執筆方針について Steins;Gitは「Gitの使い方を、Steins;Gateの世界観を使って説明する」書籍です。「Steins;Gateのストーリーの流れに沿って、Gitの説明をする」書籍ではありません。 簡潔に書くと「シュタゲ本」というよりは「技術書」よりです。とはいえ、なるべくSteins;Gateを絡めていきたいですし、全体の雰囲気もSteins;Gateっぽくした
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 （Windowsの場合、msysgit は標準で入ってます） contrib/completion/git-completion.bash - GitHub インストール方法（引用） # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
この記事はGit Advent Calendar / Jun.27日目の記事です！ 26日目はhoshina85@githubさんの横着で神経質な私とあなたに贈るgit add -pでした。「Adventってなんなの？」って方は、Wikipediaの解説をご覧下さい。 特定の文字列を変更したコミットを探し出す テンプレの張りつけが終わったところで改めましてこんにちわ、実用Gitの訳者の一人、hirataraです。 7/1の江頭2:50さんの降誕を待ち望むAdventの期間も残り4日間となりました(残り3日間の担当者募集中です！)。今日はGitでつるはしを使って過去の遺物を掘り起こす話を書こうと思います。 つるはしとはpickaxeのことです。pickaxeはgitのサブコマンドではありませんが、gitglossaryやgitdiffcoreのドキュメント中で言及されていたり、diffcor
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
zsh で Git 使ってる人はプロンプトにブランチ名とかを表示してる人も多いと思う。 zsh に標準で入ってる vcs_info っていうのを使うとだいたいいい感じにできるんだけど、できないことも当然ある。 例えば stash した数の表示には対応していないので、自分で無理矢理な感じで Git コマンドを呼び出してプロンプトに表示してる人もいると思う。 でも zsh 4.3.11 ぐらいから vcs_info に Hooks というのが追加されて、元の機能に自分で処理を追加できるようになってる。これを使うと好きなようにカスタマイズできるようになるので紹介する。 この記事でできるようになること こんなことがプロンプトに表示できるようになる。 使用しているバージョン管理システムの名前(svn, git, hg, ...) 現在のブランチ名 マージ失敗のエラー表示 さらに Git の場合は以下
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
# !/bin/bash if [ -z "$1" ]; then echo "Error: Specify a path to the submodule directory" 1>&2 exit 1 fi if [ ! "$(pwd)" = "$(git rev-parse --show-toplevel)" ]; then echo 'Error: Run again after: cd "$(git rev-parse --show-toplevel)"' 1>&2 exit 1 fi git config --remove-section submodule."$1" || exit 1 git config --file .gitmodules --remove-section submodule."$1" || exit 1 git rm --cached "$1" || e
Syncing a fork branch from the web UI On GitHub, navigate to the main page of the forked repository that you want to sync with the upstream repository. Above the list of files, select the Sync fork dropdown menu. Review the details about the commits from the upstream repository, then click Update branch. If the changes from the upstream repository cause conflicts, GitHub will prompt you to create
ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回 を自動化したもの」と考えられる（適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない） 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
