EclipseのEGitとは？Gitとの違いや役割を初心者向けにわかりやすく解説

2026年8月18日 2026年8月18日山崎講師

山崎講師

こんにちは。ゆうせいです。

Eclipseを使った開発現場では、「EGitを使ってソースコードを取得してください」「修正したらコミットしてプッシュしてください」と言われることがあります。

新人研修で初めて聞くと、

「EGitって何？」
「Gitとは違うの？」
「GitHubも聞いたことがあるけど、何が違うの？」

と混乱してしまうかもしれません。

そこで最初の章では、実際の操作に入る前に「EGitとは何なのか」を整理していきます。

難しい操作はまだ行いません。

まずは、Git・EGit・Eclipseの関係を理解するところから始めましょう！

EGitとは

EGitとは、EclipseからGitを操作するための機能です。

Eclipse Foundationの公式情報では、EGitは「JGit」と呼ばれるJava製のGit実装をEclipse上で利用するためのツールとして開発されています。(Eclipse Help)

少し難しく聞こえますよね。

新人研修の段階では、

「EGitを使えば、Eclipseの画面からGitを操作できる」

と理解しておけば十分です。

Gitそのものは、コマンドを入力して操作できます。

たとえば、ソースコードの変更を記録したり、サーバーに変更内容を送ったりするときにはGitのコマンドを使用できます。

一方、EGitでは多くのGit操作をEclipseのメニューや画面から実行できます。

つまり、

Git = バージョン管理を行う仕組み

EGit = EclipseからGitを操作するための道具

という関係です。

たとえば、テレビを想像してみてください。

テレビ本体がGitだとすると、リモコンがEGitです。

リモコンがなくてもテレビ本体のボタンを押せば操作できます。しかし、リモコンがあれば手元から操作できますよね。

EGitも似ています。

Gitの仕組みそのものが変わるわけではなく、Eclipse上からGitを操作しやすくしてくれる存在なのです。

そもそもGitとは

EGitを理解するためには、まずGitについて知っておく必要があります。

Gitとは、ソースコードなどの変更履歴を管理するための「バージョン管理システム」です。

バージョン管理システムとは、ファイルが「いつ」「誰によって」「どのように変更されたのか」を記録しておく仕組みを指します。

たとえば、学校のレポートを作成しているとしましょう。

修正するたびに、

report.docx

report_修正版.docx

report_修正版2.docx

report_最終版.docx

report_最終版_本当に最終.docx

などとファイルを増やした経験はありませんか？

少人数で個人的に管理しているだけなら、まだ何とかなるかもしれません。

しかし、10人、20人で同じシステムを開発していたらどうでしょう。

「誰がどこを変更したの？」

「昨日の状態に戻したい！」

「自分が修正していたファイルを別の人も変更している！」

といった問題が発生します。

そこで活躍するのがGitです。

Gitを利用すると、変更内容を履歴として記録できます。

過去の変更を確認したり、複数人で変更内容を共有したりできるため、チームでソフトウェアを開発するときに非常に便利です。

「保存」と「Gitへの記録」は違う

新人のうちは、特に注意してほしいポイントがあります。

Eclipseでファイルを保存することと、Gitに変更履歴を記録することは別です。

たとえばJavaファイルを書き換えて、Ctrl + Sで保存したとします。

保存された時点では、パソコン上のファイルが更新されただけです。

Gitの正式な変更履歴として保存されたわけではありません。

Gitでは、変更内容を履歴として記録する操作を「コミット」と呼びます。

コミットについては後の章で詳しく解説しますが、現時点では、

保存 = ファイルの内容を保存する

コミット = Gitの変更履歴として記録する

という違いを覚えておいてください。

この違いは非常に重要です！

「保存したからGitにも登録されたはず」と考えないようにしましょう。

Eclipseとは

Eclipseは、プログラムを作成するための統合開発環境です。

統合開発環境は「IDE」とも呼ばれます。

IDEはIntegrated Development Environmentの略です。

プログラムを書くためには、ソースコードを編集するだけではありません。

プログラムの実行、エラーの確認、デバッグ、ファイル管理など、さまざまな作業が必要になります。

Eclipseでは、そうした開発作業を1つの環境で行えます。

たとえるなら、Eclipseは「プログラマーの作業机」です。

机の上には、

・ソースコードを書く道具

・プログラムを実行する道具

・エラーを調べる道具

・プロジェクトを管理する道具

などがそろっています。

そして、その作業机に「Gitを操作するための道具」を追加したものがEGitだと考えると分かりやすいでしょう。

GitとEGitの違い

ここまでの内容を整理してみましょう。

GitとEGitは同じものではありません。

Gitは、ソースコードなどの変更履歴を管理する仕組みです。

EGitは、そのGitをEclipseから扱うためのツールです。

たとえば、Gitではコマンドを使って、

・変更されたファイルを確認する

・変更を記録する

・過去の変更履歴を見る

・別のリポジトリからソースコードを取得する

・自分の変更をリモートリポジトリへ送る

といった操作ができます。

EGitを利用すると、同様の作業をEclipseの画面から行えます。

Eclipseの公式EGitユーザーガイドでも、プロジェクトのGit管理、変更の記録、履歴確認、リポジトリの取得などの操作方法が案内されています。(Eclipse Help)

新人研修では、まずEGitを使ってGitの基本的な流れを覚えていきましょう。

GitHubとEGitは何が違う？

Gitを勉強すると「GitHub」という名前もよく目にします。

GitとGitHub、さらにEGitまで登場すると、混乱しやすいところです。

役割を分けて考えてみましょう。

Gitは、変更履歴を管理する仕組みです。

EGitは、EclipseからGitを操作するためのツールです。

GitHubは、Gitで管理しているリポジトリをインターネット上で共有・管理するためのサービスの1つです。

たとえば会社で書類を共同編集するとしましょう。

Gitは「書類の変更履歴を管理する仕組み」。

EGitは「自分のパソコンから変更履歴を操作するための画面」。

GitHubなどのサービスは「チームのみんなが書類を共有する保管場所」。

このように考えると、それぞれの役割が分かりやすくなります。

なお、実際の開発現場ではGitHub以外のGitホスティングサービスが利用される場合もあります。

そのため、

「Gitを使う = 必ずGitHubを使う」

というわけではありません。

EGitを使うメリット

EGitには、Gitを初めて扱う人にとっていくつかのメリットがあります。

まず、Eclipseから離れずにGitを操作できます。

Javaのソースコードを修正したあと、そのままEclipse上で変更内容を確認してコミットできます。

さらに、変更されたファイルを画面上で確認できる点も便利です。

「どのファイルを変更したのか」

「変更前と変更後で何が違うのか」

といった情報をEclipse上で確認できます。

コマンドをすべて暗記しなくても基本操作を進められるため、新人研修ではGitの作業イメージをつかみやすいでしょう。

EGitを使うデメリット

一方で、EGitにも注意点があります。

画面上のボタンを押すだけで操作できるからこそ、「裏側でGitが何をしているのか」が分からないまま使えてしまいます。

たとえば、

「Commit」

「Push」

「Pull」

といったボタンの意味を理解せず、とりあえず押してしまうのは危険です。

車の運転に例えるなら、

「アクセルを踏めば進むことは知っているけれど、ブレーキの役割は知らない」

ような状態になってしまいます。

EGitのボタンの位置だけを暗記するのではなく、

「今、自分はGitに何をさせているのか？」

を考えながら操作してください。

新人研修では、EGitの操作と一緒にGitの基本用語も覚えていくことが重要です。

新人研修ではEGitのどこまで覚えればいい？

EGitには多くの機能があります。

すべてを最初から覚える必要はありません。

新人研修では、まず次の流れを自分で実行できることを目標にしましょう。

リモートにあるプロジェクトを取得する

↓

ソースコードを修正する

↓

変更内容を確認する

↓

変更をコミットする

↓

必要に応じて最新の変更を取得する

↓

自分の変更をリモートへ送る

Gitでは、それぞれの操作に「Clone」「Commit」「Pull」「Push」といった名前が付いています。

専門用語が一気に増えてきましたね。

安心してください。

次の章で、EGitを使ううえで最低限知っておきたいGit用語を一つずつ解説していきます。

単語だけを丸暗記する必要はありません。

「何のために行う操作なのか」をイメージできるようになることが最初の目標です。

第1章のまとめ

EGitとは、EclipseからGitを操作するためのツールです。

GitそのものとEGitは別物なので、まずは次の関係を覚えておきましょう。

Gitは、ソースコードなどの変更履歴を管理する仕組み。

Eclipseは、プログラムを開発するための統合開発環境。

EGitは、Eclipse上からGitを操作するためのツール。

そしてGitHubなどのサービスは、Gitリポジトリをチームで共有するために利用できるサービスです。

新人の段階では、EGitに存在するすべての機能を覚える必要はありません。

まずは「Gitが何をする仕組みなのか」「EGitがどのような役割を持っているのか」を説明できるようにしてください！

次の章では、リポジトリ、コミット、ステージ、クローン、プル、プッシュなど、EGitを使うために最低限知っておきたいGit用語を解説します。

用語の意味が分かるようになると、EGitの操作も一気に理解しやすくなります。次はGitの基本用語を身につけて、実際の操作へ進む準備を整えましょう！

第2章 EGitを使う前に覚えたいGitの基本用語｜リポジトリ・コミット・Push・Pullを解説

第1章では、GitとEGitの役割について説明しました。

Gitはソースコードなどの変更履歴を管理する仕組みで、EGitはEclipseからGitを操作するためのツールです。

それでは、さっそくEGitを操作してみましょう！

……と言いたいところですが、その前に覚えておきたいものがあります。

Gitで使われる専門用語です。

EGitを操作すると、

「Repository」
「Commit」
「Push」
「Pull」
「Branch」

といった言葉が頻繁に登場します。

意味を知らないまま操作すると、

「Pushって、とりあえず押せばいいの？」

「Commitしたのに、ほかの人から変更が見えないのはなぜ？」

といった疑問が出てきます。

新人研修の段階ですべてのGit用語を覚える必要はありません。

この章では、実際の業務で特に使用する次の用語を中心に説明します。

・リポジトリ

・ローカルリポジトリ

・リモートリポジトリ

・ワーキングツリー

・ステージング

・コミット

・クローン

・プッシュ

・フェッチ

・プル

・ブランチ

用語を丸暗記するのではなく、「何をする場所なのか」「何をする操作なのか」というイメージをつかんでください。

リポジトリとは

最初に覚えたいのが「リポジトリ」です。

Repositoryと表記される場合もあります。

リポジトリとは、Gitがファイルや変更履歴を管理するための保管場所です。

単純なフォルダーとの大きな違いは、現在のファイルだけでなく、過去の変更履歴も管理している点にあります。

たとえば、学校で文化祭の企画書を何人かで作るとしましょう。

普通のフォルダーでは、現在の企画書を保存できます。

一方、Gitのリポジトリでは、

「最初に作った企画書」

「予算を修正した企画書」

「先生から指摘されて修正した企画書」

といった変更の記録も残せます。

Gitを使った開発では、このリポジトリを中心に作業を進めます。

EGitの画面にも「Git Repositories」という名前が登場するので、Repositoryという英単語にも慣れておきましょう。

ローカルリポジトリとは

リポジトリには、大きく分けて「ローカルリポジトリ」と「リモートリポジトリ」があります。

まず、ローカルリポジトリから見ていきましょう。

ローカルリポジトリとは、自分のパソコン上に存在するGitリポジトリです。

ローカルは「手元にある」と考えると分かりやすいでしょう。

自分がソースコードを変更して、その内容をGitに記録すると、基本的にはローカルリポジトリへ保存されます。

ここで非常に重要なのが、

「コミットしただけでは、ほかの人に変更内容は共有されない」

という点です。

たとえば、自分のノートに授業内容を書いても、クラスメイトのノートには自動的に反映されませんよね。

ローカルリポジトリも同じです。

自分のパソコンにある変更履歴なので、コミットしただけでは自分のパソコン内に記録された状態です。

ほかの人と変更を共有するためには、後ほど説明する「プッシュ」という操作が必要になります。

リモートリポジトリとは

リモートリポジトリとは、ネットワーク上に置かれ、チームで共有するために使われるリポジトリです。

GitHub、GitLab、Bitbucketなどのサービス上に配置される場合もありますし、会社内のGitサーバーに配置される場合もあります。

新人研修では、

ローカルリポジトリ = 自分専用

リモートリポジトリ = チームで共有

と考えておけば十分です。

会社の共有フォルダーを想像してみてください。

自分のパソコンだけに資料を保存しても、ほかの社員からは見られません。

共有フォルダーへ資料を置けば、チームメンバーが確認できます。

Gitでも似たような考え方をします。

ただし、Gitの場合はファイルそのものだけではなく、変更履歴も含めて管理します。

ローカルとリモートは別の場所にある

Git初心者が特につまずきやすいポイントなので、ローカルリポジトリとリモートリポジトリの違いはしっかり押さえてください。

たとえば、あなたがJavaファイルを修正してコミットしたとします。

その時点では、

自分のパソコンにあるローカルリポジトリ

に変更が記録されています。

まだリモートリポジトリには反映されていません。

変更内容をチームへ共有したい場合は、

ローカルリポジトリ

↓

リモートリポジトリ

という方向へ変更履歴を送ります。

変更履歴を送る操作が「Push」です。

反対に、ほかのメンバーがリモートリポジトリへ送った変更を自分の環境へ取り込みたい場合は、

リモートリポジトリ

↓

ローカルリポジトリ

という方向になります。

Gitを勉強するときは、「今どこにある情報を、どこへ移動させようとしているのか」を意識してください。

PushやPullの意味が格段に理解しやすくなります。

ワーキングツリーとは

次は「ワーキングツリー」です。

Working TreeやWorking Directoryと呼ばれる場合もあります。

ワーキングツリーとは、実際に自分がファイルを編集している作業領域です。

EclipseでJavaファイルを開いてソースコードを書き換えた場合、そのファイルはワーキングツリー上で変更されています。

たとえば、机の上にレポートを広げて編集している状態を想像してください。

机の上には、現在作業している最新版のレポートがあります。

Gitでいうワーキングツリーも、似たような場所です。

Eclipseで普段見ているプロジェクトのファイルは、基本的にワーキングツリーにあるファイルだと考えてください。

ただし、ファイルを編集しただけではGitの履歴として確定していません。

「変更した」という状態になっただけです。

そこから、ステージングとコミットという操作を行います。

ステージングとは

ステージングとは、次のコミットに含めたい変更を選ぶ操作です。

Gitを初めて使う人にとって、少し分かりにくい概念かもしれません。

「変更したなら、そのままコミットすればいいのでは？」

と思いませんか？

Gitでは、変更したファイルの中から「今回のコミットに含めたいもの」を選択できます。

たとえば、次の3つのファイルを変更したとしましょう。

User.java

README.md

User.javaとLogin.javaはログイン機能の修正です。

README.mdは、たまたま見つけた誤字を直しただけだったとします。

全部を1つのコミットにすると、

「ログイン機能の修正」と「READMEの誤字修正」

という関係のない変更が混ざってしまいます。

そこでGitでは、User.javaとLogin.javaだけをステージングしてコミットできます。

README.mdは、あとで別のコミットにできます。

旅行の荷造りに例えてみましょう。

部屋の中には、服、教科書、ゲーム機、財布などがあります。

しかし、旅行へ持っていくものを全部持っていくわけではありませんよね。

必要なものだけスーツケースに入れます。

ワーキングツリーが部屋だとすれば、ステージングは「次に持っていくものをスーツケースへ入れる作業」です。

そして、スーツケースに入れたものをひとまとまりとして記録するのがコミットです。

EGitでは、Git Stagingビューを使ってステージングする機会が多くあります。

Unstaged Changes

Staged Changes

という表示が出てきます。

Unstaged Changesは「変更されているが、まだ次のコミットに入れると決めていない変更」です。

Staged Changesは「次のコミットに入れると決めた変更」です。

英語なので最初は難しく感じますが、何度か操作すると自然に分かるようになります。

コミットとは

コミットは、Gitを使ううえで最重要といってもいい操作です。

Commitとは、ステージングした変更内容を、ひとまとまりの変更履歴としてローカルリポジトリへ記録する操作です。

たとえば、ログイン機能を修正したとします。

User.javaを変更

↓

2ファイルをステージング

↓

「ログイン時の入力チェックを追加」という内容でコミット

このような流れです。

コミットすると、その時点の変更内容がGitの履歴として残ります。

ゲームでいう「セーブポイント」を作るイメージに近いでしょう。

ただし、Gitのコミットでは単に状態を保存するだけではありません。

「何を変更したのか」を示すコミットメッセージも一緒に記録します。

たとえば、

修正

というコミットメッセージでは、後から見た人が何を修正したのか分かりません。

一方、

ログイン画面の入力チェックを追加

と書いてあれば、変更内容を想像できます。

コミットメッセージは、自分だけでなく、あとから履歴を見る人のために書くものだと考えてください。

保存・ステージング・コミットの違い

ここは新人研修で特に混乱しやすいところです。

3つの操作は別物です。

ファイルを保存する

↓

ファイルの内容がパソコン上で更新される

ステージングする

↓

次のコミットへ含める変更を選ぶ

コミットする

↓

選んだ変更をGitの履歴として記録する

たとえば、学校へ提出する作文に置き換えてみましょう。

文章を書く

↓

保存する

提出するページを選ぶ

↓

ステージングする

提出用としてひとまとまりにする

↓

コミットする

というイメージです。

EclipseでCtrl + Sを押しただけでは、コミットされません。

ステージングしただけでも、まだコミットされていません。

それぞれ別の操作なので注意してください。

クローンとは

Cloneとは、リモートリポジトリを自分のパソコンへ複製する操作です。

新人として既存の開発プロジェクトへ参加するときは、自分で新しいリポジトリを作るよりも、すでに会社で管理されているリポジトリを取得することが多いでしょう。

そのときに使用するのがクローンです。

たとえば、会社のリモートリポジトリに、

SampleSystem

というシステムが保存されているとします。

クローンすると、SampleSystemのリポジトリを自分のパソコンへ持ってこられます。

単純なファイルのコピーとは少し違います。

ソースコードだけではなく、Gitが管理している変更履歴なども含めて取得します。

図書館にある本を1ページずつ写真撮影するのではなく、本を履歴情報ごと手元へ複製するようなイメージです。

新人研修では、

「初めてプロジェクトを自分のパソコンへ持ってくる操作」

くらいに覚えておけば問題ありません。

プッシュとは

Pushとは、ローカルリポジトリの変更履歴をリモートリポジトリへ送る操作です。

日本語では「押す」という意味ですね。

自分の変更を共有側へ押し出すイメージで覚えると分かりやすいでしょう。

基本的には、

ファイルを修正

↓

ステージング

↓

コミット

↓

Push

という流れになります。

重要なのは、コミットとPushが別の操作だという点です。

コミットしただけでは、自分のローカルリポジトリへ記録されただけです。

チームのメンバーへ変更を共有するには、リモートリポジトリへPushする必要があります。

たとえば、会社で日報を書いたとしましょう。

自分のパソコンに日報を保存した状態がCommit。

会社の共有システムへ提出した状態がPush。

そんなイメージです。

「Commitしたから共有された」と勘違いしないようにしてください！

フェッチとは

Fetchとは、リモートリポジトリの最新情報を取得する操作です。

ただし、自分が作業しているファイルへすぐに変更を反映するわけではありません。

この点が、後ほど説明するPullとの大きな違いです。

たとえば、学校の掲示板に新しいお知らせが出ているとしましょう。

Fetchは、

「掲示板を確認して、新しいお知らせがあることを把握する」

ような操作です。

まだ自分の予定表を書き換えたわけではありません。

まずリモートリポジトリの状態を確認したい場合に利用できます。

新人研修ではFetchを単独で頻繁に使わない可能性もありますが、Pullとの違いを理解するために存在を覚えておくとよいでしょう。

プルとは

Pullとは、リモートリポジトリにある変更を取得し、自分の作業側へ取り込む操作です。

Pullは英語で「引く」という意味です。

