ラベル Git の投稿を表示しています。 すべての投稿を表示
ラベル Git の投稿を表示しています。 すべての投稿を表示

2012年10月20日土曜日

Eclipse EGit でのリベースのやりかた

Gitで便利な機能の1つ、リベース。
リベースの機能や動作自体については、各所で解説されているのでここでは説明しません。

便利なリベースですが、普段 Eclipse を用いて開発を行い、EGit プラグインのお世話になっていますから、リベースもぜひ EGit でやりたいでしょう。

しかし、EGit上でのリベース手順の情報が少なく、迷うことがあるでしょう。
ということで、今回は、Eclipse プラグイン EGit を用いてリベースを行う手順について説明します。

まず、リベースを行いたいブランチをチェックアウトします。

リベースを始める前に、ヒストリーを出しておくといいでしょう。
「プロジェクトのルートディレクトリを 右クリック → チーム → ヒストリーに表示」で出しておきます。

それではリベースを開始しましょう。
「プロジェクトのルートディレクトリを 右クリック → チーム → リベース...」と選択します。



リベースをどのブランチの上に行うか選択するダイアログが表示されます。


任意のブランチを選択し、「リベース」をクリックします。


リベースが始まります。表示させておいたヒストリーを見ると、リベースが行われる様子が表示されるので面白いです。

途中、リベースで適用される差分とそのコミットでの差分が衝突すると、ダイアログが表示されます。


そのままマージを開始するので「Start Merge Tool to resolve conflicts」が選択されているのを確認し「OK」をクリックします。

するとマージ方法を聞かれます。


ここでは「Use the workspace version of conflicting files」の方を選択しておきます。

マージ・ツールが起動します。
マージ・ツールではリベース前のコミットに記録されているファイルが右側、リベース対象のマージ中のファイルが左側に表示されるの出ます。左側を編集して、意図する形にします。(右側はそもそも編集不可になっています)

衝突を起こしているファイルは赤い両矢印のマークが表示されるので、それらのファイルを全て正しく編集することになります。衝突箇所が<<<<<<<,=======,>>>>>>>で区切られているのはGitコマンドラインツールと同じで、そのあたりはGit本家の解説をご参照ください。

衝突を解決しているときに、HEADと比べてみると参考になります。マージ・ツールではリベース前のコミットのファイルが表示されますが、衝突解決中のHEADはリベースが適用できた最後のコミットのファイルになっているので、比較することで衝突解決後の(リベースされたブランチ上での)変化がわかるからです。

衝突を解決できたと思った時点で、そのファイルについて「ファイルを右クリック → チーム → 比較 → HEAD」と選択して比較してみましょう。


さて、衝突を解決できたらそのファイルを Add します。Add すると、赤い両矢印の衝突マークが消えて、アスタリスクのステージングマークが表示されます。

全てのファイルの衝突を解決し Add  し終わったら、プロジェクトのルートディレクトリに表示されていた赤い両矢印の衝突マークが消えて、アスタリスクのステージングマークが表示されるでしょう。

その状態になったら、「プロジェクトのルートディレクトリを 右クリック → チーム → リベース → Continue Rebase」を選択します。


これでリベース処理が再開されます。

衝突が起きるたびに上記手順を繰り返し、最後に完了メッセージが表示されれば、リベースは完了です。

2012年6月22日金曜日

Eclipse EGit によるタグの作成とプッシュ

バージョン管理システムにおけるタグとは、特定の時点でのリポジトリの状態です。一般的にソフトウェア開発ではリリースしたバージョンをタグとして保存することが多いようです。私の場合現在仕事でアジャイルで開発しており、イテレーションごとにタグを作成する方針を採っています。

Eclipse でEGitプラグインを使っていますので、タグの作成方法について書こうと思います。(使用しているのはEGit 1.3.0.201202151440-r です。)

Gitにおけるタグの種類

