Eclipse上でPDTを使ってFuelPHPのプロジェクトをGit管理したかったので、EGit で github を使えるようにしてみました。

参考にさせていただいたサイトはこちら。

FuelPHPってなんじゃ？（Git管理編）

Eclipse、PDT、FuelPHP は既に使える状態になっているものとします。

まずはEclipseからGitを使えるように、EGit をインストールします。

Eclipse の Helpメニュー -> Install New Software でダイアログを開きます。EGitのダウンロード用URLはデフォルトで登録されているので、--All Available Sites-- の中から Collaboration -> Eclipse EGit を選択してインストールします。

インストールできたら Eclipse の Windowメニュー -> Preference でダイアログを開き、Team -> Git -> Configuration の User Settings タブで、New Entry ボタンをクリックして、user.name, user.email を設定します。

次にFuelPHPを使うプロジェクトを作成します。

sh>>
$ oil create contact
$ cd contact
<<--

ここで気をつけなければいけないことがあります。oil create で作られたプロジェクトは、FuelPHPの github のリポジトリを clone して作られいるためGit管理になっています。その中でいくつかのディレクトリは git の
submodule として登録されているのですが、通常はその中の .git はディレクトリになっているはずが、私の環境（Ubuntu12.04）ではファイルになっていて、中身は下記の用にプロジェクトルートの .git ディレクトリ配下のパスがかかれていました。

sh>>
$ cat fuel/core/.git
gitdir: /home/akanuma/Learning/php/work/contact/.git/modules/fuel/core
<<--

CentOS環境で試した時にはディレクトリとして作成されていたので環境によるのだと思いますが、このままだとあとでコミット候補としてインデックスに登録しようとした時に、下記のようなエラーが表示されます。

sh>>
$ git add .
fatal: Not a git repository: /home/akanuma/Learning/php/work/sample/.git/modules/fuel/packages/parser
<<--

また、submodule として登録した時にも下記のようにエラーになります。

sh>>
$ git submodule add git://github.com/fuel/core.git fuel/core/
The following path is ignored by one of your .gitignore files:
fuel/core
Use -f if you really want to add it.
<<--

そこで、下記の用にして .git ファイルの中身がさしているディレクトリを .git ディレクトリとして移動します。

sh>>
$ rm fuel/core/.git
$ mv .git/modules/fuel/core fuel/core/.git
$ rm fuel/packages/auth/.git
$ mv .git/modules/fuel/packages/auth fuel/packages/auth/.git
$ rm fuel/packages/email/.git
$ mv .git/modules/fuel/packages/email fuel/packages/email/.git
$ rm fuel/packages/oil/.git
$ mv .git/modules/fuel/packages/oil fuel/packages/oil/.git
$ rm fuel/packages/orm/.git
$ mv .git/modules/fuel/packages/orm fuel/packages/orm/.git
$ rm fuel/packages/parser/.git
$ mv .git/modules/fuel/packages/parser fuel/packages/parser/.git
$ rm -rf .git/modules/fuel
<<--

次に、FuelPHP の Git 管理下から外すために下記のように Git 関連ディレクトリを削除します。

sh>>
$ rm -rf .git .gitmodule
<<--

ローカルリポジトリを初期化します。

sh>>
$ git init
Initialized empty Git repository in /home/akanuma/Learning/php/work/contact/.git/
<<--

サブモジュールを追加します。

sh>>
$ git submodule add git://github.com/fuel/core.git fuel/core/
Adding existing repo at 'fuel/core' to the index
$ git submodule add git://github.com/fuel/oil.git fuel/packages/oil
Adding existing repo at 'fuel/packages/oil' to the index
$ git submodule add git://github.com/fuel/parser.git fuel/packages/parser
Adding existing repo at 'fuel/packages/parser' to the index
$ git submodule add git://github.com/fuel/email.git fuel/packages/email
Adding existing repo at 'fuel/packages/email' to the index
$ git submodule add git://github.com/fuel/auth.git fuel/packages/auth
Adding existing repo at 'fuel/packages/auth' to the index
$ git submodule add git://github.com/fuel/orm.git fuel/packages/orm
Adding existing repo at 'fuel/packages/orm' to the index
<<--

ドキュメント類を削除します。

sh>>
$ rm *.md
$ rm -rf docs
<<--

アプリケーション全体をコミット候補に加えるためにインデックスに追加します。

sh>>
$ git add .
<<--

ローカルリポジトリにコミットします。

sh>>
$ git commit -m 'First Commit.'
<<--

Eclipse の Fileメニュー -> New -> PHP Project で新規プロジェクト作成ダイアログを開きます。Project名を入力し、Content では Create project at existing location (from existing source) を選択し、oil create で作成したプロジェクトのルートディレクトリを選択し、Finish をクリックしてプロジェクトを作成します。

プロジェクトを右クリックし、Team -> Share Project を選択します。リポジトリタイプは Git を選択し次へ。Use or create repository in parent folder of project にチェックを入れ、先ほど作成したローかリポジトリを選択して Finish をクリックして共有設定をします。

再度プロジェクトを右クリックし、Team -> Commit でコミットダイアログを表示し、コメントを入力してから Commit をクリックしてコミットします。

さらにプロジェクトを右クリックし、Team -> Remote -> Push を選択してダイアログを表示し、Location に github のリポジトリの情報を入力して次へ。Source ref: で master を選択して Add Spec ボタンをクリックし、Finish ボタンをクリックして github への Push を実行します。

以上で FuelPHP のプロジェクトを github 管理下に置くことができます。

CentOS上からgithubを使えるようにしたので作業内容をメモ。

まずはyumでgitをインストールします。ちなみにCentOSのバージョンは5.8です。

sh>>

yum install git

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile

• base: rsync.atworks.co.jp
• epel: ftp.iij.ad.jp
• extras: rsync.atworks.co.jp
• remi: rpms.famillecollet.com
• updates: rsync.atworks.co.jp
  Setting up Install Process
  Resolving Dependencies
  --> Running transaction check
  ---> Package git.x86_64 0:1.7.4.1-1.el5 set to be updated
  --> Processing Dependency: perl-Git = 1.7.4.1-1.el5 for package: git
  --> Processing Dependency: rsync for package: git
  --> Processing Dependency: perl(Error) for package: git
  --> Processing Dependency: perl(Git) for package: git
  --> Running transaction check
  ---> Package perl-Error.noarch 1:0.17010-1.el5 set to be updated
  ---> Package perl-Git.x86_64 0:1.7.4.1-1.el5 set to be updated
  ---> Package rsync.x86_64 0:3.0.6-4.el5_7.1 set to be updated
  --> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================
Package Arch Version Repository Size

Installing:
git x86_64 1.7.4.1-1.el5 epel 4.5 M
Installing for dependencies:
perl-Error noarch 1:0.17010-1.el5 epel 26 k
perl-Git x86_64 1.7.4.1-1.el5 epel 28 k
rsync x86_64 3.0.6-4.el5_7.1 base 347 k