リモート側にある変更を、自分の側へ引っ張ってくるイメージで覚えましょう。

たとえば、AさんとBさんが同じシステムを開発しているとします。

Aさんが修正をCommitしてPushしました。

その時点で、リモートリポジトリにはAさんの最新変更があります。

しかし、BさんのパソコンにはまだAさんの変更がありません。

BさんがPullすると、リモートリポジトリにある変更を自分の環境へ取り込めます。

チーム開発では非常によく使う操作です。

FetchとPullは何が違う？

FetchとPullは、どちらもリモートリポジトリから情報を取得するため、最初は混同しやすいでしょう。

簡単に分けると、

Fetch

リモートの最新情報を取得する

Pull

リモートの最新情報を取得して、自分の作業側へ反映する

という違いがあります。

たとえば、スマートフォンのアプリに新しいアップデートがある場合を考えてみます。

「新しいバージョンが出ています」と情報を確認するだけなのがFetch。

実際にアップデートして自分のアプリを最新版にするところまで行うのがPull。

そんなイメージで考えると分かりやすいでしょう。

厳密な内部処理はもう少し複雑ですが、新人研修ではまず、この違いを理解できれば十分です。

PushとPullは方向で覚える

PushとPullを混同する場合は、「変更が動く方向」を意識してください。

Pushでは、

自分のローカルリポジトリ

↓

リモートリポジトリ

という方向です。

Pullでは、

リモートリポジトリ

↓

自分のローカル環境

という方向です。

英単語の意味そのままですね。

Pushは押し出す。

Pullは引っ張る。

「自分を中心に考える」のがポイントです。

自分からリモートへ送るならPush。

リモートから自分へ持ってくるならPull。

ここまで理解できれば、実際にEGitのメニューを見たときにも操作を判断しやすくなります。

ブランチとは

最後に「ブランチ」について簡単に説明します。

Branchとは、日本語で「枝」という意味です。

Gitでは、開発の流れを枝分かれさせて作業する機能をブランチと呼びます。

たとえば、現在正常に動いているシステムへ新機能を追加するとしましょう。

いきなり本番用のソースコードを直接変更して、新機能が完成するまで動かなくなったら困りますよね。

そこで、現在の開発ラインから別のブランチを作り、新しい機能を開発します。

ゲームのセーブデータを想像すると分かりやすいでしょう。

セーブデータAではストーリーを普通に進めます。

一方、セーブデータAをコピーしたセーブデータBを作り、別の選択肢を試します。

セーブデータBで失敗しても、元のセーブデータAには影響しません。

Gitのブランチにも似た考え方があります。

チーム開発では非常に重要な機能ですが、新人研修では会社ごとにブランチの運用ルールが異なる場合があります。

まずは、

「開発の流れを分岐させて、別の作業を進めるための仕組み」

と覚えておきましょう。

まず覚えるべき5つの用語

ここまで多くの専門用語が登場しました。

全部覚えられそうでしょうか？

一度で完璧に覚える必要はありません。

新人研修で特に優先したいのは、次の5つです。

Commit

変更内容をローカルリポジトリへ記録する

Clone

リモートリポジトリを自分のパソコンへ複製する

Push

自分の変更履歴をリモートリポジトリへ送る

Pull

リモートリポジトリの変更を自分の環境へ取り込む

Repository

Gitがファイルや変更履歴を管理する場所

まずは、この5つの意味を自分の言葉で説明できるようにしてください。

新人が覚えておきたいGitの基本的な流れ

最後に、ここまで登場した用語を1つの流れにつなげてみましょう。

既存プロジェクトへ初めて参加するときは、リモートリポジトリをCloneします。

↓

Eclipseでソースコードを編集します。

↓

変更したファイルから、今回記録したい変更をStageします。

↓

Stageした変更をCommitします。

↓

必要に応じてリモートリポジトリの最新変更をPullします。

↓

自分のCommitをPushしてチームへ共有します。

最初は用語が多く感じるかもしれません。

しかし、実務で何度も同じ流れを繰り返していると、

「Commitは記録」

「Pushは送信」

「Pullは取得して反映」

というように、自然と意味が身についていきます。

ボタンの場所だけを暗記するのではなく、「今どこからどこへ変更が移動しているのか」を考えながら操作してください。

第2章のまとめ

EGitを操作するためには、Git特有の用語をいくつか理解しておく必要があります。

特に重要なのは、ローカルリポジトリとリモートリポジトリが別の場所だという点です。

ファイルを編集しただけではGitの履歴にはなりません。

変更をステージングしてCommitすることで、ローカルリポジトリへ履歴として記録されます。

さらに、Commitした内容をほかのメンバーへ共有するにはPushが必要です。

反対に、ほかのメンバーがリモートリポジトリへ反映した変更はPullなどを使って取得します。

最初は、

Clone → 編集 → Stage → Commit → Pull → Push

という一連の流れをイメージできれば十分です。

次の章では、実際にEclipseでEGitを使い始めるための初期設定を行います。

Gitのユーザー名やメールアドレスなど、「なぜ設定する必要があるのか」も理解しながら進めていきましょう。

第3章 EclipseでEGitを使うための初期設定｜ユーザー名とメールアドレスを設定しよう

第2章では、Repository、Commit、Push、Pullなど、EGitを使うために最低限知っておきたいGit用語を説明しました。

ここからは、実際にEclipseを操作していきます。

最初に行うのがEGitの初期設定です。

特に重要なのが、

・ユーザー名

・メールアドレス

の2つです。

「ログインするわけでもないのに、なぜ名前とメールアドレスを設定するの？」

と思うかもしれません。

Gitでは、誰が変更したのかをCommitの履歴として残します。

そのため、EGitを使い始める前に、自分が作成したCommitへ記録されるユーザー情報を設定しておきましょう。

EGitが使えることを確認する

まず、現在使用しているEclipseでEGitを利用できるか確認します。

Eclipseのメニューから、

Window

↓

Show View

↓

Other...

を選択してください。

表示された画面で「Git」と検索します。

Git RepositoriesやGit Stagingなどの項目が表示されれば、EGitを利用できる状態です。

また、プロジェクトを右クリックして、

Team

というメニューを開いたときにGit関連の項目が表示されるかどうかでも確認できます。

新人研修で会社から指定されたEclipse環境を使用している場合は、すでにEGitが利用できる状態になっていることも多いでしょう。

利用できる場合は、新しくインストールする必要はありません。

まず現在の環境を確認してください。

EGitが入っていない場合はどうする？

使用しているEclipseにEGitが含まれていない場合は、追加で導入する必要があります。

ただし、会社のパソコンを使用している場合は、自分の判断でソフトウェアを追加しないようにしてください。

企業では、

・使用できるソフトウェア

・プラグインのバージョン

・接続できる外部サービス

などが決められている場合があります。

新人研修では、

「EGitが見つからないから、自分で適当にインストールする」

のではなく、まず研修担当者や開発環境の管理者に確認しましょう。

開発環境は仕事道具です。

学校のパソコンに勝手にソフトウェアをインストールしないのと同じように、会社の開発環境にもルールがあります。

なお、Eclipseの公式ドキュメントでは、EGitの各種設定をEclipseのPreferencesから行えるようになっています。ユーザー名やメールアドレスも、GitのConfiguration画面から設定できます。 (Eclipse Help)

Gitでユーザー名とメールアドレスを設定する理由

それでは、初期設定で特に重要なユーザー名とメールアドレスについて説明します。

GitではCommitを作成すると、

「誰が作成したCommitなのか」

という情報も記録されます。

たとえば、Aさんがログイン画面を修正したとしましょう。

AさんがCommitすると、そのCommitには変更内容だけでなく、作成者に関する情報も記録されます。

後から履歴を確認したときに、

「この変更は誰が行ったのか」

を確認できるわけです。

会社で書類を提出するときに、名前を書かずに提出すると困りますよね。

Gitのユーザー名とメールアドレスは、変更履歴に付ける「署名」のようなものだと考えると分かりやすいでしょう。

Gitのユーザー名はログインIDではない

ここで注意したいポイントがあります。

Gitに設定するユーザー名は、基本的にGitHubなどへログインするときのユーザーIDとは別のものです。

Gitのユーザー名は、

「このCommitを作成した人は誰なのか」

を示す情報です。

一方、GitHubやGitLabなどのサービスへ接続するときのアカウント情報は、

「そのサービスを利用する権限がある人なのか」

を確認するために使います。

役割が異なります。

たとえば会社を想像してみましょう。

書類の最後に書く「作成者名」がGitのユーザー名です。

会社へ入るときに使う「社員証」がログイン情報です。

どちらも本人に関係する情報ですが、目的は違います。

同じものだと思わないようにしてください。

EclipseからGitの設定画面を開く

それでは、実際に設定画面を開きます。

Eclipseの上部メニューから、

Window

↓

Preferences

を選択します。

Preferences画面が開いたら、

Team

↓

Git

↓

Configuration

と進みます。

Eclipse公式のEGitユーザーガイドでも、ユーザー名とメールアドレスは「Window > Preferences > Team > Git > Configuration」から設定できると案内されています。 (Eclipse Help)

Configurationは、日本語では「設定」や「構成」といった意味です。

Gitがどのような設定で動作するのかを確認・変更する画面だと考えてください。

Eclipseのバージョンや利用環境によって画面の見た目が多少異なる場合があります。

そのため、ボタンの位置を丸暗記するより、

「PreferencesのTeam > GitにGit関連の設定がある」

と覚えておく方が応用しやすいでしょう。

user.nameを設定する

最初にユーザー名を設定します。

Gitではユーザー名を、

user.name

という設定項目で管理します。

Configuration画面でユーザー設定を追加するときは、

Key

user.name

Value

自分の名前

という内容を登録します。

たとえば、名前が山田太郎さんなら、

user.name

Taro Yamada

のように設定します。

会社によっては、

・漢字で設定する

・ローマ字で設定する

・社内で指定された表記を使う

などのルールが決められている場合があります。

新人研修では、必ず会社や研修担当者から指定された形式を確認してください。

個人的に分かりやすい名前を自由に設定してよいとは限りません。

user.emailを設定する

続いて、メールアドレスを設定します。

Gitではメールアドレスを、

user.email

という項目で管理します。

たとえば、

user.email

taro.yamada@example.com

のように設定します。

Eclipse公式のEGitユーザーガイドでも、user.nameとuser.emailをGit Configurationへ登録する方法が案内されています。 (Eclipse Help)

会社でGitを利用する場合は、原則として会社から指定されたメールアドレスを設定しましょう。

個人用のメールアドレスを勝手に登録しないよう注意してください。

なぜでしょうか？

Commitの作成者情報は、Gitの履歴として残るからです。

業務上の変更履歴には、業務で利用する適切な情報を設定する必要があります。

user.nameとuser.emailはセットで覚える

新人研修では、

user.name

user.email

の2つをセットで覚えてください。

どちらもCommitの作成者情報に関係します。

イメージとしては、

user.name = 書類に書く名前

user.email = その人を識別する連絡先

です。

Commitを作ったとき、

「山田太郎さんが作った変更です」

と判断するための情報になります。

EGitでは初回Commitの際に、ユーザー情報が設定されていない場合、設定を求める画面が表示されることがあります。Eclipse公式のEGitユーザーガイドでも、最初のCommit時にユーザー情報の設定を促す仕組みが説明されています。 (Eclipse Help)

ただし、Commitする直前に慌てて設定するより、研修開始時に正しい値を登録しておく方が安心です。

Gitの設定には適用範囲がある

Gitの設定を理解するときには「どこまで設定が適用されるのか」という考え方も重要です。

Gitには設定の適用範囲があります。

代表的なのが、

・ユーザー単位の設定

・リポジトリ単位の設定

です。

ユーザー単位の設定は、自分が使用するGit全体に適用される設定です。

一方、リポジトリ単位では特定のリポジトリだけ別の設定を指定できます。

たとえば、普段は、

Taro Yamada

という名前でCommitするとします。

しかし、何らかの事情で特定のリポジトリだけ別のメールアドレスを使う必要がある場合、リポジトリ単位の設定を利用できます。

学校に例えてみましょう。

普段はすべての授業で同じ名前を書きます。

しかし、特定の授業だけ「学籍番号も必ず書いてください」というルールがあるとします。

全体で使うルールと、特定の場所だけで使うルールが存在するわけです。

新人研修の段階では、設定に「適用範囲がある」ということだけ覚えておけば十分でしょう。

Git ConfigurationのUser Settingsとは

EGitのConfiguration画面を見ると、User Settingsという言葉が出てくる場合があります。

User Settingsは、そのユーザー向けのGit設定です。

一般的なGitでは、ユーザー単位の設定はホームディレクトリにある設定ファイルへ保存されます。

EGitの公式ガイドでも、ユーザー設定を参照するためにホームディレクトリの情報を利用することが説明されています。 (Eclipse Help)

新人の段階では設定ファイルを直接編集する必要はありません。

EGitのConfiguration画面から、

user.name

user.email

が正しく設定されているか確認できれば十分です。

設定した内容を確認する

ユーザー名とメールアドレスを設定したら、必ず内容を確認してください。

確認したいのは、

user.name

user.email

の2項目です。

たとえば、

user.name = Taro Yamada

user.email = taro.yamada@example.com

のようになっていれば設定されています。

新人研修では、この確認作業を省略しないようにしましょう。

設定ミスは、プログラムのエラーのようにすぐ画面へ表示されるとは限りません。

Commit自体は作成できたものの、

「名前のスペルが間違っていた」

「個人用メールアドレスを登録していた」

と後から気づく場合があります。

Gitの履歴に残る情報なので、最初に確認する習慣をつけてください！

user.nameとuser.emailを設定したら認証も完了？

ここも間違いやすいポイントです。

user.nameとuser.emailを設定しても、GitHubや社内のGitサーバーへ接続するための認証設定が完了したわけではありません。

user.nameとuser.emailは、Commitに記録する作成者情報です。

一方、リモートリポジトリへアクセスするときには、接続先に応じた認証が必要になる場合があります。

代表的な接続方法として、

HTTPS

SSH

などがあります。

HTTPSは、Webサイトを見るときにも利用される通信方式です。

GitでもHTTPSを利用してリモートリポジトリへ接続できます。

SSHは、安全にネットワーク通信を行うための仕組みです。Gitでは公開鍵と秘密鍵を使った認証などに利用されます。

新人研修では、認証方式を自分で自由に決める場面は多くないでしょう。

会社によって、

「HTTPSを使用する」

「SSHを使用する」

「社内の認証システムを使用する」

など、ルールが決められている場合があります。

必ず指定された方法に従ってください。

HTTPSとSSHを簡単に理解しよう

HTTPSとSSHについて、少しだけイメージを持っておきましょう。

どちらも、

「リモートリポジトリへ安全に接続するための方法」

として利用できます。

たとえば会社の建物に入る方法を考えてみてください。

ある入口では、社員番号などの資格情報を使って本人確認をします。

別の入口では、事前に登録された専用の鍵を使います。

入口の方式は違いますが、

「許可された人だけを通す」

という目的は同じです。

GitのHTTPS認証とSSH認証も、細かな仕組みは異なります。

新人研修では、まず、

「リモートリポジトリへ接続するときには認証が必要な場合がある」

と理解してください。

SSHの鍵作成や詳細な認証方式まで最初から覚える必要はありません。

パスワードや秘密鍵をソースコードに書かない

認証について学んだところで、非常に重要な注意事項があります。

パスワードや秘密鍵などの認証情報を、ソースコードへ直接書かないでください。

たとえば、

・パスワード

・アクセストークン

・秘密鍵

・クラウドサービスの認証情報

などは、外部へ漏れてはいけない情報です。

GitでCommitすると、情報が変更履歴として残る可能性があります。

後からファイル上の文字を削除しただけでは、過去の履歴に残っている場合もあります。

「あとで消せば大丈夫」

とは考えないでください。

家の合鍵を写真に撮って社内掲示板へ貼り、

「あとで写真を外したから問題ない」

とは言えませんよね。

誰かが写真を見ていた可能性があります。

認証情報も同じです。

Gitへ登録してはいけない情報があることを、最初の段階から意識しましょう。

もし誤って認証情報をCommitやPushしてしまった場合は、自分だけで何とかしようとせず、すぐに研修担当者やプロジェクト責任者へ報告してください。

デフォルトのリポジトリ保存場所も確認しておこう

EGitでは、Gitリポジトリを保存するデフォルトの場所を設定できます。

Preferencesの、

Team

↓

Git

付近で確認できます。

新人研修では、会社や研修用PCで保存先が指定されているなら、その設定を利用してください。

保存場所を自由に変更すると、

「自分のリポジトリがどこにあるのか分からない」

という状況になりやすいためです。

たとえば、学校のプリントを毎回違う引き出しへ入れていたら、必要なときに探すのが大変ですよね。

Gitリポジトリも、決められた場所へ整理しておいた方が管理しやすくなります。

ただし、Gitリポジトリの保存先については会社や開発環境ごとにルールが異なるため、研修担当者から指定がある場合はそちらを優先してください。

EclipseのワークスペースとGitリポジトリは同じもの？

Eclipseを使っていると「ワークスペース」という言葉も登場します。

ワークスペースとは、Eclipseがプロジェクトや各種設定などを管理するために使用する作業領域です。

一方、GitリポジトリはGitが変更履歴を管理するための場所です。

目的が異なります。

新人のうちは、

Eclipseのワークスペース = Eclipse側の作業場所

Gitリポジトリ = Git側の管理場所

と理解しておきましょう。

両者を完全に同じものとして考えないことがポイントです。

後の章でリポジトリをCloneしたり、EclipseへプロジェクトをImportしたりすると、この違いが重要になってきます。

初期設定で新人がやってはいけないこと

初期設定では、必要以上に設定を変更しないことも大切です。

特に会社の開発環境では、

「意味は分からないけど、インターネットに書いてあったから変更した」

という操作は避けてください。

たとえば、

・認証方式を勝手に変更する

・ネットワーク関連の設定を変更する

・Gitの設定ファイルを直接書き換える

・SSHの設定を自己判断で変更する

・会社指定ではないメールアドレスを登録する

といった操作には注意が必要です。

新人研修では、設定項目を全部理解する必要はありません。

まずは、

「自分が変更しようとしている設定には、どんな役割があるのか」

を確認する習慣をつけましょう。

分からない設定は、変更しない。

業務用の開発環境では非常に大切な考え方です。

新人研修で最低限確認する設定

この章では多くの説明をしましたが、実際に新人研修で確認したい内容はそれほど多くありません。

最低限、次の内容を確認してください。

EclipseでEGitを利用できる
Git Configuration画面を開ける
user.nameが正しい
user.emailが正しい
会社から指定された認証方法を確認している
Gitリポジトリの保存場所について会社のルールを確認している

特にuser.nameとuser.emailは、自分で確認できるようにしておきましょう。

第3章のまとめ

EGitを使い始める前には、Gitの初期設定を確認する必要があります。

特に重要なのが、

user.name

user.email

です。

user.nameはCommitを作成した人の名前を示します。

user.emailはCommitを作成した人に紐づくメールアドレスです。

どちらもログインするためのIDやパスワードではありません。

Gitの変更履歴へ記録される作成者情報です。

また、リモートリポジトリへアクセスするときには、HTTPSやSSHなど、会社から指定された方法で認証する場合があります。

認証方法を自己判断で変更したり、パスワードや秘密鍵をソースコードへ記載したりしないでください。

新人研修では、すべての設定項目を覚える必要はありません。

まず、

Window

↓

Preferences

↓

Team

↓

Git

↓

Configuration

からGitの設定を確認できるようになりましょう。Eclipse公式のEGitユーザーガイドでも、この経路からuser.nameとuser.emailを設定する方法が案内されています。 (Eclipse Help)

次の章では、Git RepositoriesビューやGit Stagingビューなど、実際の作業で使用するEGitの主要な画面について解説します。

「どの画面で何をするのか」を覚えて、実際のGit操作へ進む準備を整えていきましょう！

第4章 EGitの画面の見方｜Git Repositories・Git Staging・Historyを理解しよう

第3章では、EGitを使い始めるための初期設定について説明しました。