まず、Git のタグには3種類あります。(参考・・・Git公式サイト:2.6 Git の基本 - タグ
  • Lightweight (軽量)タグ
    特定コミットへの単なるポインタです。 
  • Annotated (注釈付き)タグ
    チェックサムが付き、タグを作成した人の名前・メールアドレス・作成日時・タグ付け時のメッセージを保持します。 
  • Signed (署名付き)タグ
    Annotated (注釈付き)タグにさらにGPG秘密鍵による署名を付与します。対応する公開鍵により検証を行うことができます。 

EGitがサポートするタグ

これらのうち、EGit でサポートされているのはAnnotated (注釈付き)タグのみです。とはいえ、公式ドキュメントでも Lightweight (軽量)タグよりもAnnotated (注釈付き)またはSigned (署名付き)タグの利用が推奨されていますし、GPGで署名を検証する必要がある場面は少ないと思いますので、Annotated (注釈付き)タグのみで十分な場合が多いでしょう。

なお、Lightweight (軽量)タグの作成は出来ませんが読み取りは可能です。Signed (署名付き)タグについてはサポート外とされています。(参考:Light-weight and Signed Tags | EGit/User Guide

タグの作成

タグを作成するにはプロジェクトを右クリック→チーム→拡張→タグ...とメニューをたどり、タグ名と注釈を入力して「OK」ボタンをクリックすればタグが作成されます。


タグを作成した後再度タグ作成のダイアログを開いてみると、作成したタグが追加されています。なお、アイコンに黄色い人のマークが付いているものが注釈付きタグ、黄色い人のマークがないものは軽量タグです。


ちなみに軽量タグが存在する理由は、もともとリポジトリをSVNサーバから移植した際に、SVNサーバ上のタグが自動的に軽量タグに変換されたからです。(前述のとおりEGit上では軽量タグを作成できません。)

タグのプッシュ

デフォルト設定ではローカルリポジトリに作成したタグはリモートにプッシュしないようになっています。これはEGitだからというわけではなくそもそもGit自体そういう仕様のようです。

設定は以下のメニューから変更します。プロジェクトを右クリック→チーム→リモート→アップストリームからプッシュ構成…(ちなみにどうでもいいですが「アップストリームからプッシュ構成…」って誤訳ですよね。正しくは「アップストリームへプッシュ構成…」だと思います。)

出てきた「プッシュ構成」ダイアログで「参照マッピング」の「編集…」ボタンをクリックします。


「Push Ref Specifications」ポップアップが出ます。「Add All Branches Spec」ボタン、「Add All Tags Spec」ボタンをクリックして設定を追加し、「完了」ボタンをクリックします。


参照仕様が追加されているのを確認し、「保管およびプッシュ」ボタンをクリックします。
これでローカルリポジトリに作成したタグがリモートにプッシュされます。

2012年6月15日金曜日

Eclipse EGit で作業ファイルの変更を個別に元に戻す方法

ファイルをいじっていて、前回コミットした状態まで戻したくなることってありますよね。

git コマンドを使う方法なら検索すると色々出てきますが、せっかく Eclipse を使っているので、ここは EGit プラグインから GUI 上で操作をしたいところ。

これが Subversion の場合だと Subversive プラグインには「ファイルを右クリック → チーム → 戻す」メニューがありましたが、EGit では「チーム」メニューにはそれらしきものがありません。

さらに検索すると、Stack Overflow で同様の質問をしている人を発見。
http://stackoverflow.com/questions/6788881/undo-single-file-local-uncommitted-change-in-egit-e-g-svn-revert
Right click on the file -> Replace With -> File in Git Index
そっちのメニューにあったのか。

Pleiades で日本語化している場合は例えばHEADに戻す場合は
ファイルを右クリック → 置換 → HEAD改訂
とやればできます。

いやはや、EGitではファイル1つのためにもハードリセットしかないのかと一瞬思いましたが、さすがにそんなことはないって話です。

2012年6月8日金曜日

SVNリポジトリをGitに移行して中央リポジトリとして使う

現在関わっているプロジェクトでバージョン管理システムを Subversion から Git に移行したのでその時の手順をまとめてみました。

Subversion を移行する Git リポジトリは中央リポジトリとしてSSH経由でアクセスするものとし、develpoers グループに所属するユーザにアクセスを許可することにします。

また、Subversion との併用ではなく、Subversion リポジトリは残すものの基本的には Git メインで使っていくことを想定しています。

まず、Git リポジトリ用のディレクトリを作成します。
# mkdir /var/git
# cd /var/git
# mkdir repos-name.git
Git リポジトリを初期化する前に、 ディレクトリの所有者を共有用グループに変更し、グループ書き込み権限を与えます。
# chown root:developers repos-name.git
オプションに --bare と --shared=group を指定して Git リポジトリを初期化します。
# cd repos-name.git# git init --bare --shared=group
ここで作るリポジトリは中央リポジトリとして使うので、作業ファイルは不要なため --bare オプションを指定しています。また、 --shared=group オプションを指定すると、 グループでの共有に適した権限を付与してくれます。(グループ書き込み権限やディレクトリのsetgidなど。)

データを実際に移行する前に、設定ファイルを編集します。先ほどの初期化コマンドでディレクトリ内に config という名前で設定ファイルが生成されています。
# vi config

[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
[svn-remote "svn"]
url = http://example.com/svn/repos-name
fetch = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*
追加したのは赤字で示した部分です。

さらに、コミット履歴のユーザ情報を名前+メールアドレスに変換するためのファイルを用意します。
# vi ../users.txt

username = Mail Address <mail.address@example.com>
nanashi = Gonbe Nanashi <gonbe.nanashi@example.com>
ここまでできたら、あとは Subversion リポジトリからデータを取得して完了です。
# git --bare svn fetch -A ../users.txt
これでコミット履歴も含めて Git リポジトリにデータを引き継ぐことができます。


参考にしたサイト
http://blog.practical-scheme.net/shiro?20110226-sourceforge-git-migration
http://jarp.does.notwork.org/diary/200902b.html#20090213