JavaのWebアプリケーション開発フレームワークによる、Webサイト開発の顛末記です。

EclipseのMavenを使った、Spring-MVC、Thymeleaf、MyBatis 等のプログラミングテクニックを、
備忘録的に記録しています。実際に動くソースコードを多用して説明していますので、
これからEclipseや、Spring-MVCを始めたいと思っている人にとって、少しでも参考になれば幸いです。
■あぜ道 Eclipseの小技
gitローカルリポジトリの作成
EclipseでJavaのプロジェクトなどを開発する場合に限らず
どんな言語で開発するにしても、ソースのバージョン管理は重要です。
頑張って作ったプログラムソースコードを間違って削除してしまったり
何らかの理由で、一つあるいは二つ前のソースに戻したいような場合もあります。
そのためには、ソースファイルを日付付きでバックアップするとか、
Eclipseのプロジェクト全体を毎日バックアップして履歴管理するとか
方法はないことはありませんが、労力がいる割には効率がいい方法とは言えません。
Eclipseには、Subversion(SVN)や、Gitといった
バージョン管理ツールが標準で用意されているので、これらを有効活用しましょう。
個人的には、Subversion(SVN)も、Gitも両方使っていますが、
世の中の主流は、Gitに移行されつつあるようなので、
ここでは、EclipseでGitを使ったバージョン管理の方法を説明します。

Gitの基本的な説明は、ネットを漁ればたくさん情報があるので各自調べてみてください。
分かりやすいところでは、「サル先生」の
サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 あたりがお勧めです。

 

では、さっそくEclipseでGitローカルリポジトリを使ったプロジェクト管理方法を説明します。
まず、EclipseGitの管理単位は、Eclipseプロジェクト単位になるため、まだプロジェクトが作成されていない場合は、
■SpringMVC の小径 1-1)Mavenプロジェクトの生成」を見て、プロジェクトを作成してください。
ここで注意することは、プロジェクトの作業ディレクトリを、Eclipseワークスペース内ではなく、
Eclipseワークスペース外で設定しておく事。理由は後述します。

Eclipseの「ナビゲータビュー」(パッケージエクスプローラ、プロジェクトエクスプローラとかでも可)
のプロジェクト名を選択して、マウス右ボタンをクリックします。
メニューが表示されるので「チーム」-「プロジェクトの共用」を選択します。
プロジェクトの共用

 

「プロジェクトの共用」サブウィンドウが表示されるので、
「Git」を選択して、「次へ」ボタンをクリックします。
リポジトリタイプの選択

 

ここで、このプロジェクトがEclipseワークスペース内で設定されていると、どうなるかというと
間違ごぅとるばい
「リポジトリをEclipseワークスペース内に作成するのはお勧めできません」
とか警告されてしまうので、注意しましょう!

 

プロジェクトの構成に問題がなければ、「Gitリポジトリの構成」サブウィンドウが開きます。
「プロジェクトの親フォルダー内のリポジトリーを使用または作成」のチェックボックスをチェックします。
下の「プロジェクト」のチェックボックスをクリックすると下図のような状態となります。

プロジェクトの作業ディレクトリロケーションに間違いがないことを確認したら
「リポジトリの作成」ボタンをクリックします。
Gitリポジトリの構成

 

「完了」ボタンをクリックして、Gitローカルリポジトリの作成は完了です。
Gitリポジトリ作成完了

 

Eclise「ナビゲータ」ビューを確認すると
ナビゲータ
プロジェクト名の右側に「プロジェクト名 NO-HEAD」が表示されるようになりました。
プロジェクト名のすぐ下に「.git」というフォルダが表示されています。
これは、Gitローカルリポジトリ自体の作業ディレクトリとなります。
邪魔だからといって、絶対に削除してはいけません!!
いすれその内(Eclipseを再起動したりするうち)見えなくなるので放置しましょう。

 

よく見ると、プロジェクト名の左側に、> の印が表示されています。
これは何かというと、Gitリポジトリより新しい(変更された)
Gitリポジトリにコミットされていないファイルがありますよ!
というマークです。
Gitリポジトリを作成したばかりで、まだ一度もコミットしていないので当然といえば当然の話。
なので、初期コミットを実施します。
Eclipseプロジェクト名を選択し、マウスの右ボタンクリックでメニューが表示されるので、
「チーム」-「コミット」を選択します。
リポジトリのコミット

 