user.nameやuser.emailを設定したら、次はEGitで普段使う画面を確認していきます。

Eclipseには多くのビューがあるため、初めてEGitを使うと、

「どの画面を見ればいいの？」

「Git Stagingって何をする場所？」

「Git RepositoriesとPackage Explorerは何が違うの？」

と迷いやすいものです。

新人研修では、すべての画面を覚える必要はありません。

まずは、次の3つを覚えてください。

・Git Repositoriesビュー

・Git Stagingビュー

・Historyビュー

加えて、普段から使っているPackage Explorerとの関係も理解しておくと、EGitの操作がかなり分かりやすくなります。

EGitでは「ビュー」を使って操作する

Eclipseでは、画面内に表示される小さな作業領域を「ビュー」と呼びます。

たとえば、

Package Explorer

Console

Problems

などもビューです。

EGitにもGit専用のビューがあります。

ビューごとに役割が分かれていて、

Git Repositoriesビュー

リポジトリを確認する

Git Stagingビュー

変更されたファイルを確認してCommitする

Historyビュー

過去のCommitを確認する

という使い分けをします。

机に例えるなら、それぞれ専用の引き出しがあるようなものです。

文房具を見る引き出し。

書類を整理する引き出し。

過去の資料を見る引き出し。

目的に応じて開く場所が違います。

EGitも同じように、「何をしたいのか」によって使用するビューが変わります。

Git Repositoriesビューとは

最初に覚えたいのが、Git Repositoriesビューです。

Git Repositoriesビューでは、Eclipseが認識しているGitリポジトリを確認できます。

たとえば、

・どのリポジトリを利用しているのか

・どのブランチを利用しているのか

・リモートリポジトリが登録されているか

・どのようなブランチが存在するか

といった情報を確認できます。

名前にあるRepositoriesは、Repositoryの複数形です。

つまり、

「Gitリポジトリを見るための画面」

と考えてください。

Git Repositoriesビューを表示する

Git Repositoriesビューが表示されていない場合は、Eclipseのメニューから開けます。

Window

↓

Show View

↓

Other...

を選択します。

表示された一覧から、

Git

↓

Git Repositories

を選択してください。

Git RepositoriesビューがEclipse内に表示されます。

一度表示しておけば、普段の作業でも利用できます。

会社や研修用のEclipseでは、最初から表示されるようにレイアウトが設定されている場合もあります。

Git Repositoriesビューでは何を見るの？

Git Repositoriesビューを開くと、登録されているリポジトリが一覧表示されます。

リポジトリを展開すると、さまざまな項目が表示されます。

代表的なものとして、

Branches

Remotes

Working Tree

Branchesとは

Branchesでは、そのGitリポジトリに存在するブランチを確認できます。

ブランチについては第2章でも簡単に説明しました。

Gitでは、開発の流れを枝分かれさせて作業できます。

Branchesを見ると、

Local

Remote Tracking

などに分かれて表示される場合があります。

Localは、自分のパソコン上に存在するブランチです。

Remote Trackingは、リモート側のブランチを追跡するための情報です。

新人研修では、細かな仕組みまで理解しなくても問題ありません。

まずは、

「Branchesを見ると、現在どのようなブランチがあるのか確認できる」

と覚えておきましょう。

また、現在作業しているブランチがどれなのかを意識する習慣も重要です。

同じリポジトリでも、ブランチが違えばソースコードの状態が異なる場合があります。

「修正したはずなのに内容がない！」

というときに、実は別のブランチを見ていた、ということもあります。

作業開始時には、自分がどのブランチにいるのか確認してください。

Remotesとは

Remotesでは、接続先として登録されているリモートリポジトリの情報を確認できます。

よく見かける名前が、

origin

です。

originは、多くの場合、Clone元となったリモートリポジトリにつけられる名前です。

たとえば、

https://example.com/sample-project.git

というリポジトリをCloneしたとします。

Gitでは、その接続先を毎回長いURLで指定するのではなく、

origin

という短い名前で扱えるようにします。

たとえるなら、スマートフォンの連絡先です。

毎回、

090-XXXX-XXXX

という電話番号を覚えて入力する代わりに、

「山田さん」

という名前で登録しておけば簡単に電話できますよね。

originも似た役割を持っています。

新人研修では、

origin = 主にClone元のリモートリポジトリを表す名前

くらいに覚えておけば十分です。

Package Explorerとの違い

Git RepositoriesビューとPackage Explorerは、どちらもプロジェクトに関係する情報を表示します。

そのため、最初は違いが分かりにくいかもしれません。

Package Explorerは、

Javaプロジェクトのファイルやパッケージを見るための画面

です。

一方、Git Repositoriesビューは、

Gitリポジトリそのものを見るための画面

です。

たとえばJava開発中に、

src

com.example

Main.java

などを確認するのはPackage Explorerです。

一方、

現在のブランチ

リモートリポジトリ

Gitの管理状態

などを確認するのはGit Repositoriesビューです。

学校に例えるなら、

Package Explorer = 教科書の中身を見る

Git Repositories = 教科書がどの版なのか、どこから届いたのかを見る

ような違いです。

普段ソースコードを書くときはPackage Explorer。

Gitの管理状態を確認するときはGit Repositories。

このように使い分けてください。

Git Stagingビューとは

新人研修で最も重要なEGitの画面がGit Stagingビューです。

Git Stagingビューでは、

・変更されたファイルの確認

・ステージング

・コミットメッセージの入力

・Commit

などを行います。

つまり、

「変更したソースコードをGitの履歴として記録するための作業場所」

です。

第2章で説明した、

編集

↓

Stage

↓

Commit

という流れのうち、StageとCommitを行う中心的な画面になります。

このビューは頻繁に使うので、しっかり慣れてください！

Git Stagingビューを表示する

Git Stagingビューも、Git Repositoriesビューと同じように表示できます。

Window

↓

Show View

↓

Other...

を開きます。

そこから、

Git

↓

Git Staging

を選択してください。

Git Stagingビューが表示されます。

画面内には主に、

Unstaged Changes

Staged Changes

Commit Message

といった領域があります。

この3つは特に重要です。

Unstaged Changesとは

Unstaged Changesには、

変更されているものの、まだ次のCommitへ含めると決めていないファイル

が表示されます。

たとえば、Main.javaを修正して保存したとします。

Gitが変更を検出すると、Main.javaがUnstaged Changesに表示されます。

この状態では、

「Main.javaが変更された」

ことはGitが把握しています。

ただし、

「次のCommitへMain.javaの変更を含める」

とはまだ決めていません。

旅行の荷造りで考えてみましょう。

机の上に、

財布

充電器

教科書

ゲーム機

が置いてあります。

旅行へ持っていく可能性はありますが、まだスーツケースへ入れていません。

Unstaged Changesは、この机の上に置かれた荷物のような状態です。

Staged Changesとは

Staged Changesには、次のCommitへ含める変更が表示されます。

Unstaged ChangesにあるファイルをStageすると、

Unstaged Changes

↓

Staged Changes

へ移動します。

旅行の例で考えるなら、

「この荷物は旅行へ持っていく」

と決めてスーツケースへ入れた状態です。

Gitでは、このステージングという仕組みがあるため、

変更したすべてのファイルをCommitする

のではなく、

今回必要な変更だけを選んでCommitする

ことができます。

たとえば、

User.java

README.md

を変更したとしても、

User.java

だけをStaged Changesへ移動させれば、README.mdをCommitから外せます。

仕事では非常に重要な機能です。

なぜ変更したファイルを全部Commitしないの？

「変更したなら全部Commitすれば簡単なのでは？」

と思うかもしれません。

しかし、関係のない変更を1つのCommitへまとめると、後から履歴を確認しづらくなります。

たとえば、

ログイン機能の修正

READMEの誤字修正

デバッグ用のログ追加

という3種類の変更を同時に行ったとします。

全部を1つにまとめて、

いろいろ修正

というCommitを作ったらどうでしょう。

後から見た人は、

「何を目的としたCommitなの？」

と困ってしまいます。

Gitでは、できるだけ意味のある単位でCommitを作ることが重要です。

そのためにStagingを使います。

新人のうちから、

「変更されたファイルを全部そのままCommitする」

のではなく、

「今回のCommitに必要な変更なのか」

を確認する習慣をつけましょう。

Commit Messageとは

Git Stagingビューには、Commit Messageを入力する欄があります。

Commit Messageとは、そのCommitで何を変更したのかを説明する文章です。

たとえば、

修正

だけでは内容が分かりません。

一方、

ログイン画面に未入力チェックを追加

であれば、何をしたCommitなのか想像できます。

Commit Messageは、

「未来の自分やほかの開発者に残すメモ」

と考えてください。

3か月後に過去のCommitを見る可能性もあります。

そのとき、

修正

変更

対応

などしか書かれていなければ、自分自身でも内容を思い出せないでしょう。

研修の段階から、変更内容が分かるCommit Messageを書く習慣をつけてください。

Commitボタンとは

Staged Changesへ必要な変更を移動し、Commit Messageを入力したらCommitできます。

Commitすると、変更内容がローカルリポジトリへ記録されます。

第2章でも説明したとおり、

Commit = リモートリポジトリへ送信

ではありません。

Commitした段階では、基本的に自分のローカルリポジトリへ記録されています。

ほかの人へ共有するときには、さらにPushが必要です。

この違いは何度でも確認してください。

新人が特につまずきやすいポイントです。

Commit and Pushは使ってもいい？

EGitの画面では、Commitだけでなく、

Commit and Push

という操作を利用できる場合があります。

名前のとおり、

Commit

↓

Push

を続けて実行する操作です。

便利ですが、新人研修では最初から多用しない方が理解しやすいでしょう。

まずは、

Stage

↓

Commit

↓

Commitされたことを確認

↓

Push

と、操作を分けて覚えてください。

なぜでしょうか？

操作を分けると、

「今はローカルリポジトリへ記録した」

「次にリモートリポジトリへ送った」

という違いを理解しやすくなるからです。

自転車に乗る練習をするときに、いきなり高速で走るより、

ペダルを踏む

ブレーキを使う

曲がる

という操作を一つずつ覚える方が安全ですよね。

Gitも同じです。

仕組みを理解してから便利な操作を使いましょう。

変更内容の差分を確認する

Gitを使うときに非常に重要なのが「差分」です。

差分とは、

変更前と変更後で、どこが変わったのか

を表したものです。

英語ではDiffと呼ばれます。

たとえば、Main.javaの1行を変更したとします。

修正前

System.out.println("Hello");

修正後

System.out.println("Hello World");

差分を見ると、

Hello

から

Hello World

へ変更されたことを確認できます。

EGitでは、変更されたファイルを比較して差分を確認できます。

Commitする前には、できるだけ差分を見る習慣をつけてください。

なぜCommit前に差分を見るの？

「自分で修正したのだから、内容は分かっている」

と思うかもしれません。

しかし、実際の開発では意図しない変更が混ざることがあります。

たとえば、

・デバッグ用に書いたコードを消し忘れた

・関係のないファイルまで変更していた

・必要な処理を誤って削除した

・一時的に書いたコメントを残していた

といったケースです。

Commit前の差分確認は、提出前の答案チェックと同じです。

テストを解き終えたからといって、そのまま提出するより、

名前を書いたか

回答欄を間違えていないか

計算ミスがないか

を確認した方が安心ですよね。

Gitでも、

「Commitする前に差分を確認する」

という習慣をつけてください！

Historyビューとは

次に覚えたいのがHistoryビューです。

Historyビューでは、GitのCommit履歴を確認できます。

過去に、

・誰がCommitしたのか

・いつCommitしたのか

・どのようなCommit Messageだったのか

・どのファイルが変更されたのか

などを確認できます。

Gitの大きなメリットの1つが、この変更履歴を残せることです。

Historyビューは、その履歴を見るための画面だと考えてください。

Historyビューを表示する

Historyビューは、Git管理されているプロジェクトやファイルから表示できます。

たとえばPackage Explorerで対象を右クリックし、

Team

↓

Show in History

などを選択すると、Historyビューを表示できます。

Eclipseのバージョンや表示状態によってメニュー名や位置が多少異なる場合があります。

重要なのは、

「過去のCommitを確認したいときはHistoryを見る」

という考え方です。

HistoryではCommit Messageを読む

Historyビューを開くと、過去のCommitが並んでいます。

最初に確認したいのがCommit Messageです。

たとえば、

ログイン画面の入力チェックを追加

商品検索の不具合を修正

ユーザー登録時のメール形式チェックを追加

という履歴が並んでいれば、どのような変更が行われてきたのか把握できます。

Commit MessageがGitの履歴を理解するために重要だということも分かりますよね。

自分が書くCommit Messageも、後からHistoryに表示されます。

「後からHistoryで読む人が理解できるか？」

を考えて書いてください。

誰が変更したのかも確認できる

Historyでは、Commitした人の情報も確認できます。

第3章で設定した、

user.name

user.email

などの情報が、Commitの作成者情報として利用されます。

そのため、

「この処理を変更した理由を確認したい」

というときに、誰がCommitしたのかを調べる手がかりになります。

ただし、

「誰が書いたから悪い」

と責任を追及するための機能ではありません。

変更の背景を確認したり、仕様を知っている人を探したりするために活用します。

Gitの履歴は、チーム開発の記録です。

ファイルの横に表示されるマークにも注目する

EGitを使っていると、Package Explorer内のファイルに小さなマークや文字が付くことがあります。

これらは「Team Decorator」などと呼ばれる表示で、Gitの状態を確認するために使われます。

たとえば、

変更されているファイル

Gitで管理されていないファイル

現在のブランチに関する情報

などが表示される場合があります。

Eclipseのバージョンや設定によって見た目は異なります。

新人研修ではマークを全部暗記する必要はありません。

大切なのは、

「ファイルの横に普段と違う表示が出たら、Gitの状態が変化している可能性がある」

と気づけることです。

ファイルを修正したらGit Stagingを見る習慣をつける

新人のうちは、ソースコードを修正した後にGit Stagingビューを見る習慣をつけるとよいでしょう。

たとえば、

Main.javaを変更

↓

保存

↓

Git Stagingビューを見る

↓

Main.javaがUnstaged Changesに表示される

↓

差分を確認

という流れです。

Git Stagingビューを見ると、

「Gitがどの変更を検出しているのか」

を確認できます。

自分では1ファイルしか変更していないつもりなのに、5ファイル表示されていたらどうでしょう。

意図しない変更が発生している可能性があります。

そのまま全部Stageしてはいけません。

何が変わったのか確認してください。

Teamメニューも覚えておこう

EGitでは専用ビューだけでなく、プロジェクトやファイルを右クリックして表示されるTeamメニューもよく使います。

Package Explorerでプロジェクトを右クリックして、

Team

を選択すると、Git関連の操作が表示されます。

たとえば、

Commit

Pull

Push

Switch

Show in History

などの操作へアクセスできます。

実際にどの項目が表示されるかは、Gitの状態やEclipseのバージョンなどによって異なります。

新人研修では、

「Git操作を探したいときは、右クリックしてTeamを見る」

と覚えておくと便利です。

どの画面を使えばいいか迷ったとき

ここまで複数のビューが登場しました。

最初は使い分けが難しいかもしれません。

迷ったら、目的から考えてください。

ソースコードを書きたい

↓

Package Explorer

リポジトリやブランチを見たい

↓

Git Repositories

変更されたファイルを確認したい

↓

Git Staging

StageやCommitをしたい

↓

Git Staging

過去のCommitを見たい

↓

History

この対応関係を覚えておけば、基本操作では困りにくくなります。

特に新人研修では、

Package Explorer

Git Staging

の2つを頻繁に行き来することになるでしょう。

新人研修ではGit Stagingを最優先で覚える

ここまで、

Git Repositories

Git Staging

History

を紹介しました。

すべて重要ですが、新人研修で1つだけ優先するならGit Stagingビューです。

なぜなら、日常業務で頻繁に行う、

変更確認

↓

Stage

↓

Commit

という操作をGit Stagingビューで行えるからです。

Git操作に慣れていないうちは、Commitを実行する前に必ずGit Stagingビューを確認してください。

「何が変更されているのか」

「何をStageしたのか」

「Commit Messageは正しいか」

という3点をチェックします。

ボタンを押すことより、状態を確認することの方が重要です。

Commit前の確認手順

新人研修では、Commitする前に次の流れを習慣化しておくと安全です。

Git Stagingビューを開く
Unstaged Changesを確認する
変更したファイルの差分を見る
必要なファイルだけStageする
Staged Changesを確認する
Commit Messageを書く
もう一度内容を確認する
Commitする

特に、

「とりあえず全部StageしてCommit」

という操作は避けましょう。

一つずつ確認してください。

Gitは変更履歴を残すための道具です。

履歴をきれいに残すには、Commitする人自身が内容を確認する必要があります。

第4章のまとめ

EGitでは、目的に応じて複数のビューを使い分けます。

新人研修で最低限覚えておきたいのは、

Git Repositories

Git Staging

History

の3つです。

Git Repositoriesビューでは、リポジトリやブランチ、リモートに関する情報を確認します。

Git Stagingビューでは、変更されたファイルを確認し、StageしてCommitします。

Historyビューでは、過去のCommit履歴を確認できます。

また、普段のJava開発ではPackage Explorerを使います。

ソースコードを見る場所とGitの状態を見る場所は、役割が異なると覚えておきましょう。

特に重要なのはGit Stagingビューです。

ファイルを変更したら、

Unstaged Changes

↓

差分確認

↓

Staged Changes

↓

Commit Message

↓

Commit

という流れを意識してください。

ここまでで、EGitを操作するための基礎知識と画面の見方が分かりました。

次の章では、実際のEclipseプロジェクトをGitの管理対象にしてみます。

「普通のプロジェクトが、どのようにGit管理されるのか」を実際の操作を通して理解していきましょう！

第5章 EclipseプロジェクトをGitで管理する方法｜EGitでリポジトリを作成しよう

第4章では、Git Repositoriesビュー、Git Stagingビュー、Historyビューなど、EGitでよく使う画面を説明しました。

ここからは、実際のプロジェクトをGitで管理してみましょう。

今回扱うのは、

「すでにEclipse上にあるプロジェクトを、あとからGitで管理する」

という操作です。

たとえば、新しくJavaプロジェクトを作成して開発を始めたあと、

「このプロジェクトもGitで履歴を残したい」

という場合に使います。

この操作を覚えると、普通のEclipseプロジェクトがどのようにGit管理されるのかを理解できます。

新人研修では、Gitの仕組みを理解するための練習として非常におすすめです。

まずはGit管理するプロジェクトを用意する

最初に、練習用のJavaプロジェクトを用意しましょう。

すでに研修用のプロジェクトがある場合は、そちらを使用しても構いません。

新しく作る場合は、たとえば、

SampleProject

というJavaプロジェクトを作成します。

中には、

src

というソースフォルダーがあり、その中にJavaファイルがある状態を想定します。

たとえば、

Main.java

というファイルを作り、簡単なプログラムを書いておきます。

ここで重要なのは、現時点ではまだGit管理されていない普通のEclipseプロジェクトだという点です。

Git管理を開始すると、このプロジェクトに対して変更履歴を残せるようになります。

プロジェクトをGit管理するとはどういうこと？

「Git管理する」という言葉は少し抽象的ですよね。

簡単に言うと、

「このプロジェクトのファイル変更をGitで追跡できる状態にする」

という意味です。

たとえば、Main.javaを書き換えたとします。

Git管理されていない場合、変更前と変更後の違いをGitは記録できません。

一方、Git管理されている場合は、

・どのファイルを変更したのか

・どの行が変わったのか

・いつCommitしたのか

・誰がCommitしたのか

といった履歴を残せます。

学校のノートに例えるなら、普通のノートは最新の内容だけを書き換えていくものです。

Git管理を始めると、

「前のページには何を書いていたのか」

「どこを修正したのか」

まで記録できるノートに変わるイメージです。

TeamメニューからGit管理を開始する

それでは、実際に操作していきます。

Package Explorerで、Git管理したいプロジェクトを右クリックしてください。

表示されたメニューから、

Team

↓

Share Project...

