GitHubのリポジトリに$ git pushした際、デフォルトだと、ローカルコンピュータのユーザー名で push されてしまう。 GitHub のアカウント名で push したい場合には、 web.archive.orgを参考に、 $ git config --global user.name "<Githubのアカウント名>" $ git config --global user.email "<Githubに登録しているメールアドレス>" とTerminalで実行すれば、以後は GitHub のアカウント名で push される。 現在登録している git のアカウント情報を知りたい際は $ git config --global --list と実行すれば、現在の登録状況が表示される。 ちなみに、この登録情報は ~/.gitconfig に保存されることになる。 --globalのオ

Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと

gitを使ってトピックブランチをメインブランチにマージするときにコンフリクトが起きることがある。 今の環境ではコンフリクトが起きないようなタスク管理をしているので滅多には起きないけど、それ故に起きたときに毎回どうすればいいのか迷ってしまう。それを避けるために今回、gitのマージとコンフリクトについてまとめた。 3ウェイマージ gitのマージでは3ウェイマージを使用しているということで、まずは3ウェイマージについて確認する。 上図の場合、CからAの変更点(CA)、CからBの変更点(CB)があり、それらの変更点を両方取り込んだものがDになる。 Dが問題なく作成できるかどうかは、CAの変更点とCBの変更点の重複の有無とその内容による。 重複する点がなければそれぞれの変更を適用でき、問題なくDが作成される。 また、重複する点があるときでもその変更内容が同じであれば、問題なくDが作成される。 問題と

サブモジュールが更新されない Git Submodules を使うと他のリポジトリのコードを取り込むことができます。 しかし、上記のようにサブモジュールを追加すると、サブモジュール側が更新されても新しい更新に追従することができません。git submodule update を実行してもリモートの最新の状態に追従することができません。 Git Submodules は、通常はブランチではなく特定のコミット単位で関連付けを行うため、上記のコマンドを実行すると、その時点での最新のコミットのコミット ID で関連付けを行います。つまり、その後、サブモジュール側が更新されても、コミット ID は変更されないため、git submodule update しても更新されないのです。 ブランチ名を指定 ブランチ名を追加することでそのブランチの最新版に追従することができます。

はじめに gitのsubmoduleを使う機会があったのですが、間違えて追加して再追加するときに、いろいろ戸惑ったので、まとめました。 submoduleの追加

みなさんgitのsubmoduleって理解して使ってますか？ 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか？ 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ

↓のv1.1.0版の方が、より見やすく改善したものになってます！ http://www.slideshare.net/matsukaz/git-28304397 社内で開催したGit勉強会の資料。 SVNとの比較や、Gitの内部構造と各コマンドの関係、ブランチやリモートリポジトリとの関係を分かりやすく説明したつもり。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/devRead less

fetchはリモートの「情報」を取ってくるだけ、 pullは情報を取ってきて、さらに実データをローカルに反映する。 という理解でした。 でも、fetchで何やら情報を取得している様子なのに、その後行ったpullでは何も情報が取得されない。 ということが有ったので、fetchって一体何をしているの？ということで調べてみた。 まずはブランチについて ブランチの種類 ローカルブランチ ローカルで開発するときにcheckoutで開いてコミットしていくお馴染みのもの。 ローカルで作成したブランチは、pushすることでリモート追跡ブランチにも反映される。 リモート追跡ブランチ ローカルに保持している、クローン元リポジトリのブランチを取り込んだもの。 反映はfetchやpullコマンドを実行したタイミングであり自動取得はしないので、 いつの間にかリモートリポジトリ側と不一致になっていたということも有る。

git-reflog.md git reflog についてまとめてみる reflog とは reflog（参照ログ）とは HEAD やブランチ先端の動きの履歴 各個人のローカルリポジトリに存在 ブランチの切り替え、新たに加えられた変更のプル、履歴の書き換え、あるいは単なる新規コミットの実行などを記録 git reflog で HEAD の移動履歴を、git reflog <ブランチ名> でそのブランチ先端が指していたコミットの一覧を確認可能 HEAD@{5}: HEAD の五つ前の状態を示す $ git reflog d22bfa0 HEAD@{0}: commit (amend): Add the contens of poem-c 8c9300c HEAD@{1}: commit: Add the contens of poem-c 6a67f31 HEAD@{2}: commit:

前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset