Hatena::Groupcside

Cside::StudyMemo このページをアンテナに追加 RSSフィード

メインブログに書くまでもない自分用メモを垂れ流す。日々是勉強也。

カテゴリー

2013-11-11

[]あるブランチに存在しないcommit hash一覧を出す

$ git cherry -v BRANCH_NAME

2013-06-19

[]リモートブランチfooをローカルにbarブランチとしてfetchしてくる

git fetch origin foo
git branch bar FETCH_HEAD

もしくは

git fetch origin foo:bar

2012-06-12

[]diff をパッチ形式で

$ git diff --no-prefix > patchfile

すぐ忘れる

toku_basstoku_bass2012/06/16 04:23use Hoge::Bar;
は、ファイルパスHoge/Bar.pmを表していて、
Bar.pmの中に書かれているパッケージ名とは何も関係ないんです。
単一ファイルに複数パッケージを入れることができるのもそのためだと思われます。

CsideCside2012/06/26 09:28おお、知りませんでした。ありがとうございます。

2012-05-20

[]

https://github.com/zentooo/rc/blob/master/.gitconfig

git tipsの宝庫っぽかった。

このなかの意味がわからないコマンドを調べていくことでGitへの理解を深める試み中。

2012-05-13

[]addとcommitいっぺんにやるやつ

いつも忘れる

git commit -a

git add -u と git ci をいっぺんにやる。-u オプションはtracking済みのファイルを対象にする意味なので、untracked なファイルに対しては使えない。

2012-05-12

[]rebase -i などで誤ってコミットを歴史から消した場合の取り消し

ttp://d.hatena.ne.jp/hiratara/20100625/1277457958

reflogを使えばいい

コミットはそう簡単に消えない、という話

git resetやmerge、rebase で履歴が消えることは決してありません。探しにくくなるだけでリポジトリには全ての状態が存在しています*3。git logで見えなくなった履歴を探す手段として、ORIG_HEADを参照したり、git reflog コマンドを使ったりすることができます。

注意

このエントリで消えないと言った物は「すでにコミットされた履歴」です。逆にインデックスや作業ディレクトリの内容は、操作次第で簡単に消えてしまいます*4。インデックスや作業ディレクトリの更新に関しては、誤って消さないように常に神経を尖らせておくべきです。

履歴の操作をする前には、 git stash で編集中の更新を一時退避するか、もしくは、思い切ってコミットしてしまうのも手です。自分は、 git checkout -b tmp/now-working → git commit -am "!修正中!" とすることも多いです。一度コミットしてしまえばgcされるまでは消えないので安心です。

ttp://d.hatena.ne.jp/hiratara/20100625/1277457958

[]rebase <branch> と merge <branch> の違い

merge は 2 つの親を持つ 1 つのコミットを作成し、履歴を一直線に保ちませんが、rebase は現在のブランチにあるコミットを他のブランチで再現することで履歴を一直線に保ちます。本質的に、rebase は自動的に連続で cherry-pick をすることに他なりません。

図解 Git

[]マージを取り消す

直前のマージ

git reset --hard ORIG_HEAD。ORIG_HEADはマージ直前の状態が格納されている。

N個前のマージ (N > 1)

地道に revert かなぁ

[]いっぺんrevertしたcommitを再度マージする

2012-05-11

[]別ブランチの最新N個のコミット分だけマージ

2012-05-10

[]1度revertしたコミットは再びmergeできない

これ知ってました?

普通に知らなんだ・・・。。。

devブランチで開発してたとします。

 master
 ─┬─→
   └(A)─(B)─(C)→
    dev

しかし誤って、devブランチの変更をmasterにマージしてしまいました。この段階ではまだマージしたくありません。

 master
─┬──────-┬─→
  └(A)─(B)─(C)┘
    dev

なのでrevertで、このマージをなかったことにします。

              (revert)
master           ↓
─┬────────→
  └(A)─(B)─(C)─→
    dev

開発が進んで、masterがdevブランチの修正を受け入れられる状態になりました。なのでマージを試みます。


               (revert)
master            ↓
─┬─────────………──→
   └(A)─(B)─(C)──────→
    dev

が、このマージはうまくいきません。というか何も起こってくれません。Gitは過去にrevertしたコミットは同じブランチで再び取り込めないようです。

               (revert)
	          ↓
─┬─────────………──→
  └(A)─(B)─(C)───────┘
    dev                   (!!! FAIL !!!)

なので結局、A, B, C を全く別のコミットにまとめなおした上でmasterにマージしました。。。


このケースから学ぶべきは

  • 後からマージし直すコミットに対してrevertしない

