git submodule updateしてもgit submodule initした時点のコミットにしか追従してくれません。 git submodule addしてるリポジトリ(例えば.vim/vundleとか)をgithubなどのリモートの最新に追従するにはgit submodule foreach git pull origin masterを実行します。 git statusで見るとsubmoduleで管理しているリポジトリが変更されたことになっているのでgit add/commitしておきます。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou

git remote は複数登録することができる。案外、知られていないようなのでこんな風に使ってるよ、というメモ。 remote add 例えば、以下のようにローカルのリポジトリを origin に設定している環境があるとして、 git remote -v origin file:///home/bayashi/git-repos/Foo.git (fetch) origin file:///home/bayashi/git-repos/Foo.git (push) 以下のように、bb というラベルで Bitbucket を remote に登録する git remote add bb git@bitbucket.org:bayashi/foo.git リモートが2つになりました。 git remote -v bb git@bitbucket.org:bayashi/foo.git (fe

Loading...

Gitで便利な機能の1つ、リベース。 リベースの機能や動作自体については、各所で解説されているのでここでは説明しません。 便利なリベースですが、普段 Eclipse を用いて開発を行い、EGit プラグインのお世話になっていますから、リベースもぜひ EGit でやりたいでしょう。 しかし、EGit上でのリベース手順の情報が少なく、迷うことがあるでしょう。 ということで、今回は、Eclipse プラグイン EGit を用いてリベースを行う手順について説明します。 まず、リベースを行いたいブランチをチェックアウトします。 リベースを始める前に、ヒストリーを出しておくといいでしょう。 「プロジェクトのルートディレクトリを 右クリック → チーム → ヒストリーに表示」で出しておきます。 それではリベースを開始しましょう。 「プロジェクトのルートディレクトリを 右クリック → チーム → リベース

最近ソース管理にGitを使うプロジェクトがかなり増えてきました。ソース管理はSVNで十分と思っているユーザもプロジェクトの方針としてGitになった場合、最低限の操作を覚えないと作業に支障をきたしてしまいます。その際にコマンドラインで操作しても良いのですが、今までSVNでSubversiveとかSubclipseなどを使ってきたEclipseユーザは、EclipseからGitを操作したいところです。 そこでEGitを使おうと思ってもEGit自体はそこそこ歴史がある割に意外と情報が少なくて困ってしまった人もいるのではないでしょうか？。 今回はプロジェクトで使うに当たって、最低限知っておけばどうにかなりそうな操作をまとめてみることにしました。構成としては利用者側としてGitを利用することを想定してみました。実際、作業して順番とは違うのでファイルに一部矛盾するところがありますが気にしないでください

Google Codeで管理していたコードを、GitHubに移行した際のメモになります。 OSはWindows XPでmsysGitを使用。(昨年末に買ったWindows7がまだ箱から出せていない…) 作業は、GitBash(MinGW)のコンソール上にて。 まず、作業用のディレクトリ作成。 mkdir ircbot-console cd ircbot-console続いてauthors.txtの作成。 左がGoogleアカウントで右がgitでのアカウント。 Google Codeでホスティングする際に、デフォルト(no author)でtrunk,branches,tagsが作られているので注意。 vi authors.txt(no author) = onozaty <onozaty@example.com> onozaty = onozaty <onozaty@example.com

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

新規にEcliseプロジェクトを作成して「Git Staging View」でコミットをしてみると、「Author」と「Committer」を変更してコミットしたのに、コミット直後リセットされてしまうことが分かりました。ここの設定は、コミット１回限り有効な設定になってしまうようなのです。今回はこれを回避する方法をメモ。 目次 1. 名前とメールアドレスを「Preference」から設定する1.1. 設定の書き込み先を選択する 「User Settings」と「System Settings」と「Repository Settings」から設定場所を選べます。 User Settingsは、環境変数「HOME」で設定したディレクトリにある「.gitconfig」に設定したい場合で、ユーザーにひもづけたい場合に使います。System Settingsはコンピュータ上のファイルを自由に選択でき、

みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、