(追記) 下記の問題点は、1.5で修正される予定とのことです。 (追追記) 濁点付きの検索はできないようですが、ログの問題は修正されていました。v1.5.3で確認。 SourceTree の UI は最高に素晴らしく、これまで見たどんなバージョン管理アプリケーションと比べても、次元が違う洗練されたユーザエクスペリエリンスが約束されており、有料になったら絶対買うんですが、いまは無料なので本当に感動的です。 Free Mac client for Git, Mercurial and SVN - Atlassian SourceTree Git、Mercurial 対応 DVCS Mac クライアント | Atlassian 日本語サイト Mac App Store - SourceTree (Git/Hg) Mac App Store でも一つだけ問題があって、、まともなコミットログが書けな
Pro Gitから図を引用すると、こういう 場合に、分岐した時点のmasterとexperimentの先っちょのlogやdiffをみたいというお話です。実際的には、topic branchをmasterにマージする前に変更点を確認したいといった局面です。 log logの場合は「..」です。 $ git log --pretty=oneline master..experiment ec8428d4d1884d3413e0949603c0c5cdd8aef414 D 863f5738a395fe090afaeaa120b67c45d65131c4 Clogにおける「..」についてPro Gitから引用すると、以下のように書かれています。 これは "experiment からはたどれるけれど、master からはたどれないすべてのコミット" という意味です。 Git - リビジョンの選択 一
ブランチが大量にあると、git branch の結果を最終更新時間でソートして表示したくなりますよね。以下のワンライナーでできます。 (for i in `git branch | colrm 1 2` ; do echo `git log --date=iso8601 -n 1 --pretty="format:[%ai] %h" $i` $i ; done) | sort -r git branch を最終更新の日付でソートするオプションがほしい Kazuho Oku on Twitter: "git branch を最終更新の日付でソートするオプションがほしい" ってツイートしたら、@likk さんに、 @kazuho https://gist.github.com/Likk/9af89b10fd0008df91ad … ワンライナー書いたのでこれをgitのエイリアスに。 永遠に靴紐
以前カーネル開発で vc-modeを onにしたままやっていたら、バックグラウンドで ごにょごにょしすぎて、まともに使えるか!!、ってなってそれ以降ずっと offに していたんですが、さすがにブランチ情報がないと branch切ったときの確認に 手間がかかるなぁってことで、表示するようにしてみました。 CVS, subversionとかもう使わないんで、git対応だけです。 ついでに今リポジトリ内にいない場合もその情報を表示するように しています。 コード ;; Show Git branch information to mode-line (let ((cell (or (memq 'mode-line-position mode-line-format) (memq 'mode-line-buffer-identification mode-line-format))) (newcd
絨毯爆撃pushの例 いまmasterブランチに、未プッシュのコミットがあるとします。 ここで、新たにbr1ブランチを作ってチェックアウトします。 $ git checkout -b br1 master $ git branch * br1 master br1ブランチでコミットを作ります。 echo hello >> hello.txt git add . git ci -m "add file" 引数なしでプッシュします。 git push すると、どこに何がpushされると思いますか? 実は、master -> masterにpushされます。 masterがまだpushできる状態でない場合、これはかなり痛い。すごく痛い。頭が頭痛でおなかが腹痛。 しかもpushしたかった当のbr1ブランチはpushされないというオチ。(リモートにbr1ブランチがない限りは) この挙動は大半のユーザ
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 22 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Technical Side" このポストは、エンタープライズ開発のバージョン管理を Git に切り替えることに注目した連載記事(全三回)のうちの第二回目として、 Dr.Dobb's で紹介されました。最初の記事では、 今日、これほど多くのチームが切り替えを決断している理由 について議論しました。今回の記事では、アトラシアンが行った Git への切り替えにおける技術的な側面に焦点を合わせています。 この三部からなるブログシリーズでは、アトラシアンが行
1) Gitlab was chosen as an alternative to GitHub Enterprise due to its web UI, pull request functionality, and the fact that it could be maintained by GREE Tech's 80 Ruby engineers. 2) The company transitioned from Subversion to Gitlab by using git-svn to allow cross commits between the two systems during a period of combined use. 3) The speaker felt pull requests promoted a better development cul
gitで外部リポジトリを取り込んで利用するには、submodule(サブモジュール) とsubtree merging(サブツリーマージ)の2手法があります。 私の観測範囲内では、サブモジュールはよく利用されていますが、サブツリーマージは目にしません。 そこで、サブツリーマージを試してみての使い分けや思ったことをつらつらと。 大雑把な要点を最初に書いておく 外部リポジトリを外のものとして取り込むならサブモジュール 外部リポジトリを取り込みつつ、中のものとして手を加えていくならサブツリーマージ git初心者にはサブモジュール(異論ありそう) サブツリーマージ使ってみた github.com/marutanm/dotfiles 中身としては、よくある環境設定ファイル一覧です。 前提として、 tmux.conf(gistにおいていた) vim設定(githubにおいていた) zsh設定(gith
# master 上で git merge するときは常に --no-ff git config branch.master.mergeoptions "--no-ff" # git merge するときは常に --no-ff(1.7.6以降) git config --global merge.ff false ## あわせて設定しておくと吉 # master 上で git pull するときは常に rebase git config branch.master.rebase true # git pull するときは常に rebase(1.7.9以降) git config --global pull.rebase true # git pull するときは常に rebase(1.8.5以降) git config --global pull.rebase preserve
ここでは newSetting が新しい設定項目だと思ってください。 この時、もともとの設定項目 path が存在していますが、 これが動作確認に必要な項目で ローカル特有の設定値に変更していたとしたらどうでしょうか? add 前にリポジトリの内容に戻しておかないと、 このローカル用設定のままコミットされてしまいます。 こんな時に使えるのが magit の部分 stage です。 使い方はいたって簡単です。 編集が完了した状態で magit-status を実行します。 magit での git 操作画面が開きますので、部分的に stage したいファイルにカーソルを合わせます。 この状態で M-s (alt+s, Cmd+s, Opt+s)をタイプします。 するとファイルリストの下部に Diff が表示されます。 この Diff 上でリージョン選択して s をタイプすると、 リージョン選
gitの--word-diffなどは時々使うことがあると思いますが、さらにその出力を少しアレンジした方法が以下のgit diffオプション。 $ git diff --color-words --word-diff-regex='\\w+|[^[:space:]]'使いたい場面はあまり多くない気はしますが、主な用途としては、テキスト(HTML含め)の変更のdiffを見るときに使うと見やすいことが多いかと思います。 他では変数や文字の置換など、同じパターンの変更を大量にしたときなど。 以下、railsのドキュメント変更のコミットのdiffを見比べた例 $ git diff --color-words --word-diff-regex='\\w+|[^[:space:]]' 7a0dad2^..7a0dad2 $ git diff 7a0dad2^..7a0dad2 $ git diff -
この投稿はEmacs Advent Calendar 2012の14日目の記事です。 (Qiita で行われています) "Emacs Advent Calendar 2012 - Qiita" - http://qiita.com/advent-calendar/2012/emacs 導入 みなさん、 git つかってますか? git を使ってらっしゃる方はコマンドで操作している方が大半だと思います。 そこで Emacs をお使いのみなさんにお勧めするのが 今回のテーマの magit です。 magit って? Emacs から git を操作するための elisp です。 magit/magit · GitHub - https://github.com/magit/magit インストールには el-get を利用すると便利です。 M-x el-get-install → magit
gitを使ってバージョン管理を行う際に、プロジェクト全体のツリー構造をそのまま管理する目的で、中身が何も無いディレクトリもgitの管理下に置きたい場合があります。 何も対応しないと、gitは空のディレクトリをバージョン管理してくれません。 中身が空のディレクトリをgitのバージョン管理下に入れるためには、当該の空ディレクトリの中に .gitkeep というファイルを作成してからgitで管理します。 実例 Railsのアプリケーションを新しく作成する場合を例に用います。 $ rails new test_application $ cd test_application $ ls -l vendor/plugins (vendor/pluginsは中身が空なので何も出力されません) 上のように、vendor/pluginsは中身が空です。 このディレクトリをgitの管理下に入れるために、次の
gitを使っていて、「pushしたはずのコミットがいつのまか消えた!」という話をよく聞く。はじめて遭遇すると、「あれ?コミットしたはずのコードが消えてる!今日の作業が台無しに!」と思って焦ってしまう。この記事ではそれの原因とgit reflogを使った対処法を紹介する。 なぜ起きるのか? gitにはブランチがあり、ブランチごとにコミットを記録できる。gitのリポジトリの作業領域は現在のブランチのものだ。例えばgit branchで確認すると現在のブランチを確認できる。 git branch * masterなんらかのブランチで作業するのが普通だが、現在の作業ブランチがno branchの状態になってしまうことがある。これは、コミットのハッシュIDを直接checkoutしたり、リモートのブランチを直接checkoutした時に起こる。そのときには以下のような警告が起きる。 $ git chec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く