git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20～60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total

本項はChefConf 2013: Beginner Chef Antipatternsを和訳したものです。 はじめに よく Chefの学習は大変 Chefの学習曲線は急勾配 と言われているので、Opscodeでは緩和するためのコンテンツを色々準備しています。 learnchef.com docs.opscode.com パブリック/プライベート トレーニング Podcasts (Food Fight Show など) 各地のユーザグループ (訳注: 日本なら #opschef_ja ) ChefConf! (訳注: これは ChefConf 2013 で行われたセッションなので) それでも、正しいことをやっているのか知るのは難しく、何か間違ったことをやっているのか知るのはさらに難しいものです。コミュニティの中で「ベストプラクティス」は常に進化してきました。 ベストプラクティスについてもっ

CLIで操作する際に、Gitコマンドをタブキーで補完できるようにする方法をメモしておきます。 Gitをインストールしただけでは、タブキーでコマンドを補完することはできませんが、実は設定ファイルはインストールの際に準備されており、それを使うことで簡単に有効化することができます。その設定ファイルというのが git-completion.bashです。環境によってパスは違いますが、例えば以下のような感じです。（Bash以外については調べきれていません） CentOSにGitをyumでインストールした場合 /usr/share/doc/git-1.7.1/contrib/completion/git-completion.bashMacにGitのサイトからdmgをダウンロードしインストールした場合 /usr/local/git/contrib/completion/git-completion.b

2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト

先日突然会社で使ってる Jenkins が起動しなくなってしまいました。さすがにもう二度とそんな思いはしたくないので、バックアップを取ることにしました。 Backup Plugin - Jenkins - Jenkins Wiki を使ってもいいんですが、git 使えば差分バックアップになるし、好きな時点に戻せて素敵なんじゃないかと思って git を使ってバックアップを取ることにしてみました。 この記事はその時のメモみたいなものです。 リポジトリの作成 まずは git のリポジトリを作ります。せっかくなのでスクリプトコンソールを使ってみます。スクリプトコンソールを開いて、以下を実行します。 dir = System.properties["JENKINS_HOME"] def git = { Object[] cmd -> println new ProcessBuilder(["git"

Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

20110730_Redmineでのタスク管理を考える勉強会＠大阪 第１回 (2011/07/30) - RxTstudy https://sites.google.com/site/rxtstudy/home/20110730 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/07/redminefaq-rxts.html RxTstudy Redmineでのタスク管理を考える勉強会＠大阪 - Togetterまとめ http://togetter.com/li/168362

適宜追加します。 Pro Git 僕が読んだ Git の書籍の中では、一番分かりやすいと思いました。日本語版の書籍はありませんが、オンライン版が翻訳されています。 Pro Git 図解 Git Git の初心者が動作を理解するのにおススメ。 図解 Git こわくない git ブランチとマージの考え方がよく分かるスライド(@methaneさんから教えて頂きました)。 こわくない git あなたの知らないGit Tips 書籍には載ってない Tips の解説。知らないと損するかも。 あなたの知らないGit Tips ワークフロー、あるいはブランチング チームでブランチを使う際の取り決め。自分のチームで一から議論するより、すでにあるものを参考にしましょう。 git-flow github-flow Github Enterprise Github Enterprise は、企業内に設置して使うこ

Mar 22, 2013657 likes445,048 viewsAI-enhanced description The document outlines various Git commands and their usages, including initialization, adding files, committing changes, and managing branches. Key actions include committing with messages in Japanese, removing files, resetting changes, and checking out branches. It also describes the process of cloning repositories, fetching and pulling up

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

さくらのVPS+Jenkins+github+rails3の続編。 ゴールは、githubにpushすると、さくらのVPSで動いているJenkinsがgithubから最新ソースひっぱってRobolectricのテストかけた上に、apkを作るところまで。 プロジェクトの作成 mavenプロジェクトにしてみた。 ユーザーの作成 以前作ったやつで兼用。 SSH key コレも兼用しようと思ったらダメだった。１リポジトリにつき１keyだそうで。 https://help.github.com/articles/error-key-already-in-use Once a key has been attached to one repo as a deploy key, it cannot be used on another repo. If you're running into this

"3 superstitions concerning git rebase" In-house training material at Cybozu.

皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン

いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE

はじめに git commit するまえに考えるべき10のこと | Act as Professionalを読んでいろいろと思うことがあったので書きました。 これはSCMBootCamp主催者としてとか、Mercurialユーザーを代表してとかではありません。 僕はこう思う。ということです。 読むの面倒な人は最下部のまとめだけ読めばok。 commit != push DVCSの利点はローカルコミットという概念を持ち込んだことです。これにより、高速な履歴追加、安全なマージを手に入れることができました。 件の記事を読んでいて気になったのは、commitという単語です。 特に、 1コミットに1つの対応 コメントアウトしたコードをコミットしない テストが正常に通過したものにしてください コミットメッセージの1行目は”短い説明” コミットメッセージのスタイル コミットメッセージのボディは有意義な内