を選択します。

Share Projectは、

「このプロジェクトをバージョン管理システムと関連付ける」

ための機能です。

表示された画面でGitを選択します。

環境によっては、最初からGitが選択されている場合もあります。

そのまま次へ進みましょう。

Share Projectとは

Shareという言葉を見ると、

「誰かに共有するの？」

と思うかもしれません。

しかし、ここでいうShare Projectは、すぐにインターネット上へ公開する操作ではありません。

プロジェクトをGitの管理対象として登録するための操作です。

この段階では、まだGitHubなどへPushしているわけではありません。

あくまで、

「このEclipseプロジェクトをGitで管理する」

という設定を行っています。

名前だけを見て、

「Shareだから外部へ公開される」

と勘違いしないようにしてください。

Gitリポジトリを作成する

次に、Gitリポジトリを用意します。

新規プロジェクトの場合は、新しいGitリポジトリを作成することになります。

画面上では、

Create Repository

などのボタンが表示される場合があります。

選択すると、Gitリポジトリが作成されます。

Gitリポジトリが作成されると、Gitが変更履歴を管理するための情報が保存されるようになります。

内部的には、Git専用の管理情報が作成されます。

通常は、

.git

という名前のディレクトリにGitの管理情報が保存されます。

.gitとは

.gitは、そのリポジトリのGit管理情報を保存するための重要な場所です。

中には、

・Commitの履歴

・ブランチの情報

・設定情報

・Gitが管理するさまざまなデータ

などが保存されています。

普通のソースコードとは違い、Gitそのものが利用する管理情報です。

新人研修では、.gitの中身を直接編集する必要はありません。

むしろ、むやみに変更しないでください。

たとえば、図書館の本を管理する台帳を想像してください。

本そのものがJavaファイルだとすると、.gitは、

「どの本がいつ入ってきたか」

「どの版が存在するか」

「過去にどんな変更があったか」

を記録する管理台帳のようなものです。

台帳を勝手に書き換えると、管理が壊れてしまいます。

.gitも同じように、Git自身に管理させるものだと考えてください。

リポジトリをどこに作るの？

Git管理を始めるときには、

「Gitリポジトリをどこに作るのか」

という点も重要です。

新人研修では、基本的に1つのプロジェクトに対して分かりやすい構成を使えば十分です。

たとえば、

SampleProject

というプロジェクトがあり、そのプロジェクト自体を1つのGitリポジトリとして管理します。

実務では、

・複数プロジェクトを1つのリポジトリで管理する

・1プロジェクトごとに1リポジトリを作る

など、開発チームによって構成が異なります。

研修では、

「プロジェクトとリポジトリの関係は必ず1対1とは限らない」

ということだけ覚えておけばよいでしょう。

会社のプロジェクトでは、既存の構成に従ってください。

Git管理が始まったか確認する

Share Projectの設定が完了したら、Package Explorerを確認します。

プロジェクト名やファイル名に、Git関連の装飾が表示される場合があります。

また、Git Repositoriesビューを開くと、新しく作成したリポジトリが表示されます。

Git Repositoriesビューにリポジトリが追加されていれば、EGitがリポジトリを認識していることを確認できます。

さらに、Git Stagingビューも見てみましょう。

まだ一度もCommitしていない場合、多くのファイルがUnstaged Changesとして表示される可能性があります。

ここで、

「どうしてファイルを変更していないのにUnstaged Changesに出るの？」

と思うかもしれません。

Gitから見ると、まだ一度も登録されていないファイルだからです。

Untrackedファイルとは

Gitでは、まだGitの管理対象として登録されていないファイルを「Untrackedファイル」と呼びます。

Untrackedは、

「追跡されていない」

という意味です。

たとえば、Gitリポジトリを作成した直後に、

Main.java

README.md

などのファイルが存在していても、まだ最初のCommitをしていない場合があります。

Gitから見ると、

「ファイルが存在することは分かっているが、履歴としてはまだ登録されていない」

状態です。

たとえば、学校に新しい生徒が転校してきたものの、まだ名簿に登録されていないような状態を想像してください。

生徒は教室にいます。

しかし、正式な名簿にはまだ載っていません。

Gitでも同じように、ファイルが存在していても、まだ追跡対象になっていない状態があります。

すべてのファイルをGitで管理すればいいの？

ここで重要なポイントがあります。

プロジェクト内のすべてのファイルをGitで管理すればよいとは限りません。

たとえば、Javaプロジェクトには、

・ソースコード

・設定ファイル

・自動生成されたファイル

・ビルド結果

・一時ファイル

などが含まれる場合があります。

自動生成されるファイルまでGitへ登録すると、履歴が不要に増えたり、ほかの開発者と競合しやすくなったりします。

そこで使うのが、

.gitignore

です。

.gitignoreとは

.gitignoreは、

「Gitで管理しないファイルやフォルダーを指定するためのファイル」

です。

名前にあるignoreは、

「無視する」

という意味です。

Gitに、

「このファイルは管理しなくていいよ」

と伝えるために使います。

たとえば、Javaプロジェクトでコンパイルした結果が、

bin

というフォルダーに出力されるとします。

bin内のファイルは、ソースコードから自動生成できます。

そのため、開発ルールによってはGitで管理しない場合があります。

その場合、.gitignoreに除外ルールを書きます。

たとえば、

/bin/

と指定すると、binフォルダーをGitの管理対象から除外できます。

なぜ自動生成ファイルをGit管理しないの？

「ファイルがあるなら全部保存した方が安心なのでは？」

と思うかもしれません。

しかし、自動生成できるファイルまで管理すると、かえって邪魔になる場合があります。

たとえば、料理のレシピをGitで管理するとしましょう。

Gitで残したいのは、

・材料

・作り方

です。

完成した料理そのものまで毎回保存する必要はありません。

レシピがあれば、また料理を作れますよね。

Javaでも似ています。

ソースコードがあれば、コンパイルして.classファイルなどを作り直せます。

そのため、再生成できるものはGit管理しない方がよい場合があります。

.gitignoreは会社のルールを優先する

.gitignoreに何を書くかは、プロジェクトによって異なります。

たとえば、

・使用するIDE

・ビルドツール

・プログラミング言語

・会社の開発ルール

によって除外対象が変わります。

新人研修で最も重要なのは、

「インターネットで見つけた.gitignoreをそのまま使わない」

ことです。

会社のプロジェクトには、すでに決められた.gitignoreが存在する場合があります。

その場合は既存ルールを優先してください。

勝手に除外設定を追加すると、本来Git管理すべきファイルまで除外してしまう可能性があります。

Eclipse固有のファイルはどうする？

Eclipseでは、プロジェクトによって、

.project

.classpath

.settings

などのファイルが作成される場合があります。

これらをGitで管理するかどうかは、プロジェクトの方針によって異なります。

「Eclipseのファイルだから全部無視する」

とは限りません。

チーム全員で同じEclipse設定を共有するために管理する場合もあります。

反対に、個人環境に依存する設定は管理しない場合もあります。

新人研修では、

「自分の判断で消したり.gitignoreへ追加したりしない」

ことを覚えてください。

既存プロジェクトでは、必ずチームのルールに従いましょう。

最初のCommitを作る

Git管理を開始し、不要なファイルを除外したら、最初のCommitを作ります。

最初のCommitは、

Initial Commit

と呼ばれることがあります。

Initialは、

「最初の」

という意味です。

つまり、

「このリポジトリの最初のCommit」

です。

Git Stagingビューを開いてください。

まず、

Unstaged Changes

を確認します。

ここには、まだCommitされていないファイルが表示されます。

Commitするファイルを確認する

最初のCommitだからといって、何も確認せずに全部Stageしてはいけません。

まずファイル一覧を確認してください。

たとえば、

Main.java

.gitignore

.project

.classpath

などが表示されているとします。

それぞれ、

「このファイルはGitで管理する必要があるか？」

を確認します。

研修用プロジェクトであれば、研修担当者から指定されたファイルを管理してください。

実務では、既存の開発ルールに従います。

新人のうちは、

「全部選んでおけば安全」

ではなく、

「何を登録するのか確認する」

習慣をつけることが重要です。

ファイルをStageする

Gitで管理するファイルを決めたらStageします。

Git Stagingビューで、対象ファイルを、

Unstaged Changes

から

Staged Changes

へ移動します。

ここで第2章と第4章で学んだステージングが実際に登場します。

ステージングとは、

「次のCommitに含める変更を選ぶ操作」

でしたね。

今回の場合は、

「最初のCommitへ含めるファイルを選ぶ」

という意味になります。

必要なファイルがStaged Changesへ移動したことを確認してください。

Commit Messageを書く

次にCommit Messageを入力します。

最初のCommitであれば、

Initial commit

などのメッセージが使われることがあります。

ただし、会社やチームでCommit Messageの書き方が決められている場合は、そのルールに従ってください。

Commit Messageは、

「このCommitで何をしたのか」

を後から確認するための文章です。

最初のCommitなら、

「プロジェクトの初期状態を登録した」

ということが分かる内容であればよいでしょう。

Commitを実行する

StageするファイルとCommit Messageを確認したら、Commitを実行します。

これで最初のCommitが作成されます。

重要なので、もう一度確認します。

この時点では、

「自分のパソコンにあるローカルリポジトリへCommitした」

状態です。

まだGitHubや社内Gitサーバーなどのリモートリポジトリへ送ってはいません。

CommitとPushは別の操作です。

新人研修では、この違いを何度も意識してください。

Historyビューで最初のCommitを確認する

Commitが完了したら、Historyビューを開いてみましょう。

対象プロジェクトを右クリックして、

Team

↓

Show in History

などから履歴を確認できます。

Historyビューに、今作成したCommitが表示されているはずです。

Commit Message

作成者

日時

などを確認してください。

ここで、

「Git管理する」

↓

「Stageする」

↓

「Commitする」

↓

「Historyに履歴が残る」

という一連の流れを実感できます。

単にボタンを押して終わるのではなく、履歴に記録されたことまで確認しましょう。

ファイルを修正してGitの動きを確認する

最初のCommitができたら、実際にファイルを少し修正してみましょう。

たとえば、Main.javaの出力内容を変更します。

修正前

System.out.println("Hello");

修正後

System.out.println("Hello EGit");

ファイルを保存してください。

次にGit Stagingビューを確認します。

Main.javaがUnstaged Changesに表示されるはずです。

ここが重要です。

Gitは、

「Main.javaが前回のCommitから変更された」

ことを検出しています。

最初のCommitが基準点になり、その状態と現在のファイルを比較できるようになったからです。

差分を確認する

Main.javaを選択して、変更差分を確認してみましょう。

変更前

Hello

変更後

Hello EGit

という違いを確認できます。

Git管理の大きなメリットは、

「ファイルが変更された」

だけではなく、

「具体的にどこが変更されたのか」

を確認できることです。

実務では、Commit前に必ず差分を確認する習慣をつけてください。

自分で修正したつもりでも、意図していない行まで変わっている可能性があります。

元に戻したいときはどうする？

ファイルを変更したものの、

「やっぱりこの変更は不要だった」

という場合もあります。

Git管理されていれば、前回Commitした状態を基準に変更内容を確認できます。

EGitには変更を戻すための操作もあります。

ただし、新人研修では取り消し操作を自己判断で使う前に、

「何をどの状態まで戻そうとしているのか」

を確認してください。

Gitの取り消し操作には複数の種類があり、対象によって意味が異なります。

特に共有済みのCommitやPush済みの履歴を変更する場合は注意が必要です。

今回の段階では、

「Git管理しておけば、変更前との差分を確認できる」

という点を理解できれば十分です。

Git管理しているか分からなくなったら

作業中に、

「このプロジェクト、Git管理されているのかな？」

と思った場合は、いくつか確認方法があります。

まず、Package Explorerでプロジェクトを右クリックしてTeamメニューを確認します。

Git関連の操作が表示されているか確認してください。

次に、Git Repositoriesビューを確認します。

対象のリポジトリが表示されているか確認できます。

さらに、ファイルを変更してGit Stagingビューに表示されるかどうかでも確認できます。

1つの画面だけで判断するのではなく、

Package Explorer

Git Repositories

Git Staging

を使い分けて状態を確認しましょう。

Share ProjectとCloneは何が違う？

ここまで読んで、

「前の章でCloneという言葉も出てきたけど、Share Projectとは何が違うの？」

と思った人もいるでしょう。

違いは、作業を始める場所です。

Share Projectは、

すでに自分のEclipseに存在するプロジェクトをGit管理したいとき

に使います。

一方、Cloneは、

すでにリモートリポジトリに存在するプロジェクトを自分のパソコンへ取得したいとき

に使います。

たとえば、

自分で新しい課題用プロジェクトを作った

↓

Share Project

会社ですでに開発されているプロジェクトへ参加する

↓

Clone

というイメージです。

実務では、後者のCloneから作業を始めるケースが多くあります。

次の章では、そのCloneを実際に操作します。

新人研修ではShare Projectを覚える必要がある？

実務では、すでにGit管理されているリポジトリをCloneして作業する場合が多いため、新人がShare Projectを頻繁に使うとは限りません。

それでも研修で一度体験しておく価値があります。

なぜなら、

「普通のファイルが、どのタイミングでGit管理されるのか」

を理解できるからです。

Cloneだけを経験すると、最初からGit管理された状態のプロジェクトが手元に来るため、

「Gitリポジトリがどう作られたのか」

が分かりにくい場合があります。

Share Projectを一度操作しておくと、

プロジェクト

↓

Gitリポジトリを作成

↓

ファイルをStage

↓

最初のCommit

という基本構造を理解できます。

この経験が、後からGitのトラブルを考えるときにも役立ちます。

新人がやってはいけないこと

Git管理を開始するときには、いくつか注意点があります。

特に、実際の会社プロジェクトでは勝手に新しいリポジトリを作らないでください。

すでにGit管理されているプロジェクトに対して、別のリポジトリを作成してしまうと、管理構成が分かりにくくなる可能性があります。

また、

・.gitを削除する

・.gitの中身を直接変更する

・既存の.gitignoreを勝手に書き換える

・不要かどうか分からないファイルを削除する

といった操作も避けてください。

新人研修では、

「変更する前に、その設定やファイルが何のために存在するのか確認する」

ことを意識しましょう。

第5章で覚えたい操作の流れ

今回の操作を整理します。

Eclipseでプロジェクトを用意する

↓

プロジェクトを右クリック

↓

Team

↓

Share Project...

↓

Gitを選択する

↓

Gitリポジトリを作成する

↓

Git Stagingビューを確認する

↓

Gitで管理するファイルをStageする

↓

Commit Messageを書く

↓

Commitする

↓

Historyで確認する

この流れを一度、自分で実行してみてください。

特に、

「Git管理を開始しただけではCommitされない」

ことを覚えておきましょう。

Git管理を開始したあと、ファイルをStageしてCommitすることで、初めて変更履歴として記録されます。

第5章のまとめ

この章では、すでにEclipseに存在するプロジェクトをEGitでGit管理する方法を説明しました。

プロジェクトをGit管理するときは、

Team

↓

Share Project...

からGitとの関連付けを行います。

Gitリポジトリを作成すると、プロジェクトの変更をGitで追跡できるようになります。

ただし、Git管理を開始しただけでは履歴は作成されません。

管理したいファイルをStageし、Commitする必要があります。

また、すべてのファイルをGitで管理する必要があるとは限りません。

管理対象から除外したいファイルは、.gitignoreで指定できます。

ただし、.gitignoreの内容はプロジェクトごとのルールを優先してください。

新人研修では、

Share Project

↓

Stage

↓

Commit

↓

Historyで確認

という流れを実際に体験して、

「普通のEclipseプロジェクトが、どうやってGit管理されるのか」

を理解することが大切です。

次の章では、実務でより頻繁に使うCloneを扱います。

すでにリモートリポジトリ上に存在するプロジェクトを自分のパソコンへ取得し、Eclipseで作業を始めるまでの流れを身につけましょう！

第6章 EGitでリモートリポジトリをCloneする方法｜Eclipseに既存プロジェクトを取り込もう

第5章では、Eclipse上にあるプロジェクトをGitで管理する方法を説明しました。

今回は、実務でより使用する機会が多いCloneについて解説します。

新人として既存の開発プロジェクトへ参加する場合、自分で新しいGitリポジトリを作るより、

「すでにあるリモートリポジトリを自分のパソコンへ取得する」

ところから始まるケースが多いでしょう。

そのときに使うのが、

Clone

です。

Cloneを使うと、リモートリポジトリにあるソースコードだけでなく、Gitの履歴やブランチに関する情報も自分のパソコンへ取得できます。

この章では、EGitを使ってリモートリポジトリをCloneし、Eclipseでプロジェクトを開くまでの流れを説明します。

Cloneとは

Cloneとは、リモートリポジトリを自分のパソコンへ複製する操作です。

たとえば、会社のGitサーバーに、

SampleSystem

というリポジトリがあるとします。

新人としてSampleSystemの開発へ参加する場合、まず自分のパソコンに開発環境を用意しなければなりません。

そのときにCloneを実行すると、

リモートリポジトリ

↓

自分のパソコン

という方向にリポジトリを取得できます。

第2章で、

「Cloneは、リモートリポジトリを自分のパソコンへ複製する操作」

と説明しました。

今回は、実際にその操作を行います。

Cloneはファイルのコピーとは違う

Cloneについて理解するときに大切なのは、単なるファイルコピーとは違うという点です。

たとえば、誰かからJavaプロジェクトのフォルダーだけをUSBメモリでもらったとしましょう。

その場合、現在のソースコードは手に入ります。

しかし、Gitの過去のCommit履歴やブランチ情報まで正しく引き継げるとは限りません。

Cloneでは、Gitリポジトリとして必要な情報を取得します。

たとえるなら、教科書の最新ページだけをコピーするのではなく、

・最初の版

・途中で修正された版

・変更履歴

・どの版から枝分かれしたか

といった管理情報まで含めて受け取るようなイメージです。

チーム開発では、この違いがとても重要です。

既存のGitプロジェクトへ参加するときは、基本的にフォルダーを手作業でコピーするのではなく、Cloneを使いましょう。

Cloneに必要な情報

Cloneするには、リモートリポジトリの場所を指定する必要があります。

一般的には、リポジトリのURLを使用します。

接続方法によって、

HTTPS形式

SSH形式

などがあります。

たとえば、HTTPSで接続する場合は、

https://example.com/sample/sample-project.git

のような形式です。

SSHで接続する場合は、別の形式になります。

ただし、新人研修では接続方式を自分で判断して変更しないでください。

会社や研修担当者から、

「このURLを使ってCloneしてください」

と指定されたものを使用しましょう。

リポジトリのURLはどこから取得する？

GitHubやGitLabなどのGitホスティングサービスでは、リポジトリの画面からClone用URLを確認できます。

社内Gitサーバーでも、同様にURLが用意されている場合があります。

新人研修では、研修担当者からURLを渡されるケースも多いでしょう。

たとえば、

SampleSystemのリポジトリをCloneしてください。

URLはこちらです。

https://example.com/training/sample-system.git

というように案内されます。

このURLは、Gitにとってリポジトリの住所のようなものです。

宅配便を送るときに住所が必要なのと同じで、Gitも、

「どこのリポジトリを取得するのか」

を知るためにURLを使います。

EGitからCloneを開始する

それでは、EclipseからCloneを開始しましょう。

方法はいくつかありますが、新人研修ではGit Repositoriesビューから操作すると分かりやすいでしょう。

まず、

Window

↓

Show View

↓

Other...

↓

Git

↓

Git Repositories

からGit Repositoriesビューを表示します。

Git Repositoriesビュー内には、

Clone a Git repository

または

Clone a Git repository and add the clone to this view

のような操作が表示される場合があります。

Eclipseのバージョンによって表示名が多少異なることがあります。

Cloneに関する項目を選択してください。

ImportからCloneする方法もある

Eclipseでは、ImportからCloneを開始することもできます。

たとえば、

File

↓

Import...

↓

Git

↓

Projects from Git

のように進みます。

その後、

Clone URI

を選択する方法があります。

どちらの方法を使っても、最終的にはリモートリポジトリをCloneできます。

