git statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main You
複数ブランチの同時並行作業にはGit Worktreeを - astamuse Lab
猫より犬好きプログラマのにゃんです。主な仕事はマサカリの投擲とベランダに来る野良猫の餌やりです。よろしくお願いします。 皆さんバージョン管理システムを使ってますか？今では多くの現場でGitを使っていると思います。ゲーム開発など巨大なバイナリのアセットが多い現場ではGitではなくプロプライエタリのPerforceを使用されているかもしれません。他にもGitと同時期に開発されたMercurialというツールもありますが、いずれにせよ現在のdevシーンではバージョン管理システムはあって当たり前のツールの一つになっています。 弊社ではGitを使っています。Gitは機能豊富ですがその分知られていない機能も多く、ネットを見渡せば色々な記事が転がっていますが、今回は私も一つGitの便利機能を紹介したいと思います。 worktreeで複数の作業ディレクトリを作る 複数のブランチを同時並行で修正したくなった
gitのdiff-highlightを使い始めた - りんごとバナナ
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
2014年、春のGit事情 - fujimuradaisuke's blog
なんとなく最近どんな感じで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 バージョン管理しているファイルのファイルパスを表
「開発効率をUPする Git逆引き入門」を読んだ - 元RX-7乗りの適当な日々
いまやバージョン管理システムの代名詞になったといっても過言ではないだろう、Git。 そんなGitの逆引き形式の入門書を、著者/出版社の方々からご献本いただきました。ありがとうございます！ 開発効率をUPする Git逆引き入門 作者: 松下雅和,船ヶ山慶,平木聡,土橋林太郎,三上丈晴出版社/メーカー: シーアンドアール研究所発売日: 2014/04/09メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る 本書を開けてパラパラとめくってみると、まず、おっ！と思うのはその図説の多さ。最初の方だけ、とかではなく終始図説が多く、読みやすそうな印象を受けます。 1章に、Gitの概要や仕組み、流れが最低限わかりやすく記されている他は、基本的にやりたいことベースで説明されている逆引き形式となっていることが特徴的です。 目次を眺めてみると、これまでGitの使い方がよくわからなくて、一度
gitで特定のファイルの履歴を消す方法 - ichhiの日記
$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch targetfile' HEAD これで、特定のファイルtargetfileの履歴を消去できる。 特定のディレクトリは $ git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch dir' HEAD で特定のディレクトリdirが消える。-rオプションを忘れずに。 後は、コミットするだけ。 $ git commit -m 'delete targetfile' リモートのリポジトリにもこの変更を反映させなければならない。 そういう場合は $ git push origin master --force でプッシュ。--forceを付けたのはリモートを強制的に上書きするため。
gitの特定のディレクトリをブランチ毎別リポジトリにする方法 - Qiita
baseprojectという名前のリポジトリの中にあるsubprojectというディレクトリを、別のリポジトリとして分離する方法です。 その際、必要なブランチも全部移行します。 まず新しく作るリポジトリ用のディレクトリを作ります。
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/ Graphs, Hashe, and Compression, Oh My! 登壇者：@matthewmccull Hashesについて 従来の CVCS （集中バージョン管理システム）のリビジョン番号は連番。 SVN はサーバーにデプロイした時点でリビジョン番号1と設定される。 Git は SHA1 をつかっている。40桁の16進数のフィンガープリントがついてる。これは理論上は重複しない大きさ。こうすることで単純で強固な DVCS （分散バージョン管理システム）がつくれる。 新しいファイルを追加すると、.git/objects/55/7db03de...(SHA1 finger print)
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
gitの入門用のチュートリアル"Learn Git Branching"を訳した | 48JIGEN *Reloaded*
gitの入門用のチュートリアル"Learn Git Branching"を訳した 2013/03/18 ここで公開してます。スマホからだと動かないのでPCで見てください。 http://remore.github.com/learnGitBranching-ja ChromeとFirefoxでは動作確認してます。翻訳リソースはgithubに置いてあります。 Laern Git Branchingは： グラフィカルにgitツリーを操作しながらrebaseとかmergeとかを学べる IDEA * IDEAさんとかHackerNewsとかで、1か月くらい前に話題になってた MIT Lisenceで公開されてて自分で演習問題も作れる というツール。公開されてから1か月くらいしか経ってないのに、既に中国語、韓国語、フランス語の3か国語に翻訳されてる。海外の人仕事はえーと感心しました。 春だし新人さん
GitとJenkinsを使ってChefを運用する - GeekFactory
Chefはリポジトリをバージョン管理する仕組みを持っていますが、チームでの協調作業を考えるとバージョン管理システムを使う方が運用しやすいと考えます。本稿では、GitとJenkinsを使ってChefを運用するための1つのパターンを考えます。 以下があることを前提とします。 Chef Server Chef Client Gitリポジトリ Jenkins 基本的な考え方 CookbookをGitリポジトリで管理します。開発者がgit pushすると同時にChef ServerのCookbookが更新されるようにします。これにより、GitリポジトリとChef Serverが同期されるようになります。 また、後続ジョブとして各サーバでChef Clientが実行されるようにします。ビルドパイプラインを組むことで、Staging EnvironmentにおけるChef Client、Producti
「Gitによるバージョン管理」を読んだ - 元RX-7乗りの適当な日々
著者の1人である、まえだこうへいさん(id:mkouhei)からご献本いただきました。ありがとうございます！ この本については、レビューにも参加させていただいたのですが、そのレビューの依頼の時期がちょうど2010年9月頃でしたから、さぞその時々の流れにあわせた最終段階での調整・編集であったり、完成度を高めるブラッシュアップを繰り返されていたのではないかと想像します。お疲れ様でした。 Gitによるバージョン管理 作者: 岩松信洋,上川純一,まえだこうへい,小川伸一郎出版社/メーカー: オーム社発売日: 2011/10/25メディア: 単行本（ソフトカバー）購入: 6人 クリック: 239回この商品を含むブログ (27件) を見る ご執筆開始からご出版まで3年の期間を経てヴェールを脱いだGit書籍。パラパラとめくり始めて、一見堅そうな雰囲気の本書ですが、(失礼ながら)思いの外読みやすいという点
Git管理の神ツール「Gitolite」なら、ここまでできる！
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git で "Agent admitted failure to sign using the key." と出た場合 - 元RX-7乗りの適当な日々
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳） - Qiita
GitBook – Knowledge management for technical teams
Gitの使い方あれこれ
