Drowsy Dog's Diary

any note, any thought

2014年2月18日
by kazoo
2 Comments

[git] masterブランチの入れ替え、的な

といっても実際に乗り変わるわけではなく。

たとえば

みたいなブランチが(名前いまいちだけど)あって、
次バージョンの仕様をいろいろ盛り込んでいる間に feature-v2.0 の歴史が master よりもずっと先に進んでしまって、
「もうこれが master でいいよ」みたいな状態のとき。

git branch -m でブランチのリネーム、git push -f で強制 push してしまえば文字通りブランチの入れ替えはできそう。しかし、おそらく複数人で作業しているとしばき倒されますねこれは。

たぶんいろいろ方法はあると思うのですが、ここでは

と、
git merge の ours ストラテジを使ってコンフリクトをすべて自分のブランチ優先で解決した後に、master 側から merge すれば綺麗に上書きしてくれました。

単純に、master 側から

だけすればいけそうな気もしたけど、

そういうもんではないらしい。。

参考:
https://www.kernel.org/pub/software/scm/git/docs/git-merge.html
http://stackoverflow.com/questions/2862590/how-to-replace-master-branch-in-git-entirely-from-another-branch
http://stackoverflow.com/questions/2303124/git-merge-s-theirs-simply

2014年2月12日
by kazoo
0 comments

[git] mac で git の TAB 補完とか diff-highlight の折り返しとか

Mac で XCode 付属の git を使っていると、git に続くコマンドの TAB 補完が効いてくれない。補完を有効にするには、

して、~/.bashrc などで、

と、読込んでやると、

みたいに補完してくれる。

また、git diff コマンドで、Git の diff を美しく表示するために必要なたった 1 つの設定 #gitにあるように設定すれば、単語レベルの diff を表示してくれて大変ありがたいのだけど、コンソール右端を越える長い行が突き抜けていってしまう。これを折り返すには、同じく ~/.gitconfig の pager 設定に

と、書いてやれば OK でした。
快適!

2013年10月16日
by kazoo
0 comments

[git]リモートにあるはずのブランチが git branch -a で見えないとき

やっとわかった。

のように、リモートに存在するのに hotfix/1.3.1 ブランチが $ git branch -a でも出て来ないとき、next fetch のメッセージにあるように、

すればOK。

2013年8月8日
by kazoo
1 Comment

git merge のときに commit しない

(2013/10/25 -no-commitオプションについて追加)
ようにするには、

で、おk。
コンフリクトが無くてもマージコミットを抑制してくれるので、この後必要なら修正して git commit する。

また、

とすると、同じくコミットはせずマージだけ行う。
ただし後者の場合、 branch_name ブランチ側のコミットログも、branch_name ブランチがあったことも記録としては残らない。トピックブランチの内容をマージ先の1コミットにまとめても構わない場合に使う。

2013年4月3日
by kazoo
0 comments

git submodule

git submodule がちょっとややこしいのでメモ。
間違いなどあればご指摘いただけると重畳です。

submodule の追加

git submodule は、現在のリポジトリのクローン中に、別のリポジトリの特定のコミットを、サブディレクトリとして参照する。svn でいうところの externals にあたる。
たとえば独立にバージョン管理されているコアライブラリと、それをリンクするアプリケーションのプロジェクトがある場合、プロジェクトに取り込みつつも管理を別々にすることで、使用するライブラリのリリースバージョンを明確にしたり、lib をカスタマイズしてもその後のアップデートに簡単に追従したりできる。

GitSubmodule.046

「特定のコミットを参照」といっても、サブモジュールも結局リポジトリのクローンなので、こいつもコミットグラフを持っている。

サブモジュールの追加は、
git submodule add [リポジトリ] [サブディレクトリ]

.gitmodules に、サブモジュールの情報が書かれている。
git submodule add によって、この追加操作がステージングされているので、これをコミットしておく。

submoduleの操作

サブモジュールの操作は、そのサブディレクトリに入って行う。コマンドは通常と同じ。

リビジョン確認。これは submodule add された時点の corelib 側の最新コミットと同一。

サブモジュールの参照するコミットやブランチの指定。

この操作後、上のディレクトリに戻ると diff が出ている。それをもう一度 add, commit して、プロジェクトにおけるサブモジュールの更新となる。

submodule の更新

たとえばこの状態で、
GitSubmoduleUpdate

して、コミットC に戻ると、サブモジュールに diff が出てしまう。

new commits とか言われている。
これは、親リポジトリ(上位ディレクトリ)側で、checkout をしても、submodule はそれに追従しないため。これを更新するための操作が、

となる。基本的に、submodule はそのディレクトリ内部で操作しない限りは更新されない。

submodule を含むリポジトリのクローン

サブモジュールの内側は、外側の操作と連動しないので、submodule のあるリポジトリを別の場所から clone したときも、初めは submodule の中身は空っぽになっている。これを更新するために、まず git submodule init して .gitmodules ファイルを作り、その後 git submodule update で中身を更新する必要がある。

まとめ

  • submodule は、サブディレクトリの中に、外部リポジトリへの参照を記録する
  • submodule の外側(上位ディレクトリ)は、その外部リポジトリのどのコミットを参照しているかを記録(コミット)している
  • submodule の内側は、外側の操作(branchやcheckout)と連動しない。基本的には内側の操作を行ったときしか更新されない
  • submodule はただの外部リポジトリのクローンなので、ここからそのリポジトリに対する push などの操作は可能。これは運用マター

参考:
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB

http://qiita.com/items/0d525e568a6088f6f6bb