新人研修では、

Git RepositoriesビューからClone

または

File → ImportからClone

のどちらかを覚えておけば十分です。

大切なのは、

「Cloneの入口が複数ある」

ということです。

ボタンの場所だけを暗記すると、画面配置が変わったときに迷います。

「Gitリポジトリを取得したいからCloneを使う」

という目的から操作を考えてください。

Clone URIとは

Cloneの画面では、

URI

Host

Repository path

Protocol

User

Password

などの項目が表示される場合があります。

URIとは、

Uniform Resource Identifier

の略です。

簡単に言えば、

「リモートリポジトリの場所を表す情報」

です。

新人研修では、URIとURLの細かな違いまで覚える必要はありません。

Clone用URLを入力する場所だと考えればよいでしょう。

指定されたClone URLをURI欄へ入力します。

URLを入力すると情報が自動入力されることがある

EGitでは、URI欄へClone URLを入力すると、

Host

Repository path

Protocol

などが自動的に入力される場合があります。

たとえば、

https://example.com/training/sample-system.git

と入力した場合、

Protocol

https

Host

example.com

Repository path

/training/sample-system.git

のように分解されます。

ここで、

「全部自分で入力しなければいけない」

と思う必要はありません。

URLが正しければ、EGitが必要な情報を解析してくれることがあります。

ただし、自動入力された内容が会社から指定された接続先と一致しているかは確認してください。

認証情報を入力する

リモートリポジトリが認証を必要とする場合、ユーザー情報の入力を求められます。

利用する認証方式は環境によって異なります。

たとえば、

・ユーザー名

・パスワード

・アクセストークン

・SSH鍵

・社内認証

などが使われる場合があります。

第3章でも説明しましたが、

user.name

user.email

と、リモートリポジトリへ接続するための認証情報は別物です。

ここを混同しないようにしてください。

user.nameはCommitの作成者情報です。

一方、Clone時の認証は、

「このリポジトリへアクセスする権限があるか」

を確認するために使われます。

書類に書く名前と、会社の入口で使う社員証が別なのと同じです。

パスワードを保存する設定には注意する

認証画面では、

Store in Secure Store

など、認証情報を保存するための選択肢が表示される場合があります。

便利な機能ですが、会社のセキュリティルールに従ってください。

共有PCや研修用PCでは、認証情報を保存してはいけない場合もあります。

新人の段階では、

「毎回入力するのが面倒だから保存する」

という理由だけで設定を変更しないようにしましょう。

会社の開発環境では、安全性が優先されます。

Branch Selectionとは

接続に成功すると、

Branch Selection

のような画面が表示される場合があります。

ここでは、リモートリポジトリに存在するブランチを確認できます。

たとえば、

main

develop

feature/login

などのブランチが表示されることがあります。

新人研修では、基本的に研修担当者から指定されたブランチを使用してください。

全部のブランチを理解する必要はありません。

特に、

「よく分からないから全部選択する」

という操作は避けましょう。

Clone時にどのブランチ情報を取得するかはプロジェクトの運用によって異なります。

指定がある場合は、その内容に従ってください。

mainブランチとは

Gitを使っていると、

main

という名前のブランチをよく見かけます。

mainは、主要な開発ラインとして使われることが多いブランチ名です。

ただし、すべてのプロジェクトでmainが使われるとは限りません。

プロジェクトによっては、

master

develop

など、別のブランチが基準になっている場合もあります。

そのため、

「必ずmainを使う」

と覚えないようにしてください。

会社の開発ルールでは、

「作業はdevelopから開始する」

「新人は指定されたfeatureブランチを使う」

などの決まりがある場合があります。

必ずプロジェクトの運用ルールを優先しましょう。

Local Destinationとは

次に、リポジトリを自分のパソコンのどこへ保存するか指定します。

この保存先を、

Local Destination

などと呼びます。

たとえば、

C:\Users\user\git\sample-system

のような場所です。

環境によっては、EGitのデフォルトリポジトリフォルダーが自動入力されます。

新人研修では、特に理由がなければ研修担当者から指定された場所や、EGitで設定されている標準の保存場所を使いましょう。

保存先はEclipseのワークスペースと同じ？

ここは少し混乱しやすいポイントです。

Gitリポジトリの保存場所と、Eclipseのワークスペースは、同じとは限りません。

第3章でも説明しましたが、

Eclipseのワークスペース

と

Gitリポジトリ

は役割が異なります。

Gitリポジトリは、Gitがソースコードや履歴を管理する場所です。

Eclipseのワークスペースは、Eclipseがプロジェクトや設定などを管理する作業領域です。

新人のうちは、

「Cloneしたリポジトリを、あとからEclipseのプロジェクトとして読み込む」

という2段階の流れを意識すると分かりやすいでしょう。

Cloneを実行する

設定内容を確認したらCloneを実行します。

リモートリポジトリからデータが取得されます。

リポジトリのサイズやネットワーク環境によっては、多少時間がかかる場合があります。

Cloneが完了すると、自分のパソコンにGitリポジトリが作成されます。

Git Repositoriesビューを確認してください。

Cloneしたリポジトリが表示されていれば、EGitが認識しています。

ここで重要なのは、

「Cloneが成功した = EclipseのJavaプロジェクトとして開ける」

とは限らない点です。

次に、CloneしたプロジェクトをEclipseへImportする必要がある場合があります。

CloneとImportは別の操作

CloneとImportの違いは新人がつまずきやすいところです。

Cloneは、

リモートリポジトリを自分のパソコンへ取得する操作

です。

Importは、

取得したプロジェクトをEclipseで扱える状態にする操作

です。

たとえば、通販で机を買う場面を想像してみましょう。

商品が自宅へ届くのがCloneです。

届いた机を部屋に置いて、実際に使える状態にするのがImportです。

Gitリポジトリを取得しただけでは、Package Explorerにプロジェクトが表示されない場合があります。

そのときはImportを行います。

Clone後にプロジェクトをImportする

Cloneのウィザードをそのまま進めると、

Import Projects

の画面へ移動する場合があります。

また、あとから手動でImportすることもできます。

一般的には、

File

↓

Import...

からプロジェクトを読み込みます。

EGit経由でCloneした場合は、

Git

↓

Projects from Git

から進む方法もあります。

Clone済みのリポジトリを選択し、プロジェクトをEclipseへ取り込みます。

Import existing Eclipse projectsとは

Cloneしたリポジトリの中に、Eclipseプロジェクトとして必要な設定ファイルが含まれている場合、

Import existing Eclipse projects

のような選択肢を利用できることがあります。

これは、

「すでにEclipseプロジェクトとして構成されているものを、そのまま読み込む」

ための方法です。

たとえば、リポジトリに、

.project

などのEclipse用設定が含まれている場合です。

既存のEclipseプロジェクトをCloneした場合には、分かりやすい方法でしょう。

MavenやGradleのプロジェクトではImport方法が違う場合がある

実務では、JavaプロジェクトにMavenやGradleが使われている場合があります。

Mavenは、

pom.xml

Gradleは、

build.gradle

などのファイルを使って、依存ライブラリやビルド方法を管理します。

このようなプロジェクトでは、

Maven ProjectとしてImport

Gradle ProjectとしてImport

する方が適切な場合があります。

新人研修では、研修担当者から指定されたImport方法を使ってください。

「GitでCloneしたから、必ずProjects from Gitだけを使う」

とは限りません。

Gitはリポジトリを取得する役割です。

Eclipseにどう読み込むかは、プロジェクトの種類によって変わります。

Package Explorerにプロジェクトが表示されたか確認する

Importが完了したら、Package Explorerを確認します。

SampleSystemなど、Cloneしたプロジェクトが表示されていれば、Eclipseから開ける状態です。

srcフォルダーやJavaファイルを開いてみましょう。

ここまでできれば、

リモートリポジトリ

↓

Clone

↓

ローカルリポジトリ

↓

Import

↓

Eclipseで編集可能

という流れが完成します。

新人研修では、この流れを自分で説明できるようにしてください。

Git Repositoriesビューも確認する

Package Explorerだけでなく、Git Repositoriesビューも確認してみましょう。

Cloneしたリポジトリが表示され、

Branches

Remotes

Working Tree

などを確認できるはずです。

Remotesを展開すると、

origin

という名前が表示される場合があります。

第4章で説明したとおり、originはClone元のリモートリポジトリにつけられることが多い名前です。

つまり、

「このローカルリポジトリは、どこからCloneしてきたのか」

を確認する手がかりになります。

現在のブランチを確認する

Clone後には、現在どのブランチで作業しているのか確認してください。

たとえば、

main

develop

などです。

Package Explorerのプロジェクト名の近くや、Git Repositoriesビューなどで確認できる場合があります。

新人のうちから、

「作業を始める前にブランチを確認する」

習慣をつけましょう。

なぜなら、違うブランチで修正してしまうと、

「修正内容は正しいのに、作業場所が違う」

という問題が発生するからです。

たとえるなら、提出する予定の数学ノートではなく、英語ノートに数学の宿題を書いてしまうようなものです。

内容が正しくても、場所が違えば困りますよね。

Clone後にすぐ編集してもいい？

Cloneしてプロジェクトが開けたら、

「よし、すぐに修正しよう！」

と思うかもしれません。

しかし、実務では作業開始前にいくつか確認した方が安全です。

たとえば、

・正しいリポジトリをCloneしたか

・正しいブランチにいるか

・プロジェクトにエラーがないか

・必要なライブラリが取得できているか

・会社指定の設定が反映されているか

などです。

特に新人研修では、Clone後の状態確認を飛ばさないでください。

「取得できたから作業開始」ではなく、

「正しい状態で取得できたことを確認してから作業開始」

が重要です。

Eclipseで大量のエラーが出た場合

CloneしてImportした直後に、Eclipseへ大量のエラーが表示されることがあります。

驚くかもしれませんが、すぐにソースコードが壊れていると判断しないでください。

たとえば、

・JDKの設定が違う

・Mavenの依存ライブラリがまだ取得されていない

・Gradleの同期が終わっていない

・必要な環境変数が設定されていない

・Eclipseのプロジェクト設定が合っていない

といった原因が考えられます。

GitのClone自体は正常に成功していても、Eclipse側の開発環境が整っていない場合があります。

新人研修では、原因が分からない状態でソースコードを変更しないでください。

まず研修担当者へ確認しましょう。

Cloneに失敗した場合の確認ポイント

Cloneが失敗する場合は、いくつか確認するポイントがあります。

まず確認したいのが、Clone URLです。

1文字でも間違っていると、正しいリポジトリへ接続できません。

次に、認証情報を確認します。

アクセス権限がない場合や、認証方式が違う場合にはCloneできません。

さらに、

・社内ネットワークへ接続しているか

・VPNが必要ではないか

・プロキシ設定が必要ではないか

・リポジトリへのアクセス権限が付与されているか

など、会社のネットワーク環境が原因になる場合もあります。

エラーが出たときは、

「とりあえず設定をいろいろ変更する」

のではなく、エラーメッセージを確認してください。

そして、自分で変更してよい範囲が分からない場合は研修担当者へ相談しましょう。

Authentication Failedと表示された場合

Clone時に、

Authentication Failed

のようなエラーが表示される場合があります。

Authenticationは「認証」という意味です。

つまり、

「あなたがこのリポジトリへアクセスできる利用者なのか確認できなかった」

という状態です。

考えられる原因として、

・ユーザー情報が違う

・アクセストークンが違う

・SSH鍵が設定されていない

・アクセス権限が付与されていない

・指定された認証方式と違う

などがあります。

ここでuser.nameを書き換えても、認証エラーが直るとは限りません。

第3章で説明したとおり、

Gitのuser.name

と

サーバーへログインする認証情報

は役割が違うからです。

Repository not foundと表示された場合

Repository not foundというエラーが表示される場合もあります。

直訳すると、

「リポジトリが見つからない」

という意味です。

考えられる原因は、

・URLが間違っている

・リポジトリが削除されている

・アクセス権限がない

・対象の組織やプロジェクトが違う

などです。

特に、権限がない場合でもRepository not foundのように表示されるサービスがあります。

そのため、

「URLは絶対合っているからGitの故障だ」

と決めつけないでください。

URLと権限の両方を確認しましょう。

すでに同じ場所にCloneされている場合

指定した保存先にすでに同名のフォルダーやGitリポジトリが存在すると、Cloneできない場合があります。

このとき、新しいフォルダー名を適当に付けて、

sample-system2

sample-system-new

sample-system-final

のように増やしていくのはおすすめしません。

どれが正しい作業環境なのか分からなくなってしまいます。

まず、

「すでにClone済みではないか」

を確認してください。

Git Repositoriesビューに対象リポジトリが登録されている可能性もあります。

新人研修では、作業環境をむやみに増やさないようにしましょう。

Cloneは毎日する操作ではない

Cloneを覚えると、

「作業を始めるたびにCloneするの？」

と思うかもしれません。

基本的には違います。

Cloneは、

「リモートリポジトリを初めて自分のパソコンへ用意するとき」

に行う操作です。

一度Cloneした後は、毎日Cloneし直すのではなく、Pullなどを使ってリモート側の最新変更を取得します。

たとえば、教科書を毎朝新しく買い直す必要はありませんよね。

最初に教科書を用意し、その後は先生から配られる追加資料や修正を受け取ります。

Gitも似ています。

最初にClone。

その後はPullなどを使って更新します。

この違いは必ず覚えてください。

CloneとPullの違い

CloneとPullは、どちらもリモートリポジトリから情報を取得するため、初心者には似て見えるかもしれません。

違いを整理しましょう。

Cloneは、

リポジトリそのものを初めて自分のパソコンへ複製する操作

です。

Pullは、

すでにCloneしてあるリポジトリへ、リモート側の新しい変更を取り込む操作

です。

引っ越しに例えると分かりやすいでしょう。

Cloneは、

新しい部屋へ必要な家具を一式運び込んで生活を始める

ような操作です。

Pullは、

生活を始めた後に、新しく届いた荷物を部屋へ取り込む

ような操作です。

毎回引っ越し直す必要はありません。

Clone後にファイルを修正するとどうなる？

CloneしたプロジェクトのファイルをEclipseで修正して保存すると、Git StagingビューのUnstaged Changesに表示されます。

たとえば、

Main.java

を修正したとします。

保存後にGit Stagingビューを見ると、Main.javaが変更ファイルとして表示されます。

つまり、Cloneした直後からGit管理された状態になっています。

第5章のShare Projectとは違い、

「Cloneしたあとに、もう一度Share Projectする」

必要はありません。

Cloneしたリポジトリは、すでにGitリポジトリです。

ここは重要です！

CloneしたプロジェクトにShare Projectをしてはいけない

新人が混乱しやすいので、もう少し詳しく説明します。

第5章では、

普通のEclipseプロジェクト

↓

Share Project

↓

Git管理を開始

という操作をしました。

一方、今回のCloneでは、

リモートのGitリポジトリ

↓

Clone

↓

自分のGitリポジトリ

となります。

すでにGit管理されています。

そのため、

「Gitを使うならShare Projectもしなきゃ」

と考えて、Cloneしたプロジェクトへ新しいGitリポジトリを作らないようにしてください。

既存プロジェクトでは、どのリポジトリに属しているのか確認することが大切です。

実務でのCloneの流れ

ここまでの操作を、実際の新人配属時の流れとして整理してみましょう。

研修担当者からClone URLを受け取る

↓

EclipseでGit Repositoriesビューを開く

↓

Cloneを開始する

↓

Clone URLを入力する

↓

必要に応じて認証する

↓

指定されたブランチを確認する

↓

保存先を確認する

↓

Cloneする

↓

EclipseへImportする

↓

Package Explorerでプロジェクトを確認する

↓

Git Repositoriesビューでリポジトリを確認する

↓

現在のブランチを確認する

↓

プロジェクトが正常に開けるか確認する

この流れを一度、自分で実行してみてください。

新人がClone後に確認したいチェックポイント

Cloneが終わったら、次の項目を確認しましょう。

正しいリポジトリをCloneしたか
Package Explorerに対象プロジェクトが表示されているか
Git Repositoriesビューにリポジトリが表示されているか
originなどのリモート情報が登録されているか
正しいブランチを使用しているか
Eclipseに重大なエラーが出ていないか
プロジェクトが実行できる状態か

特に、

「Cloneが成功した」

ことと、

「開発を始められる状態になった」

ことは同じではありません。

Clone後の確認まで含めて作業だと考えてください。

第6章のまとめ

この章では、EGitを使ってリモートリポジトリをCloneし、Eclipseへプロジェクトを取り込む流れを説明しました。

Cloneとは、

リモートリポジトリを自分のパソコンへ複製する操作

です。

単に現在のファイルをコピーするのではなく、Gitリポジトリとして必要な情報を取得します。

新人として既存プロジェクトへ参加するときには、非常によく使う操作です。

基本的な流れは、

Clone URLを取得する

↓

EGitでCloneする

↓

ローカルリポジトリが作成される

↓

EclipseへImportする

↓

プロジェクトとブランチを確認する

となります。

また、CloneとImportは別の役割を持っています。

CloneはGitリポジトリを取得する操作。

Importは取得したプロジェクトをEclipseで扱えるようにする操作です。

さらに、

Cloneは最初に1回行う操作

Pullはその後の更新を取り込む操作

という違いも覚えてください。

Cloneしたリポジトリは、すでにGit管理されています。

改めてShare Projectで別のリポジトリを作らないようにしましょう。

ここまでで、実際の開発プロジェクトを自分のEclipseへ用意できるようになりました。

次の章では、Cloneしたプロジェクトのファイルを実際に修正し、

変更内容の確認

↓

Stage

↓

Commit

という、日常のGit作業で最も重要な流れを詳しく解説します。

新人研修では特に重要な章になります。操作を一つずつ確認しながら、Commitまでの流れを身につけていきましょう！

第7章 EGitで変更をStageしてCommitする方法｜新人が覚える基本操作

第6章では、リモートリポジトリをCloneして、Eclipseへプロジェクトを取り込む方法を説明しました。

ここからは、実際にソースコードを変更してGitへ記録していきます。

新人研修で特に重要なのが、

編集

↓

差分確認

↓

Stage

↓

Commit

という流れです。

Gitを使った日常業務では、何度も繰り返す操作になります。

この流れをしっかり身につければ、EGitを使った基本的な作業の大部分は理解できたといってよいでしょう。

まずは、ファイルを変更したあとに何が起きるのかから確認していきます。

ファイルを変更するとGitはどうなる？

CloneしたプロジェクトのJavaファイルを1つ変更してみましょう。

たとえば、

Main.java

というファイルがあるとします。

修正前が、

System.out.println("Hello");

だったとしましょう。

この部分を、

System.out.println("Hello EGit");

へ変更して保存します。

Eclipse上では、普段どおりCtrl + Sなどで保存します。

ここで重要なのは、

「保存しただけではCommitされていない」

という点です。

第1章でも説明しましたが、保存とCommitは別の操作です。

保存した時点では、

「ファイルの内容が変わった」

だけです。

Gitの履歴には、まだ何も記録されていません。

Git Stagingビューを確認する

ファイルを保存したら、Git Stagingビューを開いてください。

Git Stagingビューでは、

Unstaged Changes

Staged Changes

Commit Message

などを確認できます。

変更したMain.javaが、

Unstaged Changes

に表示されているはずです。

Unstaged Changesは、

「変更されているけれど、まだ次のCommitへ含めると決めていない変更」

です。

つまり、

編集した

↓

保存した

↓

Gitが変更を検出した

という状態です。

まだCommitの準備は終わっていません。

まずは差分を確認する

変更したファイルが表示されたら、いきなりStageしないでください。

最初に差分を確認します。

差分とは、

「変更前と変更後の違い」

です。

英語ではDiffと呼ばれます。

Main.javaを選択すると、変更前と変更後を比較できる画面を表示できます。

先ほどの例なら、

変更前

System.out.println("Hello");

変更後

System.out.println("Hello EGit");

という差分です。

この確認作業は非常に重要です。

なぜ差分を確認するの？

自分で書き換えたのだから、差分を見る必要はないと思うかもしれません。