ということのなのかな。このへんは週末調べ直します。


追記

helpにこう書かれていた。

Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.

2012-05-01

[]過去のコミットに変更を加える(git revert 使わない編)

ttp://d.hatena.ne.jp/strkpy/20090508/1241760724

  1. git rebase -i
  2. git commit --amend
  3. git rebase --continue

see also

  • ttp://d.hatena.ne.jp/miau/20100709/1278699637
  • ttp://d.hatena.ne.jp/bleis-tift/20100219/1266552535

2012-04-29

[]git status の (untracked content) とか (modified content)

# Changes not staged for commit:
#   modified:   bundle/snipmate (untracked content)
#   modified:   bundle/surround (untracked content)
#   modified:   bundle/trailing-whitespace (untracked content)
#   modified:   bundle/zencoding (untracked content)

サブモジュールの中に修正があるよ、という意。

取り除きたいなら、

the actual way to have a clean status would be to go into each one of those submodules and:

add and commits those untracked contents,

or reference those same untracked contents in a .gitignore specific to each module.

How to get rid of Git submodules untracked status? - Stack Overflow

nanto_vinanto_vi2012/05/09 23:36プロトタイプの取得にはprototype関数を使うのが簡単と思います。
http://perldoc.perl.org/functions/prototype.html

CsideCside2012/05/10 07:06ありがとうございます!知りませんでした…。

2012-04-26

[]マージを取り消すために git reset --hard ORIG_HEAD するときの注意点

  • インデックスに追加してないファイルとかあらかた消し飛ぶので注意が必要
  • TODO: うまい方法ないかあとで調べる

2011-02-28

[]入門Gitを読んだのでまとめ

入門Git

http://farm5.static.flickr.com/4149/4986116365_ac6746e587.jpg

ざっとだけど通して読んだ。なんとなーく理解してたつもりだったこともだいぶ整理されたけど、まだまだこの本に書いてあることを使いこなすまでには時間がかかりそう。復習大事。

一人で使う

add & commit
git add -u版管理対象になっているすべてのファイルをadd
git add .ワークツリー内のすべてのファイルをadd
git add -Agit add -A && git add -u
git add -pパッチ形式の出力を見ながらどの変更をaddするか選択する
git commit -agit add -u + git commit
git commit -vgit diff --cachedの出力を見ながらcommitできる
git commit <file>すでにIndexにいくつかファイルをaddしていても、それを飛び越して特定のファイルをcommitできる
変更(履歴)を見る
git diffワークツリー ⇔ Index の差分
git diff HEADワークツリー ⇔ HEADの差分
git diff --cachedIndex ⇔ HEADの差分
git log --pretty=short要約だけを出力
git log変更履歴
git log -p各コミットでの変更をパッチ形式で出力
git log <dir_or_file>
git log --grep=<pattern>
git statusワーキングツリーで変更したファイルを表示
git show今作ったばかりのコミットの内容
git blame一行一行がどのコミットで誰に変更されたか確認
修正する・取り消す
git reset <file>addを取り消す
git reset HEAD^最新のコミットを捨てる(変更点は残る)
git reset --hard HEAD^最新のコミットを捨てる(変更点も捨てる)
git revert <commit>過去の不都合なコミットを打ち消す
git checkout <file>ワークツリーにした変更を取り消す
git commit --amendgit reset HEAD^ + git commit(直前のコミットを訂正)
git rebase -i <commit>commitID以後のコミットを対話的に変更する
HEADの表記
HEAD現在最新のコミット
HEAD^HEADの1つ前
HEAD~2(HEAD^^)HEADの2つ前
HEAD~3(HEAD^^^)HEADの3つ前

2カ所・チームで使う

git --bare init --shared共用リポジトリを作る
git tag -a <tagname>タグを付ける
git tag -l過去のタグを表示
git tag -l -nタグに付けたコメントも表示
git describe引数に渡されたコミットに一番近いタグから何番目のコミットかを含む文字列を返す
git rev-parse HEADHEADのコミットオブジェクト名
git describe --contains
ブランチ
git branch <branch>ブランチを作る
git checkout <branch>ブランチを切り替える
git checkout -b <branch>git branch <branch> + git checkout <branch>
git branch今いるブランチ
git stashワークツリー内の変更をとりあえず横にのけておく(作業途中のブランチ移動などでよく使う)
git stash popさっき横にのけた変更を戻す
git merge <branch>ブランチをマージする
git fetch

以後、まとめ途中・・・

変更履歴を追う

パッチベースのワークフロー

リモートリポジトリ定義

間違いからの回復