Transaction Summary

Install 4 Package(s)
Upgrade 0 Package(s)

Total download size: 4.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): perl-Error-0.17010-1.el5.noarch.rpm | 26 kB 00:00
(2/4): perl-Git-1.7.4.1-1.el5.x86_64.rpm | 28 kB 00:00
(3/4): rsync-3.0.6-4.el5_7.1.x86_64.rpm | 347 kB 00:00
(4/4): git-1.7.4.1-1.el5.x86_64.rpm | 4.5 MB 00:00

Total 4.1 MB/s | 4.9 MB 00:01
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : perl-Error 1/4
Installing : rsync 2/4
Installing : git 3/4
Installing : perl-Git 4/4

Installed:
git.x86_64 0:1.7.4.1-1.el5

Dependency Installed:
perl-Error.noarch 1:0.17010-1.el5 perl-Git.x86_64 0:1.7.4.1-1.el5 rsync.x86_64 0:3.0.6-4.el5_7.1

Complete!
<<--

続いてgithubのヘルプページを参考にして環境設定。
まずはコミット時に使うユーザ名とメールアドレスを設定します。

sh>>
$ git config --global user.name "h-akanuma"
$ git config --global user.email "hiroaki.akanuma@gmail.com"
<<--

メールアドレスは正しいメールアドレスを設定する必要はなくて、コミットを識別するためのものなので、user@server のような形にしてどこからのコミットかを判別できるようにしても良いらしいです。

次はパスワードのキャッシュ設定。リモートサーバにアクセスするたびにパスワードを入力しなくても良いように、パスワードをキャッシュする設定をします。また、デフォルトのキャッシュの有効期限は15分間なので、とりあえず1時間に変更しておきます。

sh>>
$ git config --global credential.helper cache
$ git config --global credential.helper 'cache --timeout=3600'
<<--

これだけでひとまず全体的な設定は終了なので、ブラウザでgithubにアクセスして新しくリポジトリを作成します。

そして再びCentOS上での作業です。バージョン管理対象にするディレクトリを作成して初期化します。

sh>>
$ mkdir PerlTools
$ cd PerlTools/
$ git init
Initialized empty Git repository in /home/akanuma/scripts/PerlTools/.git/
<<--

バージョン管理したいファイルを作成し、ローカルリポジトリにコミットします。

sh>>
$ cp ../cut_time.pl .
$ ls -la
合計 16
drwxrwxr-x 3 akanuma akanuma 4096 6月 10 00:29 .
drwxrwxr-x 3 akanuma akanuma 4096 6月 10 00:28 ..
drwxrwxr-x 7 akanuma akanuma 4096 6月 10 00:28 .git
-rw-rw-r-- 1 akanuma akanuma 1336 6月 10 00:29 cut_time.pl
$
$ git add cut_time.pl
$ git commit -m 'Script for cutting file content by time range'
[master (root-commit) a677816] Script for cutting file content by time range
1 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 cut_time.pl
<<--

そしてローカルリポジトリへのコミット内容をgithubへpushします。

sh>>
$ git remote add origin https://github.com/h-akanuma/PerlTools.git
$ git push origin master
Username:
Password:
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 757 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/h-akanuma/PerlTools.git

• [new branch] master -> master
  <<--

これでgithubへコミット内容が反映されました。
他のリポジトリのForkはまだやっていないのでまたそのうち。

LionにするにあたってCode Snippetsを移動する必要があるのかなと思ったのですが、Code Snippetsはちゃんと〜/以下に格納されているので意識する必要はなさそうです。

ただ、新しいマシンに以降するとき等は作業をする必要があります。

###Xcode 4のCode Snippetsを別のマシンに移動する stackoverflow

How Can One Transfer Xcode 4 Code Snippets from One Machine to Another
http://stackoverflow.com/questions/5261076/how-can-one-transfer-xcode-4-code-snippets-from-one-machine-to-another

上で見つけたんですが、こんな感じにsnippetsが格納されています：

rails>>
% pwd
~/Library/Developer/Xcode/UserData/CodeSnippets
% ls -1
104B0BF3-0D45-4663-B56A-8DA5DB05A80B.codesnippet
1F92BFD6-8936-4DD8-9AC6-98757661A9FE.codesnippet
206B6C3E-457A-4BEE-A679-C31DB7126C66.codesnippet
20D4FA3F-B205-4EBD-BCCA-568046C1D8F8.codesnippet
<<--

###自作の.codesnippetファイルを追加してみる
1つのファイルをコピーして、IDECodeSnippetIdentifierを他と被らないように適当に編集後、Xcodeを立ち上げて見てみましたがちゃんと追加されていました。ファイル名は人間に分かりやすい名前にしていたのですが、無事認識されていました。

rails>>
add_action_sheet.codesnippet
<<--

で、~/Library/Developer/Xcode/UserData/CodeSnippetsをgitリポジトリに格納してみました。
運用的には下記のように：

0. Code Snippets用のgitリポジトリを作成
1. 新しいXcodeをインストールする前にgit push
2. Xcodeをインストール
3. Code Snippetsディレクトリにgit clone
4. XcodeのCode Snippetsで移行されているかを確認

下記の記事も参照ください：

[git] 共有リポジトリを作る：git init --bare --shared=true
http://blog.s21g.com/articles/1312

[追記 2011.07.22]
@Seasons さんに教えて頂きました！Dropboxもいいですね。
ついでにDropboxでMac内の任意のフォルダを同期できるようにできるアプリ「MacDropAny」掲載されていました。便利♪：

Xcode 4のスニペットをDropboxで同期する - Seasons.NET
http://d.hatena.ne.jp/Seasons/20110328/1301300189

まずはローカルブランチを削除して

pre>>
% git push origin :hoge
<<--

でok。

手元のファイルは残しておきたいけれど、インデックスからは削除したいという場合には、以下のように --cached オプションをつけるとうまくいきます。

pre>>
% git rm --cached /path/to/files
<<--

ディレクトリをインデックスから削除する場合は -r オプションを忘れずに。

普段のコミットログから作業日報的なものを生成したい場合、
以下のようなコマンドでそれらしいものが出力できます。

pre>>
% git log --author=takiuchi --format="%ad %s" --date=short
<<--

git svnを使っていると、何度conflictを解決しても SVNに
"Your file or directory '***' is probably out-of-date"
と冷たく拒まれることがあります。
これを解決するには、XXXXにSVNのHEADに相当するコミットハッシュを指定して以下を実行します。

pre>>
% git checkout -b merging
% git checkout trunk
% git reset --hard
% git svn fetch
% git rebase trunk merging # コンフリクトするので解決してコミット
% git checkout -b merging2
% git checkout trunk
% git merge merging2
% git svn dcommit
<<--

結構面倒です。git-svnが賢くなってくれることに期待します。