しかし、実務では意図しない変更が混ざることがあります。

たとえば、

・デバッグ用のコードを残していた

・不要なコメントを追加していた

・関係のない場所を変更していた

・一時的な設定変更を元に戻し忘れた

・ファイルの文字コードや改行コードまで変わっていた

といったケースです。

テストの答案に例えてみましょう。

最後まで解き終わったからといって、そのまま提出すると、

「名前を書き忘れた」

「問題番号をずらしていた」

といったミスに気づかない場合があります。

提出前に見直しますよね。

Gitでも同じです。

Commit前の差分確認は、

「提出前の見直し」

だと考えてください。

変更したファイルが複数ある場合

実際の開発では、1つの作業で複数ファイルを変更することがあります。

たとえば、

LoginController.java

LoginService.java

LoginForm.java

の3ファイルを変更したとします。

Git Stagingビューには、3ファイルともUnstaged Changesとして表示されます。

ここで、

「全部自分が変更したから、全部まとめてStageしよう」

と考えないでください。

それぞれの変更が、

「同じ目的の変更なのか」

を確認します。

ログイン機能の修正として3ファイルすべてが必要なら、同じCommitに含めてもよいでしょう。

一方、1ファイルだけ別件の修正なら、別のCommitに分けた方が履歴を理解しやすくなります。

1つのCommitには1つの目的を持たせる

Gitでは、

「1つのCommitに、できるだけ1つの目的を持たせる」

考え方が重要です。

たとえば、

ログイン画面の入力チェック追加

商品検索画面のレイアウト修正

READMEの誤字修正

という3つの変更を1つのCommitへまとめるとします。

Commit Messageが、

各種修正

になってしまったらどうでしょう。

後から履歴を見ても、

「何を修正したCommitなのか」

が分かりにくくなります。

できれば、

ログイン画面の入力チェック追加

というCommit、

商品検索画面のレイアウト修正

というCommit、

READMEの誤字修正

というCommit、

のように分けた方が分かりやすくなります。

お弁当に例えるなら、

主菜

副菜

デザート

を全部ぐちゃぐちゃに混ぜるより、仕切りを使って分けた方が何が入っているか分かりますよね。

Commitも同じです。

Stageとは

差分を確認したら、次にStageします。

Stageとは、

「次のCommitに含める変更を選ぶ操作」

です。

Git Stagingビューでは、

Unstaged Changes

から

Staged Changes

へファイルを移動します。

たとえば、Main.javaを次のCommitへ含めたい場合は、Main.javaをStageします。

すると、

Unstaged Changes

↓

Staged Changes

へ移動します。

これで、

「次のCommitにMain.javaの変更を含める」

とGitへ伝えたことになります。

StageしただけではCommitされていない

ここも注意してください。

Stageした時点では、まだCommitされていません。

状態としては、

編集

↓

保存

↓

差分確認

↓

Stage

まで進んだだけです。

旅行の荷造りで考えてみましょう。

部屋にある荷物から、

「旅行へ持っていくもの」

をスーツケースへ入れた状態がStageです。

まだ旅行へ出発してはいません。

Commitすることで、ひとまとまりの履歴として記録されます。

Stageを取り消すこともできる

間違えてStageしてしまうこともあります。

たとえば、

README.mdは今回のCommitに含めたくないのに、誤ってStageした

という場合です。

その場合は、Staged ChangesからUnstaged Changesへ戻せます。

この操作は、

「Stageを取り消す」

だけです。

ファイルの変更内容そのものを削除するわけではありません。

ここを混同しないでください。

Stageの取り消しは、

「今回のCommit対象から外す」

だけです。

修正内容を消す操作ではありません。

Commit Messageを書く

Stageが終わったら、Commit Messageを書きます。

Commit Messageは、

「そのCommitで何を変更したのか」

を説明する文章です。

たとえば、

修正

だけでは意味が分かりません。

変更

対応

更新

といった短すぎるメッセージも、後から内容を判断しづらいでしょう。

おすすめなのは、

何をしたのかが具体的に分かるメッセージ

です。

たとえば、

ログイン画面に未入力チェックを追加

商品検索条件にカテゴリを追加

ユーザー登録時のメール形式チェックを修正

などです。

Commit Messageは未来の自分へのメモでもある

Commit Messageは、チームメンバーだけが読むものではありません。

未来の自分も読みます。

3か月後に、

「なぜこの処理が入っているんだろう？」

と思ったとします。

Historyを確認すると、

ログイン画面の未入力時にエラー表示を追加

というCommitが見つかれば、変更内容を思い出しやすいでしょう。

一方、

修正

としか書かれていなければ、履歴をたどっても意味が分かりません。

Commit Messageは、

「未来の自分とチームに残す説明書」

だと考えてください。

良いCommit Messageの考え方

新人研修では、難しいルールをたくさん覚える必要はありません。

まずは、

「何を変更したかが分かる」

ことを意識してください。

悪い例

修正

悪い例

変更

悪い例

対応

良い例

ログイン時のパスワード未入力チェックを追加

良い例

商品検索画面の初期表示条件を修正

良い例

会員登録時のメール形式チェックを追加

会社やプロジェクトによって、Commit Messageの書き方にルールがある場合もあります。

たとえば、

・チケット番号を先頭に付ける

・英語で書く

・命令形で書く

・1行目の文字数を制限する

などです。

実務では、必ずプロジェクトのルールを優先してください。

Commit前にStaged Changesを確認する

Commit Messageを書いたら、すぐCommitボタンを押したくなるかもしれません。

その前に、Staged Changesをもう一度確認してください。

確認したいのは、

・必要なファイルが入っているか

・不要なファイルが入っていないか

・差分は正しいか

・Commit Messageは内容と合っているか

です。

特に、

「関係のないファイルが1つ混ざっている」

というミスはよくあります。

Commit前に一度確認するだけで、多くのミスを防げます。

Commitを実行する

内容を確認できたらCommitします。

Commitすると、Staged Changesにあった変更がローカルリポジトリへ記録されます。

これで、

編集

↓

保存

↓

差分確認

↓

Stage

↓

Commit

という基本操作が完了しました。

ここで、

「チームにも変更が共有された！」

と思わないでください。

まだです。

Commitした内容は、基本的に自分のローカルリポジトリへ記録されています。

リモートリポジトリへ送るにはPushが必要です。

次の章で詳しく扱います。

Commit後にGit Stagingビューを見る

Commitが成功すると、Staged Changesに表示されていたファイルが消えます。

変更内容がすべてCommitされていれば、

Unstaged Changes

Staged Changes

の両方が空になります。

つまり、

「現在の作業ファイルと最新Commitの間に、未記録の変更がない」

状態です。

このような状態を確認してから次の作業へ進むと安心です。

HistoryビューでCommitを確認する

Commitしたら、Historyビューでも確認してみましょう。

対象プロジェクトを右クリックし、

Team

↓

Show in History

などから履歴を表示します。

今作成したCommitが一覧に表示されるはずです。

確認したいのは、

・Commit Message

・作成者

・日時

・変更されたファイル

です。

自分が書いたCommit Messageが履歴として残っていることを確認してください。

ここで、

「Commitとは、本当に履歴を作る操作なんだ」

と実感できるはずです。

Commitと保存の違いをもう一度確認する

新人研修では、保存とCommitを混同しやすいため、もう一度整理します。

保存は、

現在のファイル内容をパソコンへ保存する操作

です。

Commitは、

変更内容をGitの履歴として記録する操作

です。

たとえば、

Ctrl + S

を押しただけではCommitされません。

反対に、Commitしようとしてもファイルを保存していなければ、最新の編集内容がCommit対象に入らない場合があります。

基本的には、

編集

↓

保存

↓

Gitで差分確認

↓

Stage

↓

Commit

という順番で作業しましょう。

CommitとPushの違いも重要

CommitとPushも混同しやすいポイントです。

Commitは、

自分のローカルリポジトリへ変更履歴を記録する

操作です。

Pushは、

ローカルリポジトリのCommitをリモートリポジトリへ送る

操作です。

たとえば、会社で報告書を作成するとします。

自分のパソコンに完成版を保存して整理した状態がCommit。

会社の共有システムへ提出した状態がPush。

そんなイメージです。

Commitだけでは、ほかのメンバーはあなたの変更を取得できません。

Commitは細かくした方がいい？

「どれくらいの単位でCommitすればいいの？」

という疑問もよくあります。

細かければ細かいほど良い、というわけではありません。

逆に、1日分の変更を全部まとめれば良いわけでもありません。

基本的には、

「意味のある作業単位」

でCommitします。

たとえば、

ログイン画面の入力チェックを追加

という作業なら、入力チェックに必要な変更がひとまとまりになった時点でCommitします。

途中で、

「まだコンパイルエラーが大量に出る」

ような状態を無理にCommitする必要はありません。

ただし、会社の開発ルールによっては細かくCommitする方針もあります。

研修では、

「何を変更したCommitなのか説明できる単位」

を意識してください。

関係ない変更は分ける

たとえば、ログイン機能を修正している途中で、

README.mdの誤字

を見つけたとします。

ついでに直すこと自体は問題ない場合もあります。

ただし、

ログイン機能の修正

と

READMEの誤字修正

を同じCommitへ入れる必要はありません。

別々にStageしてCommitすれば、

ログイン時の入力チェックを追加

READMEの誤字を修正

という2つの履歴になります。

後から見たときに、とても分かりやすくなります。

「同時に変更したから同じCommit」

ではなく、

「同じ目的の変更だから同じCommit」

と考えてください。

不要なファイルが表示された場合

Git Stagingビューに、自分が意図していないファイルが表示される場合があります。

たとえば、

・Eclipseの設定ファイル

・一時ファイル

・ログファイル

・自動生成ファイル

などです。

その場合、

「邪魔だから削除する」

のではなく、まずなぜ変更されたのか確認してください。

.gitignoreへ追加すべきファイルかもしれません。

一方、プロジェクトとして管理すべき重要なファイルかもしれません。

新人の段階では、判断できないファイルを自己判断で削除したり、.gitignoreへ追加したりしないでください。

研修担当者やプロジェクトルールを確認しましょう。

変更していないのにファイルが大量表示される場合

自分では何も変更していないのに、大量のファイルがUnstaged Changesに表示されることがあります。

原因として、

・改行コードが変わった

・文字コードが変わった

・自動フォーマットが実行された

・ビルドによって生成ファイルが変わった

・Eclipseの設定によってファイルが更新された

などが考えられます。

この状態で、

「全部StageしてCommitすれば消える」

と考えないでください。

意図しない変更を大量に履歴へ残してしまいます。

まず差分を確認してください。

変更理由が分からなければ、Commitする前に相談しましょう。

ファイルごとではなく変更内容を意識する

Gitでは、ファイル単位でStageするだけでなく、環境によっては変更の一部分だけをStageする操作もできます。

たとえば、Main.javaの中で、

ログイン機能の修正

README用のサンプルコード修正

という2種類の変更をしてしまったとします。

理想的には、変更内容を分けてCommitしたいところです。

Gitには部分的に変更をStageする考え方があります。

ただし、新人研修では最初から複雑な部分Stageを覚えなくても問題ありません。

まずは、

「1つのファイルの中にも、別目的の変更を混ぜない」

という意識を持ってください。

作業を始める前に目的を決めておくと、Commitもきれいになります。

Commit and Pushはまだ使わない方がよい

EGitには、

Commit and Push

という便利なボタンがあります。

Commitした直後にPushまで実行できます。

しかし、新人研修では最初のうちは、

Commit

と

Push

を別々に操作することをおすすめします。

なぜなら、

Commit = ローカルへの記録

Push = リモートへの共有

という違いを体感しやすいからです。

操作を覚える前に便利機能を使うと、

「今どこまで反映されているのか」

が分からなくなりやすいでしょう。

まずは一つずつ操作してください。

Commit前にプログラムを動かす

Gitの操作とは少し別の話ですが、Commit前にはプログラムが正しく動くか確認することも重要です。

たとえば、

・コンパイルエラーがないか

・テストが通るか

・修正した機能が期待どおり動くか

などを確認します。

Gitは変更履歴を管理してくれます。

しかし、

「その変更内容が正しいか」

までは判断してくれません。

間違ったプログラムでもCommitできます。

提出ボックスは答案の正解・不正解を判断せず、入れられた答案を受け取りますよね。

Gitも同じです。

Commitする人自身が、変更内容の品質を確認する必要があります。

新人研修で覚えたいCommit前チェック

Commit前には、最低限次の項目を確認してください。

プログラムを保存したか
Git Stagingビューを開いたか
Unstaged Changesに意図しないファイルがないか
差分を確認したか
必要な変更だけStageしたか
Staged Changesをもう一度確認したか
Commit Messageで変更内容が分かるか
プログラムが正常に動くか

慣れるまでは、この順番で確認することをおすすめします。

Git操作で大切なのは、

「早くCommitボタンを押すこと」

ではありません。

「何をCommitするのか把握してから押すこと」

です。

Commitしてから間違いに気づいたら？

Commit後に、

「ファイルを1つ入れ忘れた！」

「Commit Messageを間違えた！」

と気づくこともあります。

Gitには、直前のCommitを修正する機能があります。

たとえばAmendという操作です。

ただし、新人研修では自己判断で履歴の書き換えを行わない方が安全です。

特に、すでにPushしたCommitを変更すると、チームメンバーへ影響する可能性があります。

Commit後に間違いへ気づいたら、

まだPushしていないのか

すでにPushしたのか

を確認してください。

対処方法が分からない場合は、先輩や研修担当者へ相談しましょう。

Commit IDとは

GitのCommitには、それぞれを識別するためのIDがあります。

Commit IDやCommit Hashと呼ばれます。

たとえば、

a1b2c3d...

のような英数字です。

Gitでは、このIDを使って、

「どのCommitなのか」

を区別します。

学校の生徒に学籍番号があるようなものです。

同じようなCommit Messageがあっても、Commit IDはCommitを識別するために使えます。

Historyビューでも確認できます。

新人研修ではIDを暗記する必要はありません。

「Commitには固有の識別情報がある」

ことだけ覚えておきましょう。

新人がよくやる失敗

StageとCommitでは、新人がやりやすい失敗があります。

たとえば、

・差分を見ずに全部Stageする

・関係のないファイルまでCommitする

・Commit Messageを「修正」だけにする

・保存せずにCommitする

・Commitしただけで共有されたと思う

・大量の変更を1つのCommitへまとめる

・エラーが残ったままCommitする

などです。

一つひとつは小さなミスに見えるかもしれません。

しかし、チーム開発では履歴を読む人が自分だけではありません。

「あとから見た人が理解できるCommit」

を意識してください。

実務での基本的なCommitの流れ

ここまでの内容を、実務での一連の流れとして整理します。

作業対象のブランチを確認する

↓

ソースコードを修正する

↓

保存する

↓

動作確認する

↓

Git Stagingビューを開く

↓

Unstaged Changesを確認する

↓

差分を見る

↓

必要な変更だけStageする

↓

Staged Changesを確認する

↓

Commit Messageを書く

↓

Commitする

↓

Historyで確認する

新人研修では、この流れを何度か繰り返してください。

1回読んだだけではなく、実際に操作することが重要です。

第7章のまとめ

この章では、EGitを使って変更内容をStageし、Commitする方法を説明しました。

日常のGit作業では、

編集

↓

保存

↓

差分確認

↓

Stage

↓

Commit

という流れを何度も繰り返します。

特に重要なのは、差分確認です。

自分が意図した変更だけが含まれているか確認してからStageしてください。

Stageは、

次のCommitへ含める変更を選ぶ操作

です。

Commitは、

選んだ変更をローカルリポジトリへ履歴として記録する操作

です。

Commit Messageには、

「何を変更したのか」

が後から分かる内容を書きましょう。

また、Commitしただけではチームへ共有されません。

自分の変更をリモートリポジトリへ送るにはPushが必要です。

次の章では、

Fetch

Pull

Push

の違いを整理しながら、リモートリポジトリと変更をやり取りする方法を解説します。

特に、

「Commitしたのに相手から見えない」

「Pushしようとしたら拒否された」

「Pullすると何が起こるの？」

といった新人がつまずきやすいポイントを確認していきましょう！

第8章 EGitでFetch・Pull・Pushを使う方法｜リモートリポジトリと変更をやり取りしよう

第7章では、ファイルを編集し、差分を確認してStageし、Commitするまでの流れを説明しました。

ここまでできれば、自分のパソコンにあるローカルリポジトリへ変更履歴を残せます。

ただし、チーム開発では自分のパソコンだけで作業は完結しません。

ほかのメンバーが行った変更を受け取ったり、自分の変更をチームへ共有したりする必要があります。

そこで使うのが、

Fetch

Pull

Push

です。

新人研修では、この3つの違いを理解することが非常に重要です。

特に、

「Commitしたのに相手から見えない」

「PullとFetchは何が違うの？」

「Pushしたらエラーになった」

といった疑問はよく出てきます。

この章では、リモートリポジトリとのやり取りを一つずつ整理していきます。

まずローカルとリモートを思い出そう

第2章でも説明しましたが、Gitでは大きく分けて、

ローカルリポジトリ

リモートリポジトリ

の2つがあります。

ローカルリポジトリは、自分のパソコンにあるリポジトリです。

リモートリポジトリは、チームで共有するリポジトリです。

たとえば、自分のノートとクラス全員が見る掲示板を想像してください。

自分のノートに書いた内容は、自分しか見られません。

掲示板に貼れば、ほかの人も確認できます。

Gitでも似ています。

Commitは、自分のローカルリポジトリへ変更履歴を記録する操作です。

Pushは、そのCommitをリモートリポジトリへ送る操作です。

PullやFetchは、リモートリポジトリ側の情報を自分へ持ってくるために使います。

まずは方向を意識してください。

Pushとは

Pushは、自分のローカルリポジトリにあるCommitをリモートリポジトリへ送る操作です。

方向は、

ローカルリポジトリ

↓

リモートリポジトリ

です。

自分の変更を外へ押し出すイメージで覚えてください。

たとえば、

LoginService.java

を修正し、

ログイン時の未入力チェックを追加

というCommitを作成したとします。

その時点では、自分のローカルリポジトリにしか履歴がありません。

Pushすると、リモートリポジトリにもそのCommitが送られます。

チームメンバーは、その後Pullなどを行うことであなたの変更を取得できます。

CommitとPushは別の操作

この違いは何度でも確認してください。

Commitは、

自分のローカルリポジトリへ記録する

操作です。

Pushは、

Commitした履歴をリモートリポジトリへ送る

操作です。

たとえば、会社の日報を作る場面を想像してください。

日報を書き終え、自分のパソコンへ保存した状態がCommit。

社内システムへ提出した状態がPush。

自分のパソコンに保存しただけでは、上司は確認できませんよね。

Gitも同じです。

Commitしただけでは、チームには共有されません。

EGitでPushする

EGitでは、プロジェクトやリポジトリからPushできます。

たとえばPackage Explorerで対象プロジェクトを右クリックし、

Team

↓

Push Branch...

や、

Push to Upstream

などの項目を選択します。

表示される項目は、EclipseやEGitのバージョン、リポジトリの設定によって異なる場合があります。

Git Repositoriesビューから操作する方法もあります。

新人研修では、

「自分のCommitをリモートへ送るときはPush」

と覚えておけば十分です。

Upstreamとは

EGitの画面では、

Upstream

という言葉が出てくることがあります。

Upstreamとは、現在のローカルブランチが対応付けられているリモート側のブランチです。

たとえば、自分がローカルで、

main

というブランチを使っていて、そのブランチがリモートの、

origin/main

を追跡しているとします。

このような場合、Push to Upstreamを使うと、対応するリモートブランチへPushできます。

新人研修では、

「自分が作業しているブランチの送り先」

くらいに理解しておけばよいでしょう。

Push前に確認すること

Pushは、リモートリポジトリへ変更を送る操作です。

つまり、チームへ影響する操作でもあります。

そのため、Push前には最低限次の内容を確認しましょう。

・正しいブランチで作業しているか

・必要な変更をCommitしているか

・余計なCommitが入っていないか

