Pryは結構前からgithubのリポジトリを追いかけている人達には認知されていましたが、RailsCastsでも紹介されたことから、Ruby界で一気に広がりを見せています。 ちなみに発音はpra'i(ぷらい)です。英単語で「覗く」などを意味します。 今回はそんな便利なPryについて少し紹介したいと思います。 Pryはirbの代わりになるREPL Pryを一言で説明すると、irbと同様にREPL環境を提供してくれます。 では、さっそくインストールしてみましょう。
mercurialでは一度おこなったコミットは基本的には取り消せません。ブランチを作成するためにもコミットが必要なため、gitのようにカジュアルにブランチのリネームを行う事ができません。ここではそんな中でも何とかブランチをリネームするための3つの方法を紹介したいと思います。 紹介する方法 リネームしたいブランチの途中でブランチを切る。リネーム後のブランチを作成し、リネームしたいブランチをマージする。リネーム後のブランチを作成し、リネームしたいブランチをtransplantする。 リポジトリの例 次の様なリポジトリで考えていきます。bad-name-branchをadd-hginoreに変更したいです。 @ changeset: 4:a1b706bc0a8e | branch: bad-name-branch | tag: tip | summary: ignore log director
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 gitでマージ作業を中止して元の状態に戻すではマージに際してよくある問題の対処方法について紹介しました。 運用をきちんとしていればトピックブランチのマージでコンフリクトが発生することは稀です。 しかし稀とはいえコンフリクトが発生するときは発生します。 例えば新機能Xの実装を始めるとしましょう: $ git checkout -b topic-x master $ $EDITOR $ git commit -am 'Fix outdated comments' $ $EDITOR $ git commit -am 'Revise existing API' $ $EDITOR $ git commit -am 'Implement X' o---o---o <- topic-x / o---o---o <- m
@ 2:d9ae2b51cade | head b | default | | o 1:8141de67f6ee | head a |/ default | o 0:6af850d9f57f | initial commit default 図1. defaultブランチがマルチプルヘッド(先端(HEAD)が複数存在している状態) マルチプルヘッドは hg merge でマージして一つのヘッドに統合してからpushするのがマナーですが、push -fで強制的にpushすることができてしまいます。 [troter:~/tmp/multiple-head] % hg push pushing to /home/troter/tmp/central searching for changes abort: push creates new remote head 8141de67f6ee! (d
前回[@kana1さん](http://twitter.com/kana1)による[「gitでアレをもとに戻す108の方法」](/tech/git-undo-999)が大反響で世間はやはりgit使いが多いのかと再認識しました。 私も普段はgitを使っていますが、お仕事ではMercurialを仕事で使っているのでのっかって書き連ねてみましょう。 ### 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いていくつかコミットした。でももういらない さて初っぱなから行き詰まりそうです。基本的にMercurialは「コミットを積み重ねたものを後から編集する」ことに弱いのです。 MQを使って解決してみましょう。 $ hg update -r {revision} $ hg qimport -r {revision+1}:tip $ hg qpop –all $ hg qseries |
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Mercurialは、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く