git svn rebaseを行って conflict が発生した場合、
(no branch) になってしまいます。

この場合、手動でconflictを解決してcommitしたあと、

pre>>
% git log -1 --pretty=oneline
<<--

でコミットのハッシュを確認し、git checkoutでmerge先のブランチに
移動してから git merge <commit hash> すればokのようです。

git submodule update を行ったときに

pre>>
fatal: reference is not a tree: dfae...
<<--

というようなエラーが出ることがありました。
これを解決する方法は、
submoduleのディレクトリに移動し、

pre>>
% git reset --hard
<<--

で親ディレクトリに戻り、コミット & push

あとは普通に git submodule update をすればok.

git svnを以下のような構成で使っていた時に、git svnのリモートトラッキングブランチのpointerがtrunkに代わってしまい、いつのまにかブランチにcommitしたつもりのものがtrunkにcommitされるという事があり、困りました。

gitから.gitにpushしたものを git-svnからpullしたタイミングで発生するようです。
解決策としては、git-svnでgit pullをせずに、

pre>>
% git fetch remote-name
% git merge --no-ff remote-name/branch-name
% git svn dcommit
<<--

でok. アクシデンシャルなdcommitを防ぐには、--dry-runが便利です。

git-svnを使っていて、git svn dommitするときに、
掲題のようなエラーメッセージが出た場合、リモートリポジトリとローカルリポジトリのトラッキングブランチの同期が取れていない事が原因かもしれません。

例えば、SVNリポジトリ上で削除されているブランチが、ローカルのgitリポジトリに残ってしまっている場合、以下のようにリモートトラッキングブランチを削除する事で問題を解決できる可能性があります。

pre>>
% git branch -D -r
<<--

しばらく前にインストールしていた git-1.6.0.4 には無かった機能なのですが、最近のGit (1.6.4.4で確認) には git svn branch というSVNリポジトリのブランチを作成する機能がついているようです。

pre>>
% git svn branch
<<--

これで指定したbranchがリモートで作成されます。
あとは、こんな感じでリモートトラッキングブランチをチェックアウトすればOK.

pre>>
% git checkout -b --track
<<--

便利ですね。

[追記] 最後の方、ちょっと不明瞭だったので修正しました。

amend使ったこと無かったのでメモ。

###前提
shell>>

edit comment.rb

edit product.rb

git commit -am "wrong commit"
<<--
(上記のファイルを修正、product.rbを間違ってコミット)

そして、下記の順で変更・修正します：