・プログラムが正常に動くか

・リモート側に新しい変更がないか

特にブランチは重要です。

間違ったブランチへPushすると、意図しない場所に変更を共有してしまう場合があります。

Pushできないことがある

Pushを実行すると、必ず成功するとは限りません。

たとえば、

自分が最後にリモートを確認したあとで、別の人が先にPushした

場合です。

たとえば、AさんとBさんが同じブランチで作業しているとします。

最初は2人とも同じ状態です。

Aさんが修正して先にPushしました。

そのあと、Bさんが古い状態を基準にPushしようとします。

Gitは、

「リモート側には、あなたがまだ持っていない新しい変更があります」

と判断して、Pushを拒否することがあります。

non-fast-forwardとは

Pushが拒否されたときに、

non-fast-forward

という言葉が出ることがあります。

少し難しい言葉ですが、新人研修では、

「自分のローカルよりリモート側の方が先に進んでいるため、そのままPushできない」

と理解すれば十分です。

たとえば、共有ノートにほかの人がすでに続きを書いているのに、自分が古いコピーを上書きしようとしている状態を想像してください。

そのまま上書きすると、相手の変更が失われる可能性があります。

Gitはそれを防ぐためにPushを拒否します。

この場合は、まずリモート側の変更を取得し、自分の変更と合わせる必要があります。

PushできないからForce Pushは危険

Pushが失敗すると、

「強制的にPushすればいいのでは？」

と思うかもしれません。

GitにはForce Pushという操作があります。

しかし、新人研修では自己判断で使わないでください。

Force Pushは、リモートの履歴を書き換える可能性があります。

ほかのメンバーのCommitを失わせる危険もあります。

たとえば、共有ホワイトボードにほかの人が書いた内容があるのに、自分の古い写真を使ってホワイトボード全体を上書きするような操作です。

取り返しのつかないトラブルになる場合があります。

Pushできないときは、原因を確認してください。

Force Pushで無理やり解決しないことが重要です。

Fetchとは

Fetchは、リモートリポジトリの最新情報を取得する操作です。

方向は、

リモートリポジトリ

↓

ローカル側

です。

ただし、Fetchしただけでは、自分が現在作業しているファイルへすぐに変更が反映されるわけではありません。

ここがPullとの大きな違いです。

Fetchは、

「リモート側で何が変わったのかを確認するための情報を取得する」

というイメージです。

Fetchをたとえると

学校の掲示板に、新しい時間割が貼られたとします。

Fetchは、

「掲示板を見に行って、新しい時間割が出ていることを確認する」

ような操作です。

まだ自分の手帳を書き換えてはいません。

リモート側の最新状態を取得するだけです。

そのため、いきなり自分の作業内容へ影響させたくない場合に便利です。

EGitでFetchする

EGitでは、リポジトリやプロジェクトからFetchできます。

Git Repositoriesビューで対象リポジトリを開き、

Remotes

↓

origin

などからFetchする方法があります。

また、Teamメニューなどから操作できる場合もあります。

EclipseやEGitのバージョンによってメニュー構成は多少異なります。

新人研修では、ボタンの位置より、

Fetch = リモートの最新情報を取得する

という意味を覚えてください。

Fetchした後は何が変わる？

Fetchすると、リモート側の最新のブランチ情報などが自分のローカル環境へ取得されます。

たとえば、リモートのmainブランチに新しいCommitが増えていた場合、

origin/main

などのリモート追跡ブランチが更新されます。

一方、自分が作業しているローカルのmainブランチは、そのままの場合があります。

つまり、

「リモートは先に進んでいる」

ことを確認できる状態です。

新人研修では、ここまで細かな内部構造を完全に覚える必要はありません。

まずは、

Fetchしただけでは、自分の作業ファイルが自動的に最新になるとは限らない

という点を覚えてください。

Pullとは

Pullは、リモートリポジトリの変更を取得し、自分の作業側へ取り込む操作です。

方向は、

リモートリポジトリ

↓

ローカル環境

です。

Fetchと似ていますが、Pullは取得した後に自分のブランチへ反映するところまで行います。

新人研修では、

Fetch = 最新情報を取りに行く

Pull = 最新情報を取りに行って、自分にも反映する

と覚えてください。

PullはFetchより便利？

「だったら毎回Pullだけ使えばいいのでは？」

と思うかもしれません。

日常業務ではPullを使う機会が多いでしょう。

ただし、Pullは自分の作業ブランチへ変更を取り込むため、場合によっては競合が発生します。

一方、Fetchはリモートの情報を取得するだけなので、

「まず相手の変更を確認したい」

という場合に使いやすい操作です。

どちらが優れているというより、目的が違います。

EGitでPullする

EGitでは、対象プロジェクトを右クリックして、

Team

↓

Pull

などから実行できます。

また、Pull from Upstreamのような項目が表示される場合もあります。

現在のブランチに追跡先が設定されていれば、対応するリモートブランチから変更を取り込めます。

Pullするときには、現在どのブランチにいるのか確認してください。

違うブランチでPullすると、意図しない変更を取り込む可能性があります。

Pullすると何が起こる？

Pullでは、リモート側の変更を取得し、自分のブランチへ統合します。

たとえば、Aさんが、

LoginService.java

を変更してPushしたとします。

あなたがPullすると、その変更を自分の環境へ取り込めます。

自分が同じ場所を変更していなければ、問題なく反映されることが多いでしょう。

一方、自分も同じ行を変更している場合は、Gitが自動的にどちらを残すべきか判断できないことがあります。

その状態が、

競合

です。

競合とは

競合は英語で、

Conflict

と呼ばれます。

たとえば、AさんとBさんが同じファイルの同じ行を変更したとします。

Aさん

System.out.println("Hello A");

Bさん

System.out.println("Hello B");

どちらの変更を採用するべきでしょうか？

Gitには判断できません。

そこで、

「両方違う変更になっています。人間が判断してください」

という状態になります。

これが競合です。

競合はGitの故障ではありません。

チーム開発では普通に起こり得るものです。

Pull前にはCommitしておく

新人研修で非常に重要な習慣があります。

Pullする前に、自分の作業状態を確認してください。

作業途中の変更が大量に残っている状態でPullすると、状況が分かりにくくなることがあります。

基本的には、

自分の作業を一区切りつける

↓

差分確認

↓

Stage

↓

Commit

↓

Pull

という流れにすると整理しやすくなります。

もちろん、実務では作業途中にPullが必要になる場面もあります。

その場合はStashなど別の方法を使うこともありますが、新人研修ではまず、

「Pull前に自分の変更状態を確認する」

という習慣をつけてください。

Pull前に保存する

Eclipseで編集しているファイルは、Pull前に保存しておきましょう。

未保存の状態が残っていると、

「Eclipse上では変更したつもりなのに、Gitからはまだ見えていない」

という状態になることがあります。

作業前後にCtrl + Sで保存する癖をつけておくと安全です。

また、Git Stagingビューを確認して、未Commitの変更があるかどうかも確認してください。

Fetch・Pull・Pushの違いを整理しよう

ここで3つを整理します。

Fetch

リモートリポジトリの最新情報を取得する

自分の作業ブランチにはすぐ反映しない

Pull

リモートリポジトリの変更を取得する

自分の作業ブランチへ取り込む

Push

自分のローカルリポジトリにあるCommitをリモートリポジトリへ送る

方向で覚えると簡単です。

FetchとPullは、

リモート

↓

自分

Pushは、

自分

↓

リモート

です。

PushとPullを郵便でたとえる

Fetch・Pull・Pushが混乱する場合は、郵便で考えてみましょう。

Fetchは、

郵便受けを確認して、新しい手紙が届いていることを確認する

イメージです。

Pullは、

郵便受けから手紙を取り出し、自分の机まで持ってきて内容を反映する

イメージです。

Pushは、

自分が書いた手紙を郵便ポストへ出す

イメージです。

この3つの方向を覚えておくと、操作を間違えにくくなります。

originとは

FetchやPull、Pushを操作すると、

origin

という名前が頻繁に出てきます。

originは、多くの場合、Clone元のリモートリポジトリにつけられる名前です。

たとえば、

https://example.com/team/sample.git

からCloneした場合、この接続先がoriginとして登録されていることがあります。

originはリモートリポジトリそのものではなく、

「そのリモート接続先につけた名前」

です。

スマートフォンの電話帳で、

090-XXXX-XXXX

という番号に、

研修担当者

という名前を付けるようなイメージです。

Gitでは長いURLを毎回書かずに、

origin

という短い名前で扱えます。

origin/mainとは

Gitを使っていると、

origin/main

という表記を見かけることがあります。

originはリモート名。

mainはブランチ名です。

つまり、

origin/main

は、

「originというリモートにあるmainブランチを追跡するための情報」

だと考えてください。

自分のローカルにある、

main

とは別の情報です。

新人研修では、

main = 自分が作業しているローカルブランチ

origin/main = リモート側mainの状態を表す情報

という違いを軽く理解しておけば十分です。

作業開始時にPullすればいい？

チーム開発では、作業開始時にリモートの最新状態を確認する習慣が重要です。

たとえば、前日に自分が退社したあと、別のメンバーがPushしている可能性があります。

古い状態のまま作業を始めると、後から変更がぶつかりやすくなります。

そのため、

作業ブランチを確認する

↓

リモートの更新を確認する

↓

必要に応じてPullする

↓

作業を開始する

という流れにすると安全です。

ただし、会社によっては、

「朝は必ずPullする」

「まずFetchして差分を確認する」

など、決められたルールがある場合があります。

チームのルールを優先してください。

作業終了時にPushすればいい？

Pushするタイミングも、会社やプロジェクトによって異なります。

毎日終業時にPushするルールもあれば、一定の作業単位が完了したらPushする場合もあります。

新人研修では、

「Commitしたら必ずすぐPush」

と機械的に覚えないようにしてください。

重要なのは、

「リモートへ共有してよい状態になっているか」

です。

たとえば、

・コンパイルエラーが残っている

・テストしていない

・デバッグ用コードが残っている

・まだ作業途中

という状態なら、そのまま共有してよいかプロジェクトルールを確認する必要があります。

Push前にPullする理由

チーム開発では、Pushする前にリモートの変更を確認することがあります。

理由は、自分が作業している間にほかの人が先にPushしている可能性があるからです。

たとえば、

朝9時にPull

↓

10時から12時まで作業

↓

Commit

と進めたとします。

その2時間の間に別の人がPushしているかもしれません。

そのまま自分がPushすると拒否される場合があります。

そこで、

自分の変更をCommit

↓

リモートの最新状態を確認

↓

必要に応じてPull

↓

問題なければPush

という流れを使います。

Pullしたら競合した場合

Pull時に競合が発生した場合、慌てて適当にファイルを書き換えないでください。

まず、

どのファイルが競合しているか

どの部分が競合しているか

を確認します。

EGitでは、競合したファイルに特別な表示が付いたり、比較画面を使って変更内容を確認したりできます。

新人研修では、競合を1人で無理に解消する必要はありません。

特に実務では、

「なぜ相手がその変更をしたのか」

を確認する必要があります。

勝手に相手の変更を消すと、不具合につながる可能性があります。

競合したら、まず先輩や変更したメンバーへ相談しましょう。

Pushした後に確認する

Pushが成功したら、それで終わりではありません。

EGitの画面やリモートリポジトリの管理画面などで、

「意図したCommitがPushされたか」

を確認すると安心です。

会社のGitホスティングサービスを使っている場合は、ブラウザでCommit履歴を確認できることもあります。

確認したいのは、

・正しいブランチへPushしたか

・自分のCommitが表示されているか

・余計なCommitが入っていないか

です。

Pushはチームへ共有する操作なので、共有後の確認も習慣にしましょう。

PushしたCommitを簡単に消そうとしない

Pushした後に、

「Commit Messageを間違えた」

「小さなミスがあった」

と気づくこともあります。

このとき、過去のCommitを無理に消そうとしないでください。

ローカルだけのCommitと違い、すでにPushした履歴はほかのメンバーが取得している可能性があります。

履歴を書き換えると、チーム全体に影響する場合があります。

新人研修では、

Push後の履歴変更は自己判断で行わない

と覚えておくと安全です。

必要なら、新しいCommitで修正する方法などを先輩に確認してください。

Pullしたら見覚えのないファイルが増えた

Pull後に、自分が作成していないファイルが増えることがあります。

これは異常とは限りません。

ほかのメンバーが新しいファイルを追加してPushしていれば、Pullしたときにそのファイルも取得されます。

たとえば、Aさんが、

LoginValidator.java

を新しく追加してPushしたとします。

あなたがPullすれば、自分のプロジェクトにもLoginValidator.javaが追加されます。

Gitはチームの変更を共有するための仕組みなので、自然な動作です。

Pull後にプログラムが動かなくなったら

Pullしたあとでコンパイルエラーが出たり、プログラムが動かなくなったりすることもあります。

その原因が必ずしもPullの失敗とは限りません。

たとえば、

・新しいライブラリが追加された

・設定ファイルが変更された

・データベース設定が変わった

・別のメンバーの変更に追加作業が必要

などの可能性があります。

まずPullの結果を確認し、どのCommitが取り込まれたのかを確認してください。

原因が分からない場合は、変更したメンバーや先輩へ確認しましょう。

新人が覚える基本的な1日の流れ

ここまで学んだ内容を、実際の作業の流れとしてつなげてみましょう。

作業開始

↓

現在のブランチを確認する

↓

リモートの最新状態を確認する

↓

必要に応じてPullする

↓

ソースコードを編集する

↓

保存する

↓

動作確認する

↓

Git Stagingで差分を確認する

↓

Stageする

↓

Commitする

↓

リモート側の更新を確認する

↓

必要に応じてPullする

↓

Pushする

この一連の流れが、新人研修で最も身につけてほしい部分です。

Clone・Pull・Pushを混同しない

ここまで学んだ操作を整理すると、

Clone

最初にリモートリポジトリを自分のパソコンへ複製する

Pull

Clone済みのリポジトリへ新しい変更を取り込む

Push

自分のCommitをリモートへ送る

となります。

毎日Cloneする必要はありません。

最初にCloneして、その後はPullとPushを使ってチームと変更をやり取りします。

この違いを説明できるようになってください。

新人がやってはいけない操作

この章では、リモートリポジトリへ影響する操作を扱いました。

新人研修では、特に次の操作を自己判断で行わないようにしましょう。

・Force Pushする

・Push済みの履歴を書き換える

・よく分からない競合を適当に解消する

・Pushできないから設定を大量に変更する

・リモートブランチを勝手に削除する

・認証情報をソースコードへ書く

Gitは便利ですが、共有リポジトリへの操作はチーム全体へ影響する可能性があります。

分からない場合は、まず状態を確認してください。

そして、必要なら相談しましょう。

Pushが失敗したときの確認順序

Pushが失敗した場合は、次の順番で確認すると整理しやすくなります。

エラーメッセージを読む
正しいブランチか確認する
リモート側に新しい変更がないか確認する
認証エラーではないか確認する
Pullなどが必要か確認する
分からなければ先輩へ相談する

重要なのは、

「エラーが出たから、とりあえずいろいろ押す」

としないことです。

エラーメッセージには原因を判断するための情報が含まれています。

Pull前後の状態を確認する

Pullを行う場合も、操作前後を確認してください。

Pull前

・現在のブランチ

・未Commitの変更

・ローカルの最新Commit

Pull後

・新しいCommitが取り込まれたか

・競合が発生していないか

・プロジェクトにエラーが出ていないか

・プログラムが動作するか

ボタンを押すだけではなく、

「何が変わったのか」

を確認する習慣が重要です。

新人研修で最低限覚える4操作

ここまでの記事では多くのGit用語を扱ってきました。

ただし、日常業務で最初に使えるようになってほしいのは、主に次の4つです。

Clone

最初にリポジトリを取得する

Commit

自分の変更をローカルへ記録する

Pull

ほかのメンバーの変更を取り込む

Push

自分の変更を共有する

さらに、

Stage

を加えれば、

Clone

↓

編集

↓

Stage

↓

Commit

↓

Pull

↓

Push

という基本的なGit作業を行えるようになります。

新人研修では、まずこの流れを迷わず実行できる状態を目指してください。

第8章のまとめ

この章では、EGitを使ってリモートリポジトリと変更をやり取りする方法を説明しました。

Fetchは、

リモートリポジトリの最新情報を取得する操作

です。

Pullは、

リモートリポジトリの変更を取得し、自分の作業ブランチへ取り込む操作

です。

Pushは、

自分のローカルリポジトリにあるCommitをリモートリポジトリへ送る操作

です。

方向で考えると覚えやすくなります。

Fetch・Pull

リモート

↓

自分

Push

自分

↓

リモート

特に重要なのは、

CommitとPushは別

という点です。

Commitしただけでは、自分のローカルリポジトリに記録されただけです。

チームへ共有するにはPushが必要です。

また、Pushが拒否された場合は、Force Pushで無理に解決しないでください。

リモート側に自分が持っていない変更がある可能性があります。

まず状況を確認し、必要に応じてPullしてからPushします。

ここまでできれば、

Clone

↓

編集

↓

差分確認

↓

Stage

↓

Commit

↓

Pull

↓

Push

という、新人が最初に覚えるべきGitの基本操作を一通り実行できます。

次の章では、この一連の操作を新人の1日の作業フローとして整理します。

「出社してから何を確認するのか」「修正後に何を確認してからPushするのか」「トラブルが起きたらどこで止まるのか」をまとめ、研修後に迷わず実務へ移れる状態を目指しましょう！

第9章 EGitを使った新人の1日の作業フロー｜Clone・Pull・Commit・Pushを実務の流れで確認しよう

ここまでの章では、EGitを使った基本操作を一つずつ説明してきました。

Clone

Stage

Commit

Fetch

Pull

Push

といった操作を個別に理解できても、実際の業務では、

「結局、どの順番で操作すればいいの？」

と迷うことがあります。

そこで最後の章では、新人が1日の開発作業を進める流れに沿って、EGitの操作を整理します。

新人研修では、すべてのGit機能を覚えることより、

「作業開始からPushまでを、正しい順番で進められる」

ことの方が重要です。

まずは、1日の基本的な流れを確認しましょう。

新人が覚えたい1日の基本フロー

基本的な作業の流れは、次のようになります。

作業を開始する

↓

現在のブランチを確認する

↓

リモートの最新状態を確認する

↓

必要に応じてPullする

↓

ソースコードを修正する

↓

ファイルを保存する

↓

動作確認する

↓

Git Stagingビューで差分を確認する

↓

必要な変更をStageする

↓

Commit Messageを書く

↓

Commitする

↓

Push前にリモートの状態を確認する

↓

必要に応じてPullする

↓

Pushする

↓

Push結果を確認する

一見すると長く感じるかもしれません。

しかし、実際に何度か繰り返すと自然な流れになります。

車を運転するときも、

シートベルトを締める

↓

ミラーを見る

↓

エンジンをかける

↓

周囲を確認する

↓

発進する

という一連の動作がありますよね。

慣れると意識せずできるようになります。

Gitも同じです。

最初のうちは順番を確認しながら操作してください。

作業開始前にブランチを確認する

まず、作業を始める前に現在のブランチを確認します。

Gitでは、同じリポジトリの中でも複数のブランチが存在する場合があります。

たとえば、

main

develop

feature/login

などです。

会社によっては、

「この作業はfeature/loginで行ってください」

と指定されることがあります。

その場合、別のブランチで作業を始めてはいけません。

作業内容は正しくても、変更する場所が間違ってしまいます。

なぜ最初にブランチを確認するの？

たとえば、学校で数学の宿題をするとします。

ところが、間違えて英語のノートへ数学の問題を書いてしまったらどうでしょう。

答えが正しくても、提出するときに困りますよね。

Gitのブランチも似ています。

正しいコードを書いていても、作業するブランチを間違えると後から整理が必要になります。

そのため、作業開始時には、

「今どのブランチにいるのか」

を確認する習慣をつけてください。

ブランチはどこで確認する？

EGitでは、Git Repositoriesビューなどから現在のブランチを確認できます。

Package Explorerのプロジェクト名付近にブランチ名が表示される設定になっている場合もあります。

