つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
_ Windowsで楽勝にgitを使う方法 (2012/3/4注：このエントリーは正確には、『Windowsで楽勝かつクリーンにgitをインストールする方法』です。楽勝な使い方については、『デザイナーのためのgit』を読むと良いでしょう） まだすべてのコマンドを試したわけではないけど、次のようにすれば、わずか数クリックでgitが使えるようになる。しかも、Windows環境の汚染も目に見える限りは無い。 1) Heroku Toolbelt for Windowsをダウンロードする。 2) インストールする。この時、既定のインストール先はc:\program files\Herokuになっているが、当然、そのままにしておくこと。 3) インストールが完了したら、「スタートメニュー」－「すべてのプログラム」－「Ruby 1.9.2-p290」（このフォルダはおそらくバージョンアップによって変わ
gitでは様々な方法でコミットログを書き換えることができます。 その一例として誤ったブランチに対して行った変更を正しいブランチへ移す方法を紹介します。 問題 これまで「新機能Xを追加する」という設定で以下のトピックについて解説していました: gitでコミットの順序を入れ替えるgitで複数のコミットを1つにまとめるgitで1つのコミットを複数のコミットに分割する これにはまず としてこの作業用のトピックブランチを作成してそちらで作業を行うのが普通です。 しかし git branch を実行したところで安心してしまい、 git checkout を忘れて全く違うブランチで作業を行ってしまう というミスは時々やってしまいます (git checkout -b という方法もありますがここではそれも忘れていたとしましょう)。 例えば以下のような状況だったとしましょう: $ git branch ma
git add を実行あとで修正していなかった部分に気づいてしまった場合や、 「git add .」で間違って.swpとかのバックアップファイルがステージングに入ってしまった場合に、 git addをキャンセルする方法です。 コマンドの構文 ファイルをキャンセルする場合 git rm --cached ファイル名 ディレクトリをキャンセルする場合 git rm -r --cached ディレクトリ名 git rmは、Working Tree (作業コピー)と index からファイルを削除するコマンドですが、 --cachedを指定する事で、 indexからのみファイルを削除する事ができます。 http://blog.s21g.com/articles/960 指定する、ファイル名やディレクトリ名にはワイルドカード(*.swp等)が使用できます。 間違って要らないファイルをgit addし
Setup ----- git clone <repo> clone the repository specified by <repo>; this is similar to "checkout" in some other version control systems such as Subversion and CVS Add colors to your ~/.gitconfig file: [color] ui = auto [color "branch"] current = yellow reverse local = yellow remote = green [color "diff"] meta = yellow bold frag = magenta bold old = red bold new = green bold [color "status"] add
流行っているみたいなのと，WindowsでもCygwinで使えるようなので，WindowsでGit用サーバを立てて，色々な管理に利用してみようとした．が，さすがWindows．結構面倒だったので備忘録としてメモメモ．環境Windows XP Pro SP2CygwinGitのインストールCygwinのsetup.exeのdevelからgitを選んでインストール． adminのcygrunsrvもインストールする． netのinetutils，opensshもインストールする．CygwinのbinディレクトリへのパスがPATH(システム環境変数)に含まれているようにする． 公開用リポジトリの作成 適当なディレクトリで "$ git init" 適当なファイルを置いたら， "$ git add" をして "$ git commit" 上のディレクトリに移動して，"$ git clone --b
今まであるプロジェクト内の別ファイルへの移動にはanything-project.elというのを使っていたのですが， ファイルが多いプロジェクトだとちょっと遅い .gitignoreで指定しているファイルも表示される もうちょっといい感じに表示してほしい バージョン管理システムの情報を使っていい感じに並べてほしい という不満があったのでgit用の同じようなものを書きました． List up all files under the control of git and do something (open/view/delete/etc) with them — Gist Modified filesとUntracked filesは毎回更新してるので，ネットワーク越しとかだと重いかもしれません． git使ってる人なら普通に便利だと思います．どうぞ．
RubyDropはRuby製のオープンソース・ソフトウェア。個人的にDropboxはとても便利に使っている。これなしの生活は考えられないくらい便利だ。有料であれば50GBまで使えるが、無料版の2GBでは物足りないと感じる人も多いだろう。だがお金は払いたくないという人もいるだろう。 サーバ起動中 そこで考えたいのが自分だけのDropbox構築だ。重要なのは自動的に同期されるシステムであること、バージョン管理されること、複数のコンピュータ間でデータが同じ状態に保てることだろう。それらを実現するのがRubyDropだ。 RubyDropはRuby1.9系で動作するソフトウェアだ。簡単に言えば、特定のフォルダに関してRubyDropが監視を行う。そして変更があると内容をリモートのGitリポジトリにアップデートする。Gitリポジトリ側で変更があれば、Pullする仕組みだ。 自動的に同期されている G
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
EmacsとGitとを用いて開発してる際、たとえばgit checkoutした後、実際のファイルとバッファが不整合な状態になって、revert-bufferしないまま保存しようとすると「ファイルが変更されてるけど、どうすんの?」とかいわれて鬱陶しい。しかも、auto-save-buffers-enhancedしてたりすると、それが延々とまらなくなって、ものすごく大変なことになったりする。 いままでいちいちrevert-bufferしてたのだけど、明らかにあほっぽいなと思ったので、どうにかならないか調べてみたところ、こんな感じでauto-revert-modeを使ってやるとよさそう。なんらかのvcの管理下にあるかどうかを`vc-backend'で調べるのは、もっとちゃんとしたやりかたがありそうだけど。 ;; ↓こいつをnon-nilにしておくと、vcsによる変更もチェックしてくれる (set
メモやちょっとしたスクリプトなどをペーストするとgitのリポジトリとして管理してくれるgistというサービスがあります。そのgistにコマンドラインから投稿するツールがあって、それは前に少し紹介したんですが、それをもうちょっと便利にしたものを作りました。 swdyh's gisty at master ― GitHub http://github.com/swdyh/gisty/tree/master gistコマンドとの違いはこんな感じです。 ポストするときにファイルを指定。ファイル名、拡張子つきでアップされる。 ポスト時に複数ファイルを指定できる。 ポスト後、ブラウザで開く。(Macのみ) ポスト後、ローカルにcloneする。 過去のgistにアップしたのを全部のclone、またはpullする機能 gistyを使うと簡単にファイル名と拡張子つきでポストできて、そのままローカルにclon
เนื้อเพลง Young, Wild and Free เนื้อเพลง Young, Wild and
Web+DB Press 50号に載ってるGitの特集がすごくわかりやすかった． で，まあ，ただ読んでると頭に入ってこないから頭に入れたいところだけメモ． git add インデックスに追加する系． インデックスは，次のコミットでコミットする変更を記録したもの． git add <paths> <paths> をインデックスに追加 git add . 現在のディレクトリ以下のすべての変更ファイル/新規ファイルをインデックスに追加 git add -u インデックスから変更されてるファイルの変更をインデックスに追加 git add -A -u + 新規ファイル git add -p たとえば index.html の変更箇所(hunk)が2つあったとしたら， その2つのうち片方だけをインデックスに追加みたいなことができる（対話形式で） git commit コミットする系． git comm
clmemo@aka: Git remote repository と Branch
Git のリモート・リポジトリーでブランチを操作する方法についてメモ。 リモート・リポジトリーに新しくブランチを作成する リモート・リポジトリー foo に新ブランチ bar を作る方法。git push コマンドを使う。 $ git branch master * bar $ git push foo bar カレント・ブランチの名前を git push に渡すと、リモート・リポジトリーに同じ名前のブランチが新しく作られる。 ブランチの名前を変えたい場合? 「ローカル・ブランチ名:リモート・ブランチ名」の書式でブランチを指定する。例えば、上の例で (bar ではなく) hoge ブランチをリモートに作る場合はかうなる。 $ git push foo bar:hoge この「bar:hoge」の部分を refspec と呼ぶそうな。 リモート・リポジトリーのブランチを削除する リモート・リ
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 git でファイルの復活 コミット後に勢いよくリファクタリングするも途中で挫折 p なデバッグコードを埋め込んでいくも修正箇所を忘れた なんてとき、指定した一部のファイルだけをコミット後の綺麗な状態に戻したいときがある。 svn の場合 svn は楽だった。消して update するだけでよかったから。 具体的には、モデルを全部戻したくなった場合は % rm -rf app/models % svn update で楽に復旧できる。 git の場合 でも、git では fetch しても削除ファイルは華麗にスルーされて困っていた。 git は超便利だが、ここの一点で svn の方が使いやすいと思っていた。 が、checkou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メモcache: gitの概念図