###間違ってコミットしたファイルをコミットから外す
shell>>
git reset HEAD~1 app/models/product.rb
<<--
(変更は維持されたまま、コミットから外されます：unstageという)
(こうすると、# Changed but not updated:のところに出てくる)

###コミットメッセージの修正
shell>>
git commit --amend
<<--
(メッセージを修正できる)
(＋上でcommitから外したファイルを確定する)

###amend時にコミットメッセージを再利用する
via http://www.jukie.net/~bart/blog/git-amend

@onoさんにこの記事を教えて頂いたのですが、筆者の方はコミットメッセージを再利用するgit ammendコマンドを作っておくという技を使っておられるようです：
shell>>
git config --global alias.amend 'commit --amend -C HEAD'

#今後(メッセージはそのままで)コミットを修正したい時は下記でOK：
git amend
<<--

さらに流れ的には、

1. コミットしてから、
2. さらにファイルを編集、
3. それをgit addでファイルを追加、
4. git commit --amendで3で追加したのを直前のコミットに加える

というワークフローを使って運用。超こまめにコミットして作業したいときに便利そうです！

数字だけのタグだとうまくcoが出来なかった覚えがあるので、renameしました。あと、commitハッシュはフルでなくても、最初の5桁くらいで大丈夫だと思います。

###タグで使っているcommitハッシュを取得
shell>>
% git rev-parse 1.1
97f4c33e9a35255b8f8506ffa90ab70605ccf74f
<<--

タグのつけ直し

先程入手したcommitハッシュを使って
shell>>
git tag -a -f v1.1 97f4c33e9a35255b8f8506ffa90ab70605ccf74f
<<--

完了と思ったら、つけ直しではなく同じcommitハッシュに別のタグをつけるようになっていまようです。なので、不要なタグを削除します

###タグの削除
shell>>
% git tag -d 1.1
Deleted tag '1.1'
<<--

gitリポジトリに間違って追加してしまったファイル等を完全に消去する方法を紹介します。

pre>>
% git filter-branch -f --index-filter 'git update-index --remove "filename"' HEAD
% git push --force
<<--

ディレクトリを削除したい場合は、ディレクトリの中身のファイルを１つずつ全て削除します。

ポイント

• 上記のコマンドはワーキングディレクトリのROOTで実行する必要があります。
• "filename"はワーキングディレクトリのROOTからの相対パスで記述します。
• "-f" オプションはつけておいた方が良いです。

gitを使ってリモートリポジトリからfetch&mergeする場合、
git pullを使う事ができます。
git pullは

pre>>
% git pull origin master
<<--

のようにリモート名とブランチ名（正確にはrefspec）を指定して使うのですが、以下のような設定を行うと、これを省略できます。

.git/config

pre>>
[branch "master"]
remote = origin
merge = master
<<--

Today I collided with an issue regarding a git repository.
If a subdirectory of your repository has .git as a member, it shadows the subdirectory. So thus you can't sense its member even if you would type git status and check .gitignore.

今日はgitリポジトリに関する見つけにくい問題に遭遇しました。
リポジトリのサブディレクトリの中に.gitディレクトリがある場合、そのサブディレクトリ以下が隠されてしまい、git statusや.gitignoreを見ても存在が見えなくなってしまいます。

gitを使っていてローカルでつけたタグを、リモートにpushする場合は、

pre>>
% git push --tags
<<--

逆に、リモートのタグ情報をローカルに持ってくる場合は

pre>>
% git pull --tags
<<--

これでok

via http://news.ycombinator.com

http://www.viget.com/extend/backup-your-database-in-git/

production環境のDBをダンプして、gitのリポジトリに格納してしまおうという提案。

実際にSpeakerRateというサイトのデータはそれでバックアップしているそうデス。驚きです。crailgslistレベルのトラフィックだとうまくいかないかもしれないけれど、small to mediumサイズのwebアプリなら大丈夫だろうとのこと。

submoduleネタをゲットしたのでメモ。

@githubのtwt：

GitHub gem builder will now pull in submodules prior to the build.
4:05 AM Apr 9th from web
http://twitter.com/github/status/1478454260

てことは配布しているgemではsubmoduleをpullしてくれるってことでしょうか！！
いいですね！

###しかしtarball builderはsubmodule未対応

@github is there any plan to have the tarball builder do the same thing?
http://twitter.com/larrywright/status/1478514289

@larrywright not at the moment. We use git-archive which, for some unknown reason, doesn't support submodules.
http://twitter.com/github/status/1478579621

**その1**でsubmoduleをaddし、git-submodule statusコマンドでステータスを確認するところまでの作業をしました。
今度はaddした以外の人がpullして、submoduleを確認するところを書いてみます。

###submoduleを取得：init & update
shell>>
git pull --rebase #submoduleを追加したコミットを取得
git submodule
-e110f2056783465b8d719bdb1ab5fd14e7650f56 vendor/plugins/rspec
<<--

(-がついているので)この時点ではrspec submoduleが初期化されていません。よって下記のコマンドで初期化します：

shell>>
git submodule init
git submodule update
<<--

又は

shell>>
git submodule update --init
<<--

updateすることによりソースファイルを取得します。
これで、addした以外の人もsubmoduleを追加することができました。しかし、まだこれで終わりではなくて実はいくつか検討すべき点があります：

• submoduleに修正を加えないかどうか
• どのバージョンを使うか：commit hash
• (railsの)deployはどうするか：Capistrano
• submoduleの削除

###外部のrepoをそのままか、forkしてからか
submoduleをaddする前に検討すべき事項です(!)：
追加するremoteリポジトリを変更したくなる可能性があるかどうか検討する必要があります。例えばrailsやrspecなら変更を加えるというのはほとんどないように思われますが、完成度の低いpluginだと自分で修正したり、追加したりすることが考えられます。そのような場合、下記のようなシナリオが考えられます：

1. remoteをsubmodule(変更しない)
2. Githubであればforkして、それをsubmoduleにする
3. 自分のローカルにcloneして、それをsubmoduleにする
4. サーバにrepoを作ってremoteのファイルを追加、それをsubmoduleにする

1,2はなんとなく想像できますが、3,4は運用が面倒そうです...
また、railsまでsubmoduleにする記事もあったのですが、毎回deploy時にコピーすることになるのでdeployに時間がかかるだろうし、容量も食うので運用には向いていないかもしれません。

###どのコミットをsubmoduleとして採用するか
submoduleを利用する際、外部のbleeding edgeブランチを積極的に採用したくはありません。なので、タグか特定のバージョン(コミット)を利用するのが適切です：
shell>>
cd vendor/plugins/rspec/rspec
git tag
1.1.10
(略)
1.2.1
1.2.2
git checkout 1.2.2
cd ../../..
<<--

rspecのタグ1.2.2を採用しました。このあとRAILS_ROOTに戻ってcommit, pushすればokです。
この後、他の人がこの変更を反映するには下記の作業を行います：
shell>>
git pull --rebase #submoduleを追加したコミットを取得
git submodule update
<<--

###Capistranoでsubmoduleを使えるようにする
一行追加するだけ！
rails>>
set :git_enable_submodules, 1
<<--

via http://github.com/guides/deploying-with-capistrano

###submoduleの削除
rspecを例に：

1. .gitmodulesファイルから該当する行を削除
   shell>>
   [submodule "vendor/plugins/rspec"]
   path = vendor/plugins/rspec
   url = git://github.com/dchelimsky/rspec.git
   <<--

2. .git/configファイルから該当する行を削除
   shell>>
   [submodule "vendor/plugins/rspec"]
   url = git://github.com/dchelimsky/rspec.git
   <<--

3. git rm --cached path_to_submodule
   パスの最後に/(スラッシュ)がない状態で：
   shell>>
   git rm --cached vendor/plugins/rspec
   <<--

4. git commit、pushでおしまい

via http://git.or.cz/gitwiki/GitSubmoduleTutorial

###.gitmodulesファイル
初めてsubmoduleを追加すると、下記のファイルが追加されます：
shell>>
.gitmodules
<<--

その他に.git/configも変更されます。

###submoduleをもっとよく理解するRefs

• ここの解説が一番わかりやすかったです：

http://woss.name/2008/04/09/using-git-submodules-to-track-vendorrails/

• vendor/railsにsubmodule使おうぜ！という...！

http://woss.name/2008/04/11/using-git-submodules-to-track-vendorrails-2/

• submoduleがうまく動かなかったレポート

http://blog.buildingwebapps.com/2008/5/20/got-git-submodules-not-a-go-go

[追記] その2を書きました：
http://blog.s21g.com/articles/1411

長くなりそうなので続きはその2で！

railsを使っているとpluginなどは外部repoをそのまま使いたくなります。そこで前から聞いていたsubmoduleを使ってみたくなりました。しかしこのsubmodule、わりと最近導入されたようなのでgitのバージョンによって動作に違いがあるようです。

というわけで、まず私の環境を書いておきます：

shell>>
% git --version
git version 1.6.0.2
<<--

###git submodule add
rspecを例に：

shell>>
% git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec
<<--

追加したらcommit and push

shell>>
% git commit -am "add submodule: plugins/rspec"
% git push origin master
<<--

これでサーバにsubmoduleが追加されました。他の人がpullなどすれば、submoduleを確認することができます(詳しくはその2を参照)
で、次にsubmoduleのstatusを確認してみます。

###git submodule status
git statusと同じようなコマンドでsubmoduleの状態が確認できます：

shell>>
% git submodule status
9dc19a3a593f4ce1b4e221889091cebd773ea5c4 vendor/plugins/cache_fu (heads/master)
-e110f2056783465b8d719bdb1ab5fd14e7650f56 vendor/plugins/rspec 651611999df3e57de6f36486b51abd3bf5d66cea vendor/rails (v2.2.0-1085-g6516119)
<<--

commit hashに-、+がついている時がある(上だとrspecに-がついてます)。
ざっくり説明：

• -がついているとまだ初期化されていない状態
  => git submodule update --initでok
• +がついているとサーバでindexしているcommit hasと異なるcommit hashだよというお知らせ
  => git submodule updateでok

iPhone appのバージョンアップを申請後、時期verを開発継続している際にrejectされた、という場面があったので、タグ・ブランチでの運用を始めました：ezPhotoMail2度目のrejectを食らってしまいました orz

###rails@githubの場合：命名
ブランチ：バージョン＋stable/unstableの形
http://github.com/rails/rails/tree/2-3-stable

タグ：タグ名はvが入っている形
http://github.com/rails/rails/tree/v2.3.2.1

railsを参考にezPhotoMailでの運用を決めました、下記。

###ezPhotoMailでの運用：命名
appリリース後、新しいバージョンをリリースする場合はタグを付けます：タグは後付けも可能。
ブランチ名にはタグ名のvがない、数字だけのものを採用することにしました。

ex

• タグ名：v1.1
• ブランチ名：1.1

タグ名とブランチ名を同じにするとcheckoutやshowなどでrefspec(refs/heads/1.1, refs/tags/v1.1などの形式)を挙げねばならず運用が面倒。

###ezPhotoMailでの運用：rejectされた

• タグ名のvを取ったブランチがあるか確認、なければブランチを作成して修正
  shell>>
  git branch -r
  git checkout -b 1.1 refs/tags/v1.1 #1.1ブランチを作成してcheckout
  git push origin HEAD:refs/heads/v1.1 #HEADはカレントブランチ。refs/heads/v1.1はサーバ上のブランチ名
  <<--
• ブランチがあれば、checkoutして修正
• Info.plistのversionの末端を+1する：1.1→1.1.1
• 申請用のzip作成：appName_1.1.1.zip
• add, commit・push
• (各ブランチを最新にして)1.1ブランチをmasterブランチにマージ
  shell>>
  git checkout 1.1
  git pull --rebase origin v1.1:1.1 #v1.1=サーバブランチ
  git checkout master
  git pull --rebase origin master #サーバでもローカルでも同じ名前master
  git merge 1.1 #masterに1.1をマージ
  <<--
• 申請作業

###ezPhotoMailでの運用：申請が通った
ブランチのInfo.plist内のバージョンを確認して、タグを作成。

おまけにしようと思ったのですが、長くなりそうなので別記事にします。

###ブランチv1.1をサーバにpushする：
shell>>
% git push origin refs/heads/v1.1
<<--

###タグv1.1をサーバにpushする：
shell>>
% git push origin refs/tags/v1.1
Counting objects: 1, done.
Writing objects: 100% (1/1), 159 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To ssh://git.s21g.com/mnt/git/ezPhotoMail.git

• [new tag] v1.1 -> v1.1
  <<--

###ローカルのタグをすべてサーバにpushする：
via http://github.com/guides/push-tags-to-github

shell>>
% git push --tags
<<--

###サーバのタグを取得するには
tagをpushしたサーバ上のrepoをcloneすればtagも勝手に取得してくれるようです。cloneしてから、tagのブランチを作れば内容が確認できます。

shell>>
% git tag -l
v1.1
% git checkout -b 1.1 refs/tags/v1.1
<<--

又はブランチを作らずに内容を確認：

shell>>
% git checkout refs/tags/v1.1
<<--

ブランチ、タグ両方にv1.1があると、ambiguousだと怒られました。

shell>>
% git show v1.1
warning: refname 'v1.1' is ambiguous.
<<--

ということで探してみたら、下記の記述：

• ブランチ "test" は "refs/heads/test" の略記です。
• タグ "v2.6.18" は "refs/tags/v2.6.18" の略記です。
• "origin/master" は "refs/remotes/origin/master" の略記です。

http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#how-git-stores-references

fmfm フルパス？で指定してみると、うまく表示されました！：

shell>>
% git show refs/tags/v1.1
<<--

各コミットに割り当てられるSHA1は長いので、その頭数桁をabbreviated commit hash/commit checksumなどと呼びます。適当な長さで良いようです：ex. 7-8桁。

数桁って何桁やねん！と思って探したのですが、見つけられませんでした。そういえば昔何かのlibraryの作者にバグ報告したときに、githubのコミットSHA1の頭五桁を送ってくれって言われたことがありました。ということで適当でいいみたいですね。この適当さ加減が良い。そしてそういう風にも使えるのですね。

このhashはtag設定時等に指定できます:

shell>>
% git tag -a v1.1 0d86f96 -m "version 1.1"
% git show fb47ddb2
<<--

Pretty formatsのformatに記述されていました: abbreviated commit hash

%h: abbreviated commit hash
http://www.kernel.org/pub/software/scm/git/docs/git-show.html#_pretty_formats

learn.githubでタグ時の説明に：commit checksum

And I forgot to tag the project at ‘v1.2’, which was at the ‘updated rakefile’ commit, I can add it after the fact. To tag that commit, you can just specify the commit checksum (or part of it) at the end of the command.

$ git tag -a v1.2 9fceb02
http://learn.github.com/p/tagging.html#tagging_later

サーバ管理をしていて、root権限が必要なディレクトリに、ファイルをリポジトリからgit cloneしてきたい状況になったので、方法をメモしておきます。
まず状況の確認として、

• gitのプロトコルにはsshを使っている
• リポジトリサーバには、rootユーザでは鍵認証でもパスワード認証でもログインできない
• リポジトリサーバ、clone先のサーバ双方ともfooというローカルユーザが存在。sshでリモートログインできる

という感じです。ユーザ権限でアクセス出来る場所にgit cloneする場合であれば、

pre>>
foo% git clone ssh://git.repos.com/path/to/repo.git
<<--

こんな感じで済むのですが、ファイルの作成にroot権限が必要な場合、
repoディレクトリを作成出来なくて怒られます。
かといって、rootユーザでgit cloneしようとしても、リポジトリサーバにはrootではログイン出来ないのでcloneできません。

そのような場合には、以下の手順を踏みます。

1. clone先のサーバに ssh -A foo@target.server.com でエージェントフォワードしてログイン。
2. ssh -A root@localhost でエージェントフォワードした状態でlocalhostにrootユーザでログイン（ターゲットサーバ上での、ローカルからのrootによるssh接続は許可する必要がある）
3. git clone ssh://foo@git.repos.com/path/to/repo.git でclone

これでroot権限が必要な場所にfooユーザのSSHエージェントを介してリポジトリサーバに接続し、cloneできます。

注意

安全にエージェントフォワーディングを行う事が出来るのは、
接続先および踏み台にするのサーバ群の管理者たちが全て信頼できる場合に限られます。

弊社は、deployツールとしてcapistranoを使っています。
しかし、Capistranoのメンテナンスが終了するという話("Jamis Buck氏, CapistranoやSQLite/rubyの開発を終了"参照)を聞いても、
特に困らないという事に気がついて、あらためて驚きを感じました。

なぜだろうと考えてみると、それはGitとGitHubの存在による所が大きい。
GitHubにソースがある限り、メンテナが不在でも勝手にforkして
野良patchを書いたり、それを集めてきてちょっとした
stable release的なものを作ったりする事ができてしまう。

もちろんそれは、今までだって頑張れば出来た事だけれど、
Git/GitHubは、それを全く違う次元で簡単にしてしまった。

かつてはメンテナやコミッタが専権的にソフトウェア開発の決定権を握っていた構造が、Git/GitHubの登場によって、気がつかないうちに崩れ去っている。
これはソフトウェア開発史上、非常に大きな出来事なんだろう。

See Also

• Net::SSH, Capistrano, and Saying Goodbye

Xcodeで開発しているiPhoneアプリをgitで管理する場合には、
以下のような
.gitignore
ファイルを使っています。

pre>>
.xcodeproj/.mode1v3
.xcodeproj/.pbxuser
build
.DS_Store
<<--

ハマったので覚えるために記事にしました。

###サーバ等で
shell>>
$ mkdir repo.git
$ cd repo.git
$ sudo git init --bare --shared=true
<<--

**"空"**の共有リポジトリができました。

###ローカルマシンで
その後、remote add, add, commit, push

shell>>
git init
git remote add origin ssh://git.s21g.com/mnt/git/repo.git
git add .
git commit -m "initial import"
git push origin master
<<--

サーバのrepo.gitにファイルが追加された時点でcloneできるようになります。空のリポジトリをcloneしようとしてもエラーが出ます：

shell>>
$ git clone ssh://git.s21g.com/mnt/git/repo.git
fatal: no matching remote head
<<--

###おまけ：git URLを確認する git remote show origin
shell>>
git remote show origin

• remote origin
  URL: ssh://git.s21g.com/mnt/git/repo.git
  <<--

pre>>
% git pull
<<--
は、
pre>>
% git fetch
% git merge /
<<--
と同じ事です。

git pull --rebaseというのもよく見かけますが、これは
pre>>
% git fetch
% git rebase /
<<--
と同じ事です。mergeの代わりにrebaseを使います。

See Also

• git-pull、git-pull --rebaseをめぐる冒険＋コンフリクトした場合の作業

githubなどを使っていると、簡単にリポジトリをフォーク出来るので、
有名なプロジェクトになると、数十のリポジトリが並走している事もしばしばです。
多くの場合、フォークのツリーをたどっていけば、ルートになるリポジトリが見つかるのですが、ルートになっているプロジェクトのコードが最新であるとは限りません。
フォークしたリポジトリの方にバグの修正が入っていたり、パッチがあたっていたりする事も良くあります。

そのような場合には、
pre>>
% git remote add
<<--
のようにして、関心のあるremoteリポジトリを登録しておきます。
登録が済めば、
pre>>
% git fetch
<<--
でリモートのブランチを手元に持ってくる事が出来ます。
例えば手元のmasterとリモートのmasterの差異を知りたければ、

pre>>
% git diff master../master
<<--

のようにする事で調べられます。

昔書いたgit-svn関係の記事が、結構ブックマークされてるようだったので、
一旦まとめておきます。

• git-svnでSVN上の複数のブランチやtrunkを扱う方法
• git-svnのサブコマンド補完関数（Zsh）
• git-svn環境からRubyforgeのGitリポジトリにpushする方法のメモ
• git-svnを使って既存のSVNリポジトリでGitを使う方法のメモ

See Also

• git-svn+Railsで使うgitコマンド
• git svn cloneに失敗する：git svn clone -r 1234で解決

GitHubでGemを公開する場合に、バージョン管理をどうするか色々考えていたのですが、良さそうな方法を見つけたのでメモしておきます。

• 開発時のバージョン番号はリリースしているものより一つ進める
  • 0.1.0をリリースしてる場合、ソースコード中のバージョン番号は、次のリリースバージョン（例えば0.1.1など）にしておく
• リリース時にgemspecを更新してpushする

これによって、http://gems.github.com をリリースGemリポジトリとして使う事が出来ます。

また、開発中のEdgeGemを配布する場所としては、自分でGemリポジトリを作ってしまうのが良さそうです。
弊社では、http://merbi.st というEdgeGemリポジトリを用意しています。
これは、あらかじめ登録してあるGitHubなどの外部リポジトリから、定期的に最新のコードをfetchしてGem化しています。

githubの仕様変更
により、githubでEdgeGem (EdgeのコードをGemにまとめたもの)
を常にフレッシュな状態で公開する事が難しくなってしまったので、
Merbist向けにプラグイン配布用のGemサーバを用意しました。

• http://merbi.st

gems.rubyforge.orgやgems.github.comなどの通常のGemサーバと同様に、以下のようにsourcesに登録して使う事ができます。

pre>>
% sudo gem sources -a http://merbi.st
<<--

仕組みとしては、http://merbi.st/fetch にアクセスされると、
登録されているgithub上のリポジトリから、Edgeのコードがpullされ、
GemとGemサーバ用のインデックスデータを作成します。

現時点では、以下のGemを公開しています。

pre>>
% gem list -r -s http://merbi.st

*** REMOTE GEMS ***

dm-has-versions (0.1.1)
dm-pagination (0.1.1)
merb_babel (0.1.2.2)
merb_component (0.1.1)
merb_recognize_path (0.0.2)
merb_slice-gen (0.0.2)
merb_timezone_select (0.0.2)
pagination_scope (0.0.8)
rttool (1.0.2)
<<--

サーバの負荷の面で不安があるので、
現時点では同期するリポジトリの登録は管理者のみに制限していますが、
http://merbi.st/plugins
よりプラグイン情報を登録していただければ（要アカウント作成）、
問題が無い限り定期的に確認して同期リストに追加いたします。

反応がない場合は@takiuchi
までご一報ください。

個人的には git が色んな点で svn を上回っていると感じているが、
まだひとつだけ svn にしかない機能が残っている。

pre>>
% svn info
URL: http://wota.jp/svn/rails/plugins/trunk/dsl_accessor
...
<<--

あれ？この git ってどこのレポジトリのだっけ？
てのを速攻で知りたいときに git info がないのを恨めしく思う。
もちろん .git/config を見ればいいのだが、

pre>>
% cat .git/config
...
[remote "origin"]
url = git@github.com:maiha/mjs.git
fetch = +refs/heads/:refs/remotes/origin/

<<--

svn info に比べると只でさえ type 数が多い上に、
サブディレクトリにいるときの type 数は分析不能になるので、
やっぱり辛い。
中身も長過ぎて url を見つけ出すのも大変だし、
最近では明け方には氷点下近くまで冷え込んでしまって、
コンビニ行くのも一苦労な昨今、
たっきーに

「git config すればええがな」 (声・略礼服の長老)

と言われたので、そうしました。

pre>>
% git config --list
user.email=maiha@wota.jp
user.name=maiha
...
<<--

--list は長いので、get で url だけ登録。

pre>>
% vi ~/.gitconfig
[alias]
url = config --get remote.origin.url

% git url
git@github.com:maiha/mjs.git
<<--

くぅ〜ん♪

でも、git info もやっぱり欲しいです

init してgithub に first commit した最初のレポジトリだけ、なぜか git pull が動かない。

pre>>
% git pull
...
branch.master.remote =
branch.master.merge =
remote..url =
remote..fetch =
<<--

github の指示通りに実行したのにこの仕打ちはむごいよ。
確かに git pull origin を付ければ動作するのだが、
新たに clone したレポジトリだと git pull だけでも動作するのが、
なんか悔しい。

pre>>
% git pull origin
Already up-to-date.
<<--

それでも type 数の節約を優先させるために仕方なく、
「first commit後は必ず一度 clone しなおす」
という生活にすっかり慣れきって、いよいよ冬が降るという話題も出るほど厳しい冬となってきた昨今、
たっきーに

「alias すればええがな」 (声・略礼服の長老(すべらない話／小藪))

と言われたのでそうしました。

pre>>
% vi ~/.gitconfig
[alias]
up = pull origin
% git up
Already up-to-date.
<<--

くぅ〜ん♪

多分この週末がすぎれば直ってると思うんですが、GitHubのgem生成機能が動作していないようで、公開したいgemが公開されずに困っています。
そういう場合に、手動でなんとかする方法をメモ。

GitHubで公開されているgemは、GEM_NAMEにユーザIDがプレフィックスとしてつくので、単純にgitをcloneしてきてrake installしても、プレフィックスがついていないgemがインストールされてしまうので、ちょっと困ります。

この問題を回避するには、自分でgemspecファイルを編集して、
以下のようにプレフィックスをつけてやる必要があります。

ruby>>

-- encoding: utf-8 --

Gem::Specification.new do |s|
s.name = %q{genki-merb_babel}
s.version = "0.1.0.6"
<<--

gemspecファイルを編集したら、

pre>>
% gem build merb_babel.gemspec
% sudo gem install genki-merb_babel-0.1.0.6.gem
<<--

という感じでインストールすれば、GitHubからインストールしたのと同じような感じでインストールできます。

現在のディレクトリがgitの管理下にあるかどうか判定する方法を思いついたので、
walf443さんの方法
を改良してみました。
こんな感じに、gitで管理されてないディレクトリではブランチ名を表示しなくなります。

実際のzshrcは以下の通り。

sh>>
_set_env_git_current_branch() {
GIT_CURRENT_BRANCH=$( git branch &> /dev/null | grep '^*' | cut -b 3- )
}

_update_rprompt () {
if [ "git ls-files 2>/dev/null" ]; then
RPROMPT="[%:$GIT_CURRENT_BRANCH]"
else
RPROMPT="[%]"
fi
}

precmd()
{
_set_env_git_current_branch
_update_rprompt
}

chpwd()
{
_set_env_git_current_branch
_update_rprompt
}
<<--

git ls-filesがgitの管理下以外では何も返さない事を利用しています。

追記

• 2>/dev/null が抜けていたので追加しました。

以前、
benchmarkforrails
というRailsプラグインを紹介した事がありました。
しばらく互換性の問題があって使うのをやめていたのですが、
久々にRails-2.2.2環境で使ってみたら動いたので、
最新版のリポジトリの場所を紹介します。

• benchmarkforrails

gitで公開されているので、以下のようにインストールします。

pre>>
% ./script/plugin install git://github.com/cainlevy/benchmarkforrails.git
<<--

See Also

• BenchmarkForRails導入でrakeが動かない

GitX
は、MacOSXで使えるGit用のGUIツールです。

基本的にはCUIで操作してるのですが、
これを使うとブランチのマージの様子などが視覚的に追えて便利。

アバター画像はメールアドレスから
gravatar経由で持ってきてるんですね。
賢い。

See Also

• Mac OSXでGitを使った開発を行っているなら「GitX」

Gitでは、SVNなどと違ってリビジョン番号のような順序付きの数字ではなく、
ハッシュのような識別子でコミットが管理されています。
なので、時系列にそってコミットIDを列挙したい場合は、
以下のように git rev-list コマンドを使えば良いようです。

pre>>
% git rev-list 2dfb3...(snip)...cf210
<<--

これで、指定したコミットより過去（指定したコミットを含む）のハッシュが時系列にそって得られます。
先頭は一番新しいもので、末尾が一番古いものです。

pre>>
% git rev-list HEAD
<<--

とすると、全てのコミットのハッシュを時系列にそって取得出来ます。

s21gブログではmasterの他にdeployブランチがあり、下記のようなフローで運用しています。

1. 普段はmasterにpushして
2. deployできる状態になったらdeployにmasterの変更を反映
3. deployをpush＆cap deploy

ローカルでもdeployブランチとすればよかったのですが、ローカルを意識したいのでlocal_deployという名前にしてみました。そのことで勉強になったので、書いてみたいと思います。

###リモートのoriginブランチを確認
shell>>
git branch -a

• master
  origin/HEAD
  origin/deploy
  origin/master
  <<--

###ローカルにブランチを作成
shell>>
git branch local_deploy origin/deploy
git branch -a #追加されているのを確認
git checkout local_deploy
<<--

また下記のコマンド1つで、ブランチを作ってcheckoutまでをやってくれます。

shell>>
git checkout -b local_deploy origin/deploy
<<--

git checkout -b <new> <start-point>
create a new branch <new> referencing <start-point>, and check it out.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#manipulating-branches

###masterの変更をlocal_deployブランチに反映
shell>>
git checkout master
git pull --rebase -v #masterを最新に, +verbose
git checkout local_deploy
git merge master
git push origin local_deploy:refs/heads/deploy
<<--

git merge masterの前後でちゃんとファイルが変更されているか見てみましたがちゃんとmergeできていました。また、pushの際のsrc:dstの指定の仕方がこのままでは面倒なので調べて後日また書いてみようと思います。

コンフリクトした時は修正後コミットし、上のpushコマンドを発行すればokです。

shell>>
#(コンフリクトしたファイルを修正後)
git add some.file
git commit -m "merged from master"
<<--

emacsを使っていると＊~ファイルや#＊#ファイルができます。これらを無視するのにプロジェクトのgitignoreを変更するのははばかれるというので、使い回せないかと思ったところありました。

1. ~/.gitignoreファイルを用意する
2. 下記のコマンドを発行
   shell>>
   git config --global core.excludesfile ~/.gitignore
   <<--
   ~/.gitconfigを編集する手もあるようなのですが、即反映というわけではないようなので、shellから指定したところすぐに反映されました。
3. おしまい

###~/.gitignoreの中身
shell>>
~
#*#
<<--

間違ってremoteブランチを作ってしまったのですが、勉強になったので記事にしておきます ；P

###remoteにlocal_deployブランチを作成

shell>>
$ git push origin local_deploy #間違って作成
$ git branch -a

• master
  origin/HEAD
  origin/deploy
  origin/local_deploy #ローカルにも反映されている
  origin/master
  <<--

###remoteブランチを削除
shell>>
$ git push origin :local_deploy
<<--
これでサーバ側は反映されました。

###別のローカルリポジトリ(cloned)で削除が反映されない
しかしもう一つ別のディレクトリで同じgitリポジトリをcloneしていて、そちらで削除が反映されない状況に。

下記の1.の説明にあるように、(remoteブランチの追加は自動でされるが)削除されたものはローカルで明示的に削除しないといけないようです。

Delete unneeded branch
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -d -r origin/todo origin/html origin/man (1)
$ git branch -D test (2)

  1. Delete remote-tracking branches "todo", "html", "man". Next fetch or pull will create them again unless you configure them not to. See git-fetch(1).  
  2. Delete "test" branch even if the "master" branch (or whichever branch is currently checked out) does not have all commits from test branch. 

http://www.kernel.org/pub/software/scm/git/docs/git-branch.html

(上によると、git branch -d -r origin/removed_branchでもremoteブランチが削除できるようですね)

###コマンドgit remote show origin, git remote prune origin
git remote辺りにコマンドがあると知ったので見てみると、git remote showがありました。
確認すると、腐りかけた(Stale)tracking branchと表示されています。

shell>>
$ git remote show origin

• remote origin
  URL: ssh://git.s21g.com/mnt/git/blog.git
  Remote branch merged with 'git pull' while on branch master
  master
  Stale tracking branch (use 'git remote prune')
  local_deploy
  Tracked remote branches
  deploy master
  <<--

そして、pruneで削除。ヘルプには、--dry-runでやるとどのブランチをpruneするかレポートしてくれて、実際のactionはしない旨が記述されているのですが、私の環境では削除されてしまいました。

shell>>
$ git remote prune origin --dry-run
<<--

###Refs
http://www.kernel.org/pub/software/scm/git/docs/git-remote.html
http://www.kernel.org/pub/software/scm/git/docs/git-branch.html
http://reinh.com/blog/2008/04/18/git-push-just-the-tip.html

Gitに関するリンク集
http://blog.s21g.com/articles/548

gitをやり始めて時間が経ちますが、まだまだ知らないことばかり。
もう一度リンク集作ってみました。

###複数で開発するとき
git-pushのコツ：remoteブランチとか
http://reinh.com/blog/2008/04/18/git-push-just-the-tip.html

ブランチを使った開発の流れ
http://b.lesseverything.com/2008/3/25/got-git-howto-git-and-github

###gitリポジトリからのdeploy
CapistranoでGitを使う方法のメモ
http://blog.s21g.com/articles/807

rakeタスクからdeployする手順/ワークフロー
http://www.brynary.com/2008/8/3/our-git-deployment-workflow

###初心者にも役立つもの
Git It, Got It? Good!：pdf。これシンプルで分かりやすいと思います
http://assets.reinh.com/talks/GIT.pdf
http://reinh.com/blog/2008/02/19/git-it-got-it-good.html

Git用語Glossary
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#glossary

毎日使うgitコマンド：gitコマンドサンプルが多いのが良
http://www.kernel.org/pub/software/scm/git/docs/everyday.html

via http://ozmm.org/posts/git_post_commit_for_profit.html

gitのrefspecがよくわからなくて、調べていたら出会った記事です。

###.git/hooks/pre-commitをshellスクリプトで
shell>>
$ chmod 744 .git/hooks/pre-commit
$ cat .git/hooks/pre-commit
#!/bin/sh
rake test
<<--

こういうのもありました。
http://reinh.com/blog/2008/02/21/git-pre-commit-hook.html

shell>>
#!/bin/sh
rake spec 2> /dev/null
<<--

###.git/hooks/pre-commitをrubyで
shell>>
$ cat .git/hooks/pre-commit
#!/usr/bin/env ruby
if whoami.strip != 'deploy'
puts "You need to be deploy!"
exit 1
else
exit 0
end
<<--

###その他のhooks
.git/hooksには下記のようなファイルがあるので、preもpostもできるようです。
shell>>
post-commit
post-receive
post-update
pre-applypatch
pre-commit
pre-rebase
<<--

###pre-push hookはないのか
と思ったら、こういうパッチを書いている方がいます。パッチほとんどやったことないので、今度やってみよう。

http://kerneltrap.org/mailarchive/git/2008/8/19/2996404

少し前にgitでのHEADが何か・どこか解決したので、リブログしておきます。

http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#manipulating-branches

特別なシンボル "HEAD" 使用すると、常に現在のブランチを参照することができます。実際 git は .git ディレクトリにある "HEAD" という名前のファイルを使用して現在のブランチの場所を記憶しています。

shell>>
$ cat .git/HEAD
ref: refs/heads/master
<<--

gitを使っていて、間違ったファイルをgit addしてしまった場合に、
これをキャンセルする為には、以下のコマンドが使えます。

pre>>
% git rm --cached
<<--

git rmは、Working Tree (作業コピー)と
index からファイルを削除するコマンドですが、
--cachedを指定する事で、
indexからのみファイルを削除する事ができます。

git addはWorking Treeからindexにファイルを追加するコマンドなので、
git rm --cachedは、git addと対をなすコマンドだと言えますね。

git-pullで私なりの解釈で aha！が来たのでメモします。
これからは git-pull --rebaseにしよー
下記をそのままという感じなのですがｗ
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase

###そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ
git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。)

