【Emacs本を書きました】 gitはブランチが強力です。 ブランチは単なるポインタなので、gitではブランチの積極的な利用が推奨されています。 トピックブランチ特に「トピックブランチ」は便利なブランチ利用法です。 作業前に特定の作業用のブランチを切り、無事に実装できたらmasterにマージ（リベース）し、ブランチを削除する方法です。 トピックブランチを切ることで、現在の目標を明確にすることができます。 また、緊急の修正をする場合はあわてずに一旦masterに戻って修正し、再びトピックブランチで作業することができます。 トピックブランチについては http://progit.org/book/ja/ch3-4.html が詳しいです。 トピックブランチを作成するnewtopicとういう名前のトピックブランチを作成するには、以下のコマンドを使います。 $ git checkout -b ne
『Rails のプラグインを subtree として管理する - ドレッシングのような』の続きです。 この記事を書いてから数ヶ月後、導入していたプラグインをアップグレードする機会があって、subtree マージが役立つ時がやって来たのです。 ・・・ところが、何度やっても subtree マージが上手く行かない。いろいろ試してマージできたと思ったら、マージ元ブランチの全履歴がコミットされて悲惨な状況になったり。 で、私のお仕事の目的は残念ながら git で subtree マージを実施することではなかったので、泣く泣くアップグレードによる変更をパッチとしてマージしてコミットしました。 余裕が出てきたら、追試をして正しい事を明らかにしてみたいです。 git は難しいけど楽しいですね♪ (追記: 2010.07.12)某IRCチャネルで、すごい回避策が生み出されました。 12-17:21 iwa
(2010.02.05 追記) read-tree する前に ours ストラテジで merge しなきゃダメだったようなので、その手順を追加した。 下のエントリではプラグインを submodule として管理する方法をメモした。 今回扱っているリポジトリは僕だけでなく他社の人 (それも git に慣れてない人) と一緒に弄るものなので、submodule を使うと clone するところから大変なことが分かった *1。 そこで、submodule の代わりに subtree merge と呼ばれる方法を採用することに変更した。これは、プラグインのリポジトリをブランチの中で管理し、master ブランチへ read-tree というコマンドでマージする方法。 restful_authentication を例に説明する。まず、本家を remote リポジトリとして追加する。 $ git r
例えば、以下のようなコミット履歴があるとします。 A---B---C---D masterここで git rebase -i HEAD~3 をして、 コミットB を E に書き換えたくなったとします。このとき、rebase -i によって履歴を書き換えてしまうと、以下のようにリポジトリからB〜Dのコミットは消滅してしまうと思っている人も居るのではないでしょうか。 A---E---C'---D' master確かに、Gitがこのような動作をするのであれば、rebase後に元の状態へ戻すことは到底困難であるように見えます。しかし、正確に書けば、実際のレポジトリの状態は以下のようになります。 E---C'---D' master / A---B---C---D実はコミットA〜Dの一連のコミットは手つかずで残っており、「master」というラベル*1が新たな枝に付け替えられただけなのです。よって、
こんにちは。murahashiです。 gitやgit-svnを使うにあたり、試したことや引っかかったことについて、yukiのエントリ ウノウラボ Unoh Labs: subversionリポジトリでもgitが使えるgit-svn のつづきを書いてみました。 Q. ブランチ名を長くしてしまったので手打ちするのが大変です A. bashでgitコマンドを補完します gitのコマンド補完は git-completion.bash が便利です。 fedoraにyumでgitを入れた場合には下記場所にあります。 /usr/share/doc/git-VERSION/cntrib/completion/ 自分の見える場所にgit-completion.bashがなければ、インストール済みのgitと同じversionのgitのソースをダウンロードします。 cntrib/completion/
> According to specification > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) > should return success but currently it did return ELOOP. Fix the code to ignore > O_NOFOLLOW in case the provided path has trailing slashes. This is a regression > caused by path lookup cleanup patch series. > > CC: stabl[email protected] Hmm? Is this correct? Isn't the bug introduced in this merge window, and thus n
A recent post that was highly ranked on Hacker News complained about common git workflows causing him serious pain. While I won't get into the merit of his user experience complaints, I do want to talk about his specific use-case and how I personally work with it in git. Best I can tell, Mike Taylor (the guy in the post) either tried to figure out a standard git workflow on his own, or he followed
メモcache: gitを知らないデザイナとgitで共同作業するには？
2009/12/14 gitを知らないデザイナとgitで共同作業するには？ デザイナとgitで共同作業するまでの過程をログに残しておきます。 第一段階 会社で使っているフレームワークの Vの部分(いわゆるテンプレートまわりとか)はデザイナもさわるので、 .gitignore で無視することにして、 フレームワークのMVCのVの部分を除いてプログラマしかさわらない部分だけの リポジトリを作ってgitでバージョン管理することにした。 第二段階 ところが、Vの部分はデザイナしか関わらないわけではありません。 当然のごとく、プログラマ側から 「できればVの部分もgitでバージョン管理したい」 との要望がでてきました。 第三段階 そこで、デザイナに「バージョン管理は何を使っていますか？」 と聞いてみたところ「Mac の Time Capsule です。」 と言われ若干放心状態に…。 確かにバージョン
何週間か前、私は上流のCVSリポジトリから、複数のディレクトリにある複数のファイルを含むパッチセットを抽出しなくてはならない立場になっていることに気づいた。1回のコミットを、1つの簡単に取り出すことのできるdiffにまとめるという、Subversionのコンセプトに慣れていた私は、今回バージョンコントロールの世界にどれほどの進化があったのか悟り、ショックを受けた。 例えば、CVSではコミットを行うと、各ファイルにそれぞれ別のリビジョンが作成されるため、特定の時点のコミットで何が変更されたかをすべて知りたいとしても、リポジトリ全体のdiffを取ることはできない。SubversionとGitでは、3つのファイルを1度にコミットした場合でも、変更された部分のdiffをまとめて取ることは簡単にできる。ところがCVSの場合は、同時にコミットされたものであっても、まずそれら3つのファイルのリビジョンを
gitにsshのオプションを渡すには、sshをラップしたスクリプトを用意して GIT_SSHで指定してやればいいらしい。 例えば、johndがjdoeというユーザ名でid_rsa_jdoeという鍵を使って loginしたい場合の準備： % man ssh % $EDITOR git_ssh_jdoe.sh % cat git_ssh_jdoe.sh #!/bin/sh # git_ssh_jdoe.sh exec ssh -o User=jdoe -o IdentityFile=/home/johnd/.ssh/id_rsa_jdoe "$@" % % chmod +x git_ssh_jdoe.sh 使うときはGIT_SSHを指定してgitを実行する。 % GIT_SSH=git_ssh_jdoe.sh git fetch Enter passphrase for key '/home/
git を普段から使っているわけではないため、勘違いしているところもあるかもしれないです。 cygport で git がサポートされていることと、最近は git でしか配布していないソースもそこそこあるため、パッケージを git からつくることがある。 パッケージには元々のソースのバージョンだけでなく、パッケージ特有のリリース番号を追加することが一般的である。リリース番号はソースは同じだが、コンパイルオプションや梱包するファイルの変更など、パッケージする条件が変わった場合に変更 (ほとんどの場合はインクリメント) される。 例えば、cygwin だと 1 から始まる整数値のみ *1、Vine Linux の場合は 1 から始まる整数値にディストリビューションの略称と思われる固定文字列 "vl" がついて、さらに Vine Linux 自体のメジャーバージョン番号が付与される。*2 話を
1. Subversionと連携できる Subversionのtrunkだけでなくbranches, tagsもちゃんとローカルのGitリポジトリへ同期できます。 http://sourceforge.jp/magazine/09/03/26/0834222 実際僕はいくつものプロジェクトで、チームのリポジトリがSubversionであっても、自分の開発PCではGitを使ってSubversionと同期して開発してきました。これからもそうしていきます。 2. Subversionの履歴を引き継げる Subversionと同期できるようにローカルにGitリポジトリを作ると、そのSubversionの履歴もGitリポジトリに引き継がれます。ですのでSubversionにある履歴がGitに移行したから失われることはありません。 3. Subversionからゆっくり移行できる チームでSubver
ついったーにつぶやいたものを中心にまとめました。 まだこれで正しいという確信を持てていないので、メモという位置付けでお願いします*1。 なので追記する可能性が高いです。 TDD でドキュメンテーションコメントを書くタイミング カテゴリを指定して実行するテストを分ける git stash の使い道 TDD でドキュメンテーションコメントを書くタイミング ここでは Git を前提にしますけど、rebase 使えるならほかのものでも大丈夫なはずです。 TDD でいつドキュメンテーションコメントを書けばいいのか、というのは、 Re:TDD を理解するためのまとめ - ぐるぐる〜 TDD Boot Camp の参加報告とか読んで - ぐるぐる〜 と、過去 (といっても半年も経ってないけど) ずっともやもやしてたんですが、 事前条件で楽できないかなーという考え - Logic Dice に対する自分な
egg.elいまいちーと書いたところ、 @gom egg.elが嫌ならmagit.elでどう？俺的にはそっちのが使いやすいけど。 http://twitter.com/rubikitch/statuses/1901340067 と id:rubikitch さんに教えてもらいました。ありがとうございます。 というわけで、早速試してみた。 インストール makeするのね $ git clone git://github.com/jdhuntington/magit.git $ ./autogen.sh $ ./configure --prefix=$HOME/lisp/magit $ make $ sudo make install .emacsの書き換え (add-to-list 'load-path "~/lisp/magit/share/emacs/site-lisp/") (requ
GiggleはMac OSX/Linux用のオープンソース・ソフトウェア。Subversionでは有名なTortoiseSVNというグラフィカルクライアントソフトウェアがある。Gitではまだあそこまでの完成度ではない（特にMac OSX向けには）ということもあって、運用時にはターミナルを使っている。 X Windowを使ってMac OSXでも動く 普段のファイル追加、コミットであればターミナルからで十分だが、更新状況のチェックやログを見たいという時にはやはりGUIのフロントエンドが欲しくなる。そこで使ってみたいのがGiggleだ。GiggleはLinux向けではあるが、MacPortsでインストールが出来る。 GiggleでローカルのGitリポジトリを開ければ、その更新ログが閲覧できる。ブランチを作った時の分岐もグラフ上に描かれるので分かりやすい。特定のコミットを選べば、その時に変更が加え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
