Kazzzの日記

■[git]使わないと判らないこと

githubを使い始めた時はその良さが余りよく判らなかったのだが、元々SVNで使っていたGoogle Code上でgitを使うとその良さを実感している。

メリットはいろいろあると思うが、やはりローカルの環境だけでコード管理できることと、分散型ではの軽さ(サーバのキャパシティにあまり左右されない)だろう。

ツイートする

Permalink | コメント(0) | トラックバック(0)

■[VS2010][git] Visual Studio 2010からGitを操作する(Git Source Control Provider)

Mandarine-wp7ではリポジトリにgitを選択しているが、Visual Studio 2010ではgitは直接サポートされておらず、リポジトリの操作はIDEとは独立して行う必要がある。

• git bashシェルで操作する
• git GUIで操作する(一部の操作しか実施できない)
• TortoiseGitで操作する

※全てMSysGit(http://code.google.com/p/msysgit/)のインストールが必要となる。


まあ、これでも十分なのだがSVNではAnkhSVN素晴らしい拡張があった。 なのでGitもVisual Studio 2010のIDEと連携してリポジトリを操作したい所だ。

Git Source Control Provider

Git Source Control Provider - Visual Studio Gallery
Git Source Control Provider - CodePlex

Git Source Control Providerは以前に紹介したVisual Studio Color Theme Editor と同様「Visual Studio拡張機能」として提供されており、簡単にインストールして使うことができる。

　インストールと設定

インストールしてもそのままでは動かない。まずはオプション→Source Controlを開き、「現在のソース管理プラグイン」に"Git Source Control Provider"を選択する必要がある。


これで準備は完了だ。これ以降、プロジェクト又はソリューションでコンテキストメニューを開くと以下のどちらかのメニューが表示されるはず。

• まだリポジトリを作成していない場合

• 既にリポジトリがある場合

あとはgitを知っている開発者であればこの拡張で何ができるのか、何ができないかが判るだろう。

Git Source Control Providerの画面と操作

• Gitコミット予定一覧画面

コンテキストメニューから「Git - Pending Changes...」を選択するとこの画面が表示される。変更されているがまだリポジトリにはコミットされていないファイルが列挙される。ファイルを一つ選択するとファイルのDiffが右側のペインに表示される。メニューからは「コミット」、「直前のコミットを修正」※、「ブランチの切替え」、「リフレッシュ」を実行できる。

• Git履歴画面

現在のリビジョン、タグがチャートで表示される。また、この画面でブランチを切替えたり上記コミット一覧画面にジャンプすることもできる。

なお、"Git Source Control Provider Options"に追加の情報を設定することでシェル(Git Bash)を呼び出したり、TortoiseGitのコマンドを呼び出すことができるようになる。

ちなみに"Git Extensions"はTortoiseGitと似たGit操作ツール。私はインストールしていない。

この設定をした後のコンテキストメニューは以下のように変化する。


GitBashシェルを直接呼び出したり、TortoiseGitの機能をここから直接呼び出すことができる。


上記のメニューから"Show Log"呼び出した結果

以上のようにVisual Studio 2010とGitをある程度連携させることができるのが中々に便利だ。(込み入ったことは結局シェルからコマンドを打つことが多いが)また、GitはSVNのようにリモートの情報をキャッシュしておく必要が無いので全体的に動作が軽いのも良い所だと思う。


※"Amend commit"であり下手に使うとリモートのリポジトリとの同期が崩れPush/Pullが出来なくなるため、注意が必要だ。

ツイートする

Permalink | コメント(0) | トラックバック(1)

■[git]Google Codeのgitとnon-fast-forwardエラー

Mandarine-wp7ではリポジトリにgitを選択している。
svnがgitになってもやることは変わらなくて、最初はローカルにあるファイルをGoogle Codeのサーバにアップするが、gitの場合は既にローカル側にリポジトリがあることが殆どなので、まずはこれをリモートにプッシュする。

その時のプッシュは全く問題無く終わったのだが、その後幾つかのファイルを修正して追加でコミットし、その後再度プッシュした時に問題は発生した。

>git push 
To https://〜.git
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'https://〜.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'non-fast-forward'
section of 'git push --help' for details.

何度プッシュしてもこのメッセージが出てリモートにコミットが反映されない。そもそも"non-fast forward"ってなんだろう。と調べてみたのだが「プッシュ先のコミットの子孫では無い」とされた場合にこのエラーが出てしまうらしい。つまりは自分以外が既に修正している、ということ。しかし、そもそも最初にプッシュした以外は何もしていないしんだけどなぁ。

と調べていたところ、気になる記述をいくつか見つけた。

個人で使っている場合でもcommit --amendを行った後にpushを実行すると歴史が失われるためnon-fast-forwardが発生する。
Git - 個人的なメモのページ PukiWiki plus!

最後の部分、--amend でコミットしたせいでリモートの情報とローカルの情報が 食い違ってしまっていて、そのままだと push させてくれない。
ソフトウェア/rails/言語ネゴシエーション/github を使った公開 - takeuchi@ShigekawaLab

なるほど、下手に"git commit --amend"を使ってしまうとプッシュ済みのリモートとローカルのコミット済みの情報に差異が出てしまうため、以降普通にプッシュできなくなるらしい。なるほど、私も確かに"commit --amend"をしたのだ。

解決方法としては

• 作業用にブランチを作ってそちらにプッシュし、その後masterとマージする
• git push --forceで強制的に上書きする (その後コンフリクトが発生するが無視してプッシュする)
• git pull origin masterでローカル側を一旦合わせて再度修正する

等があるが今回はまだブランチは実質無いし、作成して日が浅いので強制的にプッシュすることで済ませてしまった。今後同じケースを発生させないためにも、"--amend"オプションはできるだけ使わないほうが良さそうだ。

ツイートする

Permalink | コメント(0) | トラックバック(0)