「変更をGitリポジトリーにコミット」というサブウィンドウが開きます。
コミットメッセージに適当なメッセージを入力します。(⇒ここが空だとコミットできません)
下のファイル一覧にコミット対象のファイルの一覧が表示されています。
チェックボックスのチェックを外すと、そのファイルはコミットされません。
最初のコミットなので全部コミットします。
「ファイル」タイトルの右側のチェックボックスをチェックすると、
一覧のファイルが全部一括でチェックされます。
チェックしたら「コミット」ボタンをクリックします。
リポジトリのコミット

 

Eclise「ナビゲータ」ビューを確認すると
ナビゲータ
プロジェクトr名の右側の名称が「プロジェクト名 master」に変更されました。
これで、リポジトリのコミット完了です。

 

■Gitローカルリポジトリの使い方
Gitの作成は分かりましたが、んじゃこれが一体何の役に立つのさ?
と思われるでしょうから、一つ例を挙げておきましょう。
本編で作成した、index.html を少し修正してみます。
ソースコード変更
charsetと、メッセージを少し変更して保存してみました。
あぁぁぁ!しまったぁぁ!!
変更箇所を間違ってしまった。
ほんとは「タイトル」を修正するつもりだったのに!
なんて、これぐらいだったら別にどうってことはありませんが
ほんとのプロジェクトでは、数百から数千ステップもあるかというソースコードなので
どこをどう変更したかなんていちいち覚えていないのも実情。
さてどうしましょう。。。

 

修正した未コミットのファイルには、>マークが付いているので
今修正した、index.html を選択してマウスの右ボタンをクリックします。
メニューが表示されるので、「比較」-「HEAD改訂」を選択します。
ソースコード変更

 

エディットビューに、左右に分かれた比較ソースコードが表示されました。
左がローカル(今編集したファイル)、右がローカルリポジトリにコミットされているファイル。
枠で囲まれている箇所が、変更された箇所(リポジトリの内容と異なる箇所)です。
変更箇所が一目瞭然です。
ソースコード差異

 

間違ってファイルを修正してしまった場合など、リポジトリから戻したい時などは
中央の小さな□マークにマウスカーソルを当てると、
<マークに変わるのでこのマークをクリックすると
リポジトリの内容が、ローカルのファイルに適用されます(修正前に戻る)
変更内容を戻す

 

「比較」-「HEAD改訂」は、直前のコミット内容しか表示できませんが、
もっと以前のリポジトリを見たい時は、
「比較」-「ローカルヒストリー」を選択します。
変更内容を戻す

 

「ヒストリー」ビューが表示されて、過去コミットされたリビジョンの一覧が表示されるので
どれかをマウスでダブルクリックすると、エディットビューに比較ソースコードが表示されます。
変更内容を戻す

 

Oh my God !!!!!!!!!!
手が滑って、ファイルを削除しちまったぁぁぁぁぁ!!
どうしよう( ノД`)シクシク…
慌てない、慌てない ぽくぽくぽく....チーン!
ファイルを間違って消しちゃったヨー( ノД`)シクシク…
ナビゲータを確認すると、削除されたファイルの親のフォルダーに、黒枠に白抜きの「*」マークが表示されています。
これは、「未コミットの削除ファイルがあります。」のマークです。
意識的に削除したいファイルがある場合は別ですが、間違ってファイルを消してしまった場合、
この状態をコミットしてはいけません。(ファイルが復元できなくなります)

 

黒枠に白抜きの「*」マークが付いたフォルダーを選択し、マウスの右ボタンをクリックします。
メニューが表示されるので、「置換」ー「HEAD改訂」を選択します。
ファイルの復元

 

「ローカル変更の破棄」ダイアログボックスが表示されるので
「OK」ボタンをクリックします。
ローカル変更の破棄

 

無事、削除してしまった index.html が復元されました。
ファイルを間違って消しちゃったヨー

 

これでもう、ソースバージョン管理の煩わしさから解放されて、開発に集中できますね!
めでたし、めでたし。

Gitのリポジトリ管理方法には、もう一歩先の世界。
共有リポジトリ(リモートリポジトリ)管理という方法があって、これはローカルPCの外の世界
外部のサーバー上の共有リポジトリと、ローカルリポジトリを連携する管理方法があります。
これを行うと、ネットさえ繋がっていれば(アカウントは当然必要ですが)
どこにいようが、常に最新のプロジェクトが編集可能となります。
一方、これは複数のプロジェクト開発メンバーで共有するリポジトリであるため、
気を付けないと人にファイルを上書きされてしまったりといった
ソースの競合(コンフリクト)状態が発生したりする危険もあります。
これらに付いては、またいずれ機会があればお話ししたいと思います。