特技はgit commit -a -m いろいろ修正です！ ダメ。ゼッタイ。 しかしこまめにコミットするのは面倒臭いですよね。でもrebaseやらrevertやらcherry-pickするにもコミットログは綺麗にしたい。そんなズボラで凝り性なあなたはgit add -pでコミットを整えるといいと思います。

前回は Git subtree merge について説明しましたが、今回はそれに深い関係がある Git subtree コマンドについての説明です。 まず基本的なこととして、 Git subtree は Git subtree merge と同じものではありません。 subtree merge はマージ戦略として subtree を指定したマージにすぎませんが、 Git subtree は明確に外部ライブラリの取り込みと submodule の代替を目的として設計された機能です。 Git 1.7.11 以降であれば、 Git subtree を使用するのが望ましいでしょう。 なぜなら、 Git subtree には、 Git subtree merge にはない、下記のような機能があるからです。 取り込んだライブラリ側の歴史を"潰し"(squash)てコンパクトな歴史にできる。 自分のプロ

読者の皆さまが普段使っているバージョン管理システムは何でしょうか？多くの会社さんと同様、KLabでは大多数のプロジェクトでGitを利用しています。 Gitでは全てのcommitについて名前とメールアドレスが記録されます。ところで、Git管理しているリポジトリ上で会社のメールアドレスと個人のメールアドレスが混ざることがありませんか？ KLab社内では大半のプロジェクトでGitHub Enterpriseを利用している一方、一部プロジェクトや公開用のリポジトリについてはgithub.comも併用しており、それぞれで登録メールアドレスが異なっていたりするため、間違いが起こりやすい状況になっています。 本稿では、そんなときでもリポジトリごとに適切なメールアドレスでcommitできるような~/.gitconfigの書き方を紹介します。 具体的な手順 今回紹介する手順は、リポジトリをgit clone

config_param :queued_chunk_flush_interval, :time, :default => 1 を追加したコミットがどれかを探したいとします。 しかし、git blame を見るとこんなかんじに、インデントコミットによってほぼ全ての履歴が上塗りされていてどれだかわからない、みたいな状況にどうやって真犯人を探そうかという話です。 1. git blame -w を使う インデントコミットを無視したいだけであれば git blame の -w オプションが使える。-w は比較の際に whitespace を無視してくれるオプション。git diff にもあるよね。 $ git blame -w lib/fluent/output.rb ... (省略) 14d01c71 (Masahiro Nakagawa 2013-03-27 03:56:51 +0900 1

なんとなく最近どんな感じで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 バージョン管理しているファイルのファイルパスを表

皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな

detached HEADって言う名前で入門Gitにも書いてあるんだけど、そういうことが起こりうるってメンタルモデルができてないと起きていることにすら気づかないので書いておく。 まず説明用のリポジトリを用意します。 t$ git init Initialized empty Git repository in /Users/nishio/gittest/pygit2/t/.git/ t$ touch a t$ git add a t$ git commit -m "add a" [master (root-commit) 6f6eb7c] add a 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a t$ touch b t$ git add b t$ git commit -m "add b" [m

はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ

git current-branch, git fetch-pulls, git pull-dry-run など git alias ネタGit

GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe

2012-08-20一部訂正 githubにdotfile上げてる人は結構多いですが、 github.tokenなど、一部の設定は公開されると困りますね。 そんなときはincludeディレクティブを使うとローカル用の設定を別ファイルに出来るので捗ります。 [include] path = .gitconfig.local [core] editor = emacs pager = lv whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol excludesfile = .gitignore こんな感じでやると.gitconfig.localを読み込んでくれるので、 github.tokenなどは.gitconfig.localに書いておくといい感じになって捗ります。 参考： http://stackoverflow.com

直前のコミットをやり直したいときは、git commit --amend を使うと可能だ。そして、さらに昔のコミットをやり直す(書き換える)ときは、git rebase -i を使う。 git rebase -i を使うと、引数にとったコミット以降のコミット系列に対して、コミットの書き換え、削除、統合を行うことができる。 次の課題をこなすことを目標としながら、git rebase -i の動作を追っていこう。 課題「最新のものから古いほうへ3つ分のコミット(HEAD, HEAD~1, HEAD~2)のログメッセージを書き換えたい」 git rebase -i の起動 まず、変更したいコミットで一番古いものより一つ古いものを引数にして、git rebase -i を実行する。この場合は HEAD~3 である。 $ git rebase -i HEAD~3 すると、エディタが rebase コ

以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗

Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi

Gitの取消練習 Gitで「間違えた」「こうしておけば良かった」と思った時の対処方法を覚えましょう。 準備 作業ディレクトリとしてC:\workディレクトリを使うことにします。 C:>mkdir c:\work C:>cd c:\workここに「readme.txt」「password.txt」の二つのファイルを作っておきます。 C:\work>notepad readme.txt C:\work>notepad password.txtreadme.txtは次の内容にします。 This is my readme file.password.txtは次の内容にします。 My password is JugemJugem.initを取消しましょう。 カレントディレクトリをgitリポジトリにします。 C:\work>git init Initialized empty Git reposito