Here's a tip for keeping up to date: In lieu of using git pull to download the latest changes, use git pull --rebase. Instead of cluttering the history with a merge commit, it reapplies your changes to the latest upstream. The only caveat is that you shouldn't use this method if you've already published the changes to another repository. Doing so would cause problems for anyone who has already downloaded the original commits.
http://www.tpope.net/rails-git-best-practices

でgit-pullとgit-pull --rebaseの違いをgit-rebaseの説明を読んで理解する

###状況
o--o--O--o--o--o <-- origin
         \
         a--b--c <-- mywork

"mywork"は"origin" から単純に並行に行なわれています
プロジェクトの上流では他の興味深い変更が行なわれ、 "origin" は発展します

###で、(上の状況から)git-pullした場合
o--o--O--o--o--o <-- origin
         \          \
         a--b--c--m <-- mywork

"pull" を使用して変更をマージさせることができます；結果として新しいマージコミットが生成されます

###で、(上の状況から)git-pull --rebaseした場合
originが最新であればgit rebase originでいいと思うのだけど、(originが)最新でない場合はgit-pull --rebaseすればいいのだと解釈しました。

o--o--O--o--o--o <-- origin
                      \
                      a'--b'--c' <-- mywork

これは、mywork からあなたの各コミットを削除し、一時的に (".dotest" という名前のディレクトリ内に)パッチとして保存し、 mywork を origin の最新バージョンの位置に更新し、その後で保存した各パッチを新しい mywork ブランチに適用します。

コンフリクトがある場合は、下記にあるように修正してaddしてgit rebase --continueすればok。

###各git-somethingでのコンフリクト時のリカバリ

• git merge 時のリカバリ

      o 手動マージ -> 動作確認 -> add -> commit  

• git rebase 時のリカバリ

      o 手動マージ -> add -> git rebase --continue  

• git pull 時のリカバリ

      o メンテナの場合 -> 一蹴  
      o ユーザの場合 -> 手動マージ -> add -> commit  

• git-am 時のリカバリ ( apply mail = メールで送られるパッチの適用 )

      o メンテナの場合 -> 一蹴    
      o ユーザの場合 -> 手動マージ -> add -> git-am --resolved  

http://d.hatena.ne.jp/conceal-rs/20080928/1222612534

###Refs
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase
http://www.tpope.net/rails-git-best-practices
http://blog.s21g.com/articles/535:tpope.netさんのRails with Gitのためのベストプラクティス
http://d.hatena.ne.jp/conceal-rs/20080928/1222612534：gitでの開発の流れがわかってかなり++