表示方法はEclipseやEGitの設定によって異なることがあります。

新人研修では、

「作業開始前に現在のブランチを確認する」

ことを習慣にする方が重要です。

ブランチの作成や細かな切り替え方法については、研修担当者やプロジェクトのルールに従ってください。

次にリモートの最新状態を確認する

正しいブランチであることを確認したら、リモートリポジトリの最新状態を確認します。

なぜ作業開始前に確認するのでしょうか？

自分が作業していない間にも、ほかのメンバーが開発を進めている可能性があるからです。

たとえば、前日の18時に仕事を終えたとします。

そのあと、別のメンバーが19時に変更をPushしたかもしれません。

翌朝、自分の環境だけ昨日の状態のまま作業を始めると、古いソースコードを基準に修正することになります。

そこで、作業開始時にはリモートの状態を確認します。

Pullする前に自分の変更が残っていないか確認する

リモートの最新状態を取り込む前に、自分の作業状態を確認してください。

Git Stagingビューを開いて、

Unstaged Changes

Staged Changes

にファイルが残っていないか確認します。

前日の作業途中の変更が残っているかもしれません。

その状態で何も考えずPullすると、状況が複雑になる場合があります。

たとえば、

「昨日どこまで自分が変更したのか」

「Pullで何が変わったのか」

が分からなくなる可能性があります。

新人研修では、

「Pullする前にGit Stagingを見る」

という習慣をつけるとよいでしょう。

必要に応じてPullする

自分の作業状態を確認したら、必要に応じてPullします。

Pullは、

リモートリポジトリ

↓

自分のローカル環境

へ変更を取り込む操作です。

前章で説明したとおり、Pullするとリモート側の変更を取得し、自分のブランチへ反映します。

作業開始時にPullしておけば、なるべく新しい状態から開発を始められます。

ただし、会社によっては、

「最初にFetchして状態を確認してからPullする」

などのルールがある場合もあります。

プロジェクトのルールを優先してください。

Pullが成功したか確認する

Pullボタンを押したら、それで終わりではありません。

結果を確認してください。

確認したいのは、

・正常にPullできたか

・新しいCommitが取り込まれたか

・競合が発生していないか

・Eclipseにエラーが発生していないか

です。

特に競合が発生した場合、そのまま作業を続けないでください。

状態を確認し、分からなければ先輩や研修担当者へ相談しましょう。

Gitでは、

「操作した後に結果を確認する」

ことが非常に重要です。

ソースコードを修正したら保存する

修正が終わったら、ファイルを保存します。

Eclipseでは、

Ctrl + S

などで保存できます。

何度も説明してきましたが、

保存

と

Commit

は別の操作です。

保存しただけではGitの履歴にはなりません。

まずファイルの現在内容がパソコンに保存されます。

その変更をGitの履歴として残すには、StageとCommitが必要です。

動作確認をする

Commitする前には、変更したプログラムが正しく動くか確認します。

たとえば、

・コンパイルエラーがないか

・対象機能が正常に動作するか

・想定したエラーメッセージが表示されるか

・既存機能が壊れていないか

などを確認します。

会社によっては、自動テストや単体テストを実行するルールがある場合もあります。

ここで覚えておいてほしいのは、

Gitはプログラムの正しさを確認してくれない

ということです。

Gitは変更履歴を記録します。

間違ったコードでもCommitできます。

そのため、Commitする前の動作確認は開発者自身が行います。

Git Stagingビューで変更を確認する

動作確認が終わったら、Git Stagingビューを開きます。

Unstaged Changesに、今回変更したファイルが表示されます。

ここで、

「自分が変更したファイルだけが表示されているか」

を確認してください。

たとえば、1ファイルしか変更したつもりがないのに、

20ファイル

表示されていたらどうでしょう。

何か意図しない変更が発生している可能性があります。

そのまま全部Stageしてはいけません。

まず原因を確認します。

差分を見る

Commit前には、必ず差分を確認しましょう。

差分を見ると、

変更前

↓

変更後

で、何が変わったのか確認できます。

たとえば、

if (userName == null)

という条件を、

if (userName == null || userName.isEmpty())

へ変更したとします。

差分を見ることで、

「本当にこの変更だけなのか」

を確認できます。

また、

System.out.println("debug");

などのデバッグ用コードが残っていないかも確認できます。

意図しない変更があったら止まる

差分を確認して、

「こんな変更をした覚えがない」

という箇所が見つかった場合は、そのままCommitしないでください。

原因として、

・自動フォーマットが実行された

・改行コードが変わった

・Eclipseの設定ファイルが更新された

・ビルドで自動生成ファイルが変わった

などが考えられます。

新人研修では、

「分からない変更を、そのままCommitしない」

ことが非常に重要です。

何が起きたのか分からない場合は、研修担当者へ確認しましょう。

必要な変更だけStageする

差分を確認して問題なければ、今回Commitしたい変更をStageします。

Unstaged Changes

↓

Staged Changes

へ移動します。

変更されたファイルが複数ある場合は、それぞれ今回のCommitに必要か確認してください。

たとえば、

LoginService.java

LoginController.java

README.md

を変更していたとします。

LoginService.javaとLoginController.javaはログイン機能の修正です。

README.mdは別件の誤字修正です。

その場合、Commitを分けることを検討します。

Staged Changesをもう一度見る

Stageしたら、

Staged Changes

を確認します。

新人のうちは、Stageした時点で安心してしまいがちです。

しかし、最後にもう一度確認しましょう。

確認する内容は、

・必要なファイルが入っているか

・不要なファイルが入っていないか

・変更内容が正しいか

です。

Stageは、

「次のCommitに何を入れるか」

を決める操作です。

つまり、Staged Changesの内容がそのままCommitの中身になります。

提出用の封筒に何を入れたのか、封をする前に確認するようなものです。

Commit Messageを書く

次にCommit Messageを書きます。

Commit Messageには、

「何を変更したのか」

が分かる内容を書いてください。

悪い例

修正

悪い例

対応

悪い例

作業

良い例

ログイン時のユーザー名未入力チェックを追加

良い例

商品検索条件にカテゴリ指定を追加

良い例

会員登録時のメール形式チェックを修正

会社によって書き方が決められている場合は、そのルールに従います。

Commitする

内容を確認したらCommitします。

Commitした時点で、変更がローカルリポジトリへ記録されます。

ここで一度、

History

を確認してみてもよいでしょう。

自分が作ったCommitが履歴として表示されます。

Commit Messageや変更内容が正しいか確認してください。

新人のうちは、

CommitしたらHistoryで確認する

という流れを何度か繰り返すと、Gitの仕組みを理解しやすくなります。

Commit後にすぐPushしていい？

Commitが終わると、

「次はPush！」

と思うかもしれません。

しかし、Push前に一度リモートの状態を確認した方が安全です。

なぜなら、自分が作業している間に、ほかのメンバーがPushしている可能性があるからです。

たとえば、

9時にPull

↓

9時30分から11時まで作業

↓

11時にCommit

という流れだったとします。

その1時間30分の間に、別のメンバーがPushしているかもしれません。

そのため、自分のPush前にリモート側の最新状態を確認します。

Fetchでリモートの状態を確認する

Push前にリモートの状況を確認したい場合、Fetchを使う方法があります。

Fetchは、リモートリポジトリの最新情報を取得します。

自分の作業ブランチへすぐ取り込むわけではありません。

そのため、

「リモート側が更新されているか」

を確認したい場面で役立ちます。

新人研修では、

Push前に必ずFetchしなければならない

と覚える必要はありません。

会社やチームの運用に従ってください。

重要なのは、

「Pushする前に、リモート側が変わっている可能性を考える」

ことです。

リモートが進んでいたらPullする

リモート側に新しい変更がある場合は、必要に応じてPullします。

Pullすると、

ほかのメンバーの変更

と

自分の変更

を同じブランチ上で統合します。

問題なく統合できれば、そのまま次へ進めます。

しかし、同じ箇所を変更していると競合が発生する場合があります。

競合したら勝手に相手の変更を消さない

競合が発生した場合、Gitは、

「どちらの変更を残せばよいか判断できません」

と伝えています。

そのため、

「自分のコードが正しいはず」

と判断して、相手の変更を全部消してはいけません。

相手が変更した理由があるかもしれません。

たとえば、

自分

ログインエラー時は画面Aへ移動

相手

ログインエラー時は画面Bへ移動

という変更が競合したとします。

どちらが正しいかはGitには分かりません。

仕様を確認する必要があります。

新人研修では、競合が起きたら、

「勝手に直さず、まず確認する」

と覚えておきましょう。

問題がなければPushする

リモートの状態を確認し、必要な変更が取り込まれ、問題がなければPushします。

Pushすると、

ローカルリポジトリ

↓

リモートリポジトリ

へ自分のCommitが送られます。

ここで初めて、チームメンバーが自分の変更を取得できる状態になります。

Commit

と

Push

は別の操作です。

最後まで意識してください。

Push結果を確認する

Pushを実行したら、成功したか確認します。

EGitにはPush結果が表示されます。

成功している場合は、リモート側へCommitが送られています。

失敗した場合は、エラーメッセージを確認してください。

よくある原因として、

・リモート側が先に進んでいる

・認証に失敗した

・Pushする権限がない

・対象ブランチへのPushが禁止されている

・ネットワークに接続できていない

などがあります。

「失敗したからもう一度押す」

だけでは解決しない場合があります。

まず原因を読み取りましょう。

リモート側でも確認する

会社でGitHubやGitLabなどのGitホスティングサービスを利用している場合は、Push後にWeb画面から確認できる場合があります。

たとえば、

・自分のCommitが表示されているか

・正しいブランチへPushされているか

・Commit Messageが正しいか

などを確認できます。

新人研修では、

「Pushボタンを押して終わり」

ではなく、

「正しく共有されたことを確認する」

ところまでを作業と考えてください。

変更後にレビューを依頼する場合

実務では、Pushしたらそのまま本番環境へ反映されるとは限りません。

多くの開発現場では、

コードレビュー

という作業があります。

コードレビューとは、

自分が書いたコードを、ほかの開発者に確認してもらうこと

です。

たとえば、

・処理内容が正しいか

・読みやすいコードか

・不具合が入り込んでいないか

・プロジェクトのルールを守っているか

などを確認してもらいます。

GitHubやGitLabなどでは、Pull RequestやMerge Requestといった仕組みを使う場合があります。

新人研修では詳細まで覚えなくても構いません。

まずは、

「Pushした後にレビューがある場合もある」

と理解しておきましょう。

レビューで修正を指摘されたらどうする？

レビューで、

「この処理を修正してください」

と指摘されることもあります。

その場合は、新しく変更を加えます。

基本的には、

ソースコードを修正

↓

保存

↓

動作確認

↓

差分確認

↓

Stage

↓

Commit

↓

Push

という流れをもう一度行います。

最初のCommitを無理に消す必要はありません。

会社の運用によってはCommitをまとめる場合もありますが、新人のうちは自己判断で履歴を書き換えない方が安全です。

1日の終わりに確認したいこと

作業を終了する前に、自分のGit状態を確認しておきましょう。

Git Stagingビューを開いて、

Unstaged Changes

Staged Changes

を確認します。

もしファイルが残っている場合は、

「この変更は何だろう？」

と確認してください。

作業途中の変更なら、翌日にどうするか考えます。

意図しない変更なら、そのまま放置しない方がよいでしょう。

また、作業途中の状態をどう扱うかは会社によってルールが異なります。

勝手にCommitやPushせず、必要なら先輩へ相談してください。

作業途中だから適当にCommitしていい？

退勤時間になったから、

途中

作業中

仮

といったCommit MessageでとりあえずCommitしたくなることもあるでしょう。

しかし、共有されるGit履歴として適切かどうかはプロジェクトの運用によります。

作業途中のCommitを許可しているチームもあれば、一定の完成状態でCommitするルールのチームもあります。

「退勤時間だから何でもCommitする」

と機械的に考えないでください。

会社やチームのルールに従いましょう。

PushしていないCommitがあるか確認する

Commitはしたものの、Pushしていない状態で作業を終了する場合もあります。

必ずしも問題ではありません。

Commitは自分のローカルリポジトリに保存されています。

ただし、

「Pushする予定だったのに忘れている」

可能性もあります。

作業終了時には、

・Commit済みか

・Push済みか

・作業途中なのか

を自分で把握できる状態にしておきましょう。

「現在の状態が分かる」ことが重要

Gitを安全に使うために最も大切なのは、

「今、自分のリポジトリがどの状態なのか」

を把握することです。

たとえば、

未保存の変更がある

保存したがStageしていない

StageしたがCommitしていない

CommitしたがPushしていない

Pushまで完了している

という状態があります。

新人のうちは、

「ボタンを押す方法」

ばかり覚えがちです。

しかし、本当に重要なのは、

「今どの状態で、次に何をすべきか判断できること」

です。

困ったらGit Stagingを見る

EGitを使っていて、

「今どうなっているのか分からない」

と思ったら、まずGit Stagingビューを確認してください。

Unstaged Changesにファイルがある

↓

変更したがStageしていない

Staged Changesにファイルがある

↓

StageしたがCommitしていない

どちらも空

↓

少なくとも未Commitの変更は見当たらない

という判断ができます。

そのうえでHistoryを見れば、

「どこまでCommitされているか」

も確認できます。

さらにGit Repositoriesビューを見ると、

ブランチやリモートの状態を確認できます。

困ったときこそ、現在の状態を確認してください。

エラーが出たらメッセージを読む

Gitでエラーが発生すると、英語のメッセージが表示されることがあります。

英語を見ると、

「よく分からないから閉じよう」

と思ってしまうかもしれません。

しかし、エラーメッセージには重要な情報があります。

たとえば、

Authentication failed

なら認証関連の問題です。

non-fast-forward

ならリモート側の履歴が先に進んでいる可能性があります。

Conflict

なら競合です。

全文を理解できなくても構いません。

まずキーワードを確認してください。

エラー画面を消す前に記録する

新人研修でおすすめしたい習慣があります。

エラーが出たら、画面を閉じる前に記録してください。

たとえば、

・エラーメッセージをコピーする

・スクリーンショットを取る

・どの操作をしたときに出たかメモする

などです。

先輩へ、

「なんかエラーが出ました」

と相談するより、

「Pushしたところ、non-fast-forwardと表示されました」

と伝えた方が原因を調べやすくなります。

エラー情報も大切な手がかりです。

分からないまま操作を続けない

Gitでは、分からない状態で操作を続けると状況が複雑になる場合があります。

たとえば、

Pushできない

↓

適当にPullする

↓

競合した

↓

よく分からないのでResetする

↓

直らないのでForce Pushする

という流れになったら危険です。

最初のPush失敗時点で止まって原因を確認すれば、簡単に解決できたかもしれません。

新人のうちは、

「分からなくなったら止まる」

ことも重要なスキルです。

新人が自己判断で避けたい操作

基本操作に慣れるまでは、次のような操作を自己判断で使わない方が安全です。

Force Push

リモートの履歴を書き換える可能性があります。

Reset

指定方法によっては、自分の変更を失う可能性があります。

Rebase

Commit履歴を書き換える操作が含まれます。

Push済みCommitのAmend

共有済み履歴を変更する問題につながる場合があります。

リモートブランチの削除

チームメンバーへ影響する可能性があります。

これらの機能が悪いわけではありません。

Gitを使いこなすうえでは便利な機能です。

ただし、

「何が起きるか分からない状態」

で実行するのが危険なのです。

Gitで失敗したら終わり？

Git初心者は、

「変な操作をしたら全部壊れてしまうのでは？」

と不安に感じるかもしれません。

Gitは変更履歴を管理する仕組みなので、正しい手順を使えば復旧できるケースも多くあります。

ただし、

「戻せるかもしれないから適当に操作していい」

という意味ではありません。

特にリモートへ共有した履歴は、ほかのメンバーにも影響します。

問題が起きたときは、

現在の状態を確認

↓

エラーメッセージを記録

↓

勝手に追加操作しない

↓

必要に応じて相談

という流れを意識してください。

新人研修で覚える最小セット

ここまで9章にわたってEGitを説明してきました。

機能はたくさんありますが、新人研修でまず覚えてほしい操作は、それほど多くありません。

Clone

既存のリモートリポジトリを自分のパソコンへ取得する

Pull

リモートの変更を自分の環境へ取り込む

差分確認

自分が何を変更したのか確認する

Stage

次のCommitに入れる変更を選ぶ

Commit

変更をローカルリポジトリへ記録する

Push

Commitをリモートリポジトリへ共有する

この6つが基本です。

さらに、

現在のブランチを確認する

という習慣を加えれば、日常作業の基本形が見えてきます。

新人が覚える合言葉

操作に迷ったら、次の順番を思い出してください。

確認

↓

更新

↓

修正

↓

確認

↓

記録

↓

Gitの言葉へ置き換えると、

ブランチ確認

↓

Pull

↓

編集

↓

Diff

↓

Stage

↓

Commit

↓

Push

です。

非常に大切な流れなので、何度も練習してください。

作業開始からPushまでの実践例

最後に、具体的な作業例を見てみましょう。

あなたは、

「ログイン画面でパスワードが未入力の場合にエラーを表示する」

という修正を担当したとします。

まず、Eclipseを開きます。

現在のブランチを確認します。

研修担当者から指定されたブランチになっていることを確認します。

次に、Git Stagingビューを確認します。

前回の未Commit変更がないことを確認します。

リモートの状態を確認し、必要に応じてPullします。

Pull後に競合やエラーがないことを確認します。

LoginService.javaを開き、未入力チェックを追加します。

ファイルを保存します。

プログラムを実行し、

パスワード未入力時に正しくエラーが出る

ことを確認します。

Git Stagingビューを開きます。

LoginService.javaがUnstaged Changesに表示されています。

差分を確認します。

デバッグコードなど、余計な変更が入っていないことを確認します。

LoginService.javaをStageします。

Staged Changesを確認します。

Commit Messageに、

ログイン時のパスワード未入力チェックを追加

と入力します。

Commitします。

Historyを確認し、自分のCommitが作成されていることを確認します。

Push前にリモート側の変更を確認します。

問題がなければPushします。

Pushが成功したことを確認します。

これで一連の作業が完了です。

新人研修では速さより確認を優先する

最初のうちは、EGitの操作に時間がかかっても問題ありません。

むしろ、

「何をしているのか分からないまま素早く操作する」

より、

「意味を理解しながら一つずつ確認する」

方が重要です。

Git操作は慣れれば自然に速くなります。

まずは、

どのブランチにいるのか

何を変更したのか

何をStageしたのか

何をCommitしたのか

どこまでPushしたのか

を把握してください。

第9章のまとめ

新人研修でのEGit学習では、すべての機能を覚える必要はありません。

最初に身につけたいのは、日常業務の基本サイクルです。

作業開始時には、

現在のブランチを確認

↓

リモートの最新状態を確認

↓

必要に応じてPull

します。

開発中は、

編集

↓

保存

↓

動作確認

↓

差分確認

↓

Stage

↓

Commit

という流れを守ります。

作業を共有するときは、

リモートの状態を確認

↓

必要に応じてPull

↓

Push

↓

結果確認

と進めます。

特に新人のうちは、

「分からない変更をCommitしない」

「分からないエラーが出た状態で操作を続けない」

「Force Pushなどの強い操作を自己判断で使わない」

ことを意識してください。

EGitは、ボタンの位置を暗記するだけでは使いこなせません。

重要なのは、

「今、自分がGitのどの状態にいるのか」

を考えながら操作することです。

まずは小さな研修用プロジェクトで、

Clone

↓

Pull

↓

編集

↓

Diff

↓

Stage

↓

Commit

↓

Push

という流れを何度も繰り返してください。

基本操作を迷わず実行できるようになったら、次の学習として、

ブランチの作成と切り替え

マージ

競合の解消

Stash

Revert

Reset

Rebase

などへ進むとよいでしょう。

最初から高度な機能を覚える必要はありません。

まずは「変更を確認し、安全に記録し、安全に共有する」というGitの基本を身につけてください！

セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
海外放浪の末、2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。