GitHub Eclipseによるリポジトリの基本操作

— y2sunlight 2020-06-19

GitHub に戻る

本章は、リポジトリの基本的な操作について GitHubガイドに掲載されているHelloWorldに従って説明を進めます。本章を完了するには、GitHubのアカウントと以下のクライアント環境が必要です。GitクライアントにはEclipseを使用します。

クライアント環境

• Windows10 Pro
• Eclipse 2019-12 Version 4.14

関連記事

• GitHub 環境構築
• GitHub メールの設定
• GitHub プロフィールの設定
• GitHub Eclipseによるリポジトリの基本操作
• GitHub Eclipseによるブランチの操作
• GitHub タグとリリースの作成
• GitHub コラボレータの招待
• GitHub ソースコードの公開

リンク

• https://github.com/ — GitHubの本家
• https://guides.github.com/ — GitHubガイド
• Hello World — GitHubガイドより
• Mastering Markdown — GitHubガイドより
• リポジトリの作成、クローン、アーカイブ — GitHubヘルプより

GitHub

• y2sunlight/hello-world — 本章の例題はGitHubで公開しています

以下では、GitHubガイドのHelloWorldに従って説明を進めます。HelloWorldは、README.mdを編集するだけの簡単な例題ですが、GitHubの基本的なワークフローを理解する上では十分なものです。

まず最初に、新しいリポジト( hello-world )作ります。GitHubでは、リポジトリ作成直後は、デフォルトでmasterブランチが作成されます。そして、README.md編集用の作業ブランチ( readme-edits )を追加します。README.md の編集作業はこのブランチで行います。作業終了後に、作業ブランチをプッシュして、プルリクエストを開きコードの変更をレビュワー(ここではリポジトリのオーナー)に通知します。レビューが終わると、レビュワーは readme-edits ブランチを master ブランチにマージします。

このように、GitHubでは開発者とレビュワーの日常的な作業単位は以下のようになります：

• 開発者

  1. 作業用のブランチ作成
  2. コード編集（コミット）
  3. プッシュ
  4. プルリクエスト

• レビュワー

  1. プルリクエストのレビュー
  2. 必要に応じてレビュー内容のフィードバック

     • 開発者は必要に応じて、コード編集・プッシュ・プルリクエストを繰り返す
  3. レビューOKなら、作業用ブランチを master にマージ

この流れは、GitHub Flowと呼ばれ、GitHubでのワークフローモデルになっています。

尚、上述したように本章では、GitクライアントにはEclipseを使用します。

参考リンク

• GitHubフロー — GitHubヘルプより
• GitHubフローを理解する — GitHubガイドより
• GitHub Flow — Scott Chacon on the Interwebs
• GitHub Flow — Scott Chacon on the Interwebs(邦訳)
  Scott Chacon(スコット・チャコン氏)はGitのエバンジェリストでGitHubのスタートに携わった人物

画面右上の[+]メニューから[New repository]を選択して下さい。

■ 必要な項目を入力します。

• [Repository name] — リポジトリ名(ここでは hello-world ) を入力します。
• [Description] — 短い説明文を入力できます。
• [Public]/[Private] — Publicを選択するとリポジトリがインターネットに公開されます。
• [Initialize this repository with a README] — READMEでこのリポジトリを初期化します。
  本章ではこれをチェックして下さい。
• [その他] — .gitignoreやライセンスのテンプレートを追加することもできます。

■ [Create]ボタンを押して下さい。

■ リポジトリを作成すると上画面が表示されます。

リポジトリ hello-world に移動します。まだ表示していない場合は、ダッシュボードの左サイドバーから hello-world を選択して下さい。

■ ファイルリスト上部のドロップダウン[branch：master] をクリックします。
■ テキストボックスに 新しいブランチのブランチ名 readme-edits を入力します。
■ [Branches]内の[Create branch: readme-edits from 'master']を選択して下さい。

■ 新しいブランチを作成すると上画面が表示されます。

ブランチの作成はEclipseからでもできます。後述の「Eclipseからブランチを作る」を参照して下さい。

本章は GitHubガイドのHelloWorldと異なり、ローカル環境のGitクライアントで操作します。また、

以下では、GitHubで公開されているリポジトリ( hello-world ) の ブランチ( readme-edits )をインポートして Eclipseで編集できるようにします。EclipseではGitの使い方については本編の「Eclipse EGit プラグイン」を参照して下さい。

ここではワークスペースとして D:\\usr\workspace\github を使用し、以下のフォルダをプロジェクトフォルダに指定します。

D:\\usr\workspace\github\hello-world

Eclipseを起動して、メニューから[ファイル][インポート]を選択します。

■ [Git][Gitプロジェクト]を選択し、[次へ]を押します。

■ [クローンURI]を選択し、[次へ]を押します。

■ [URI]を入力します（ここでは https://github.com/y2sunlight/hello-world.git を入力しています）。

リポジトリのURLは、リポジトリ hello-world の画面で、ファイルリスト右上の[Clone]ボタンを押すと表示できます。

URL横のアイコンを押すとクリップボードにコピーできます。

■ URIを入力するとそれに応じて他の項目は自動で表示されます。
■ hello-worldは公開リポジトリなので、[認証]欄は空欄のままです。
（但し、プッシュ時には必要になります）
■ [次へ]を押します。

■ ブランチ master と readme-edits の両方にチェックを入れます。
■ [次へ]を押します。

■ ローカルリポジトリの保存先にはワークスペース下のプロジェクトフォルダを指定します。
ここでは D:\usr\workspace\github\hello-world を指定します。
■ 初期ブランチに readme-edits を選択します。
■ リモート名は origin（デフォルト値）のままで良いです。
■ [次へ]を押します。

■ [新規プロジェクト・ウイザードを使用してインポート]を選択して、[完了]を押します。

■ [PHPプロジェクト]を選択して、[次へ]を押します。

■ [プロジェクト名]に hello-world を入力して、[完了]を押します。

■ プロジェクトエクスプローラに以下のファイルが表示されます。

• インポートしたファイル — README.md, LICENSE
• Eclipseのプロジェクトファイル — .setteings/, .buildpath, .project

GitHubからプロジェクトをインポートした後、まず最初にしなければならない事は、コミットメールアドレスの変更です。GitHub用のメールアドレスを設定しないとユーザ共通のメールアドレスが使用されます。ユーザ名の変更は必要に応じて行って下さい。

本編では、基本的にオンプレミスのGitサーバを使用し、公開リポジトリのみGitHubによる運用を想定しています。従って、社内用と公開用でコミットメールアドレスを変更して使用します。コミットメールアドレスに関しては、本編の「メール設定」を参照して下さい。

Eclipse で hello-world リポジトリの設定画面を開きます：

1. メニューの[ウインドウ][設定]を選択
2. 左ペインで[チーム][Git][構成]を選択
3. [構成]の[リポジトリ設定]タブを選択
4. [リポジトリ]で[hello-world]を選択

■ [エントリー追加…]ボタンを押します。

1. ユーザ名を入力して[追加]ボタンを押します。（キー： user.name）
2. メールアドレスを追加します。（キー： user.email）

■ [適用]ボタンを押します。

Eclipseによるプロジェクト内のファイルの編集からコミットまでの手順を説明します。詳しくは、本編の「Eclipse EGit プラグイン」を参照して下さい。

EclipseでGitの操作を行う時は、[Gitステージング]タブを表示します。まだ表示していない場合は、メニューの[ウィンドウ][ビューの表示][その他…]を選択して [Git][Gitステージング]ビューを開いて下さい。

本編ではプロジェクト関連ファイルはリポジトリに保存しない方針なので、これらのファイルをリポジトリ登録から除外します。

[プロジェクト・エクスプローラー]で以下のフォルダまたはファイルを右クリックして、[チーム][無視]を選択して下さい。この時、.gitignore ファイルが無視を行ったフォルダに作られます。

• .setting/
• .buildpath
• .project

README.md を編集します。

■ このファイルはMarkdown形式で書かれています。
■ 編集が終わったら[ファイル][保存]して下さい。

[Gitステージング]タブで編集したファイルをステージングします。

■ .gitignore と README.md を選択し[＋]ボタンを押して[ステージされた変更]に移動します。

■ [コメント・メッセージ]を入力して下さい。
■ [コミット]ボタンを押してローカルリポジトリにコミットします。

公開リポジトリと言えどもプッシュするには認証が必要になります。リポジトリのオーナーには全ての権限があります。また、オーナーはコラボレータを招待して権限を与えることもできます。公開リポジトリで、リポジトリへの書き込みが出来るのはオーナーと権限の与えられたコラボレータ（人またはチーム）だけです。

本編では、GitクライアントからのアクセスにHTTPSを使用します。HTTPSでは、通常、ユーザ名とパスワードで認証しますが、アカウントが2要素認証を使用している場合、パスワードの代わりに「個人用アクセストークン」が必要になります。従って、プッシュの前に、まず個人アクセストークンを作成しなければなりません。

GitHubの画面右上の[アイコン]メニューから[Settings]を選択した後、左サイドバーで[Developer settings]を選択します。

■ [Personal access tokens]を選択します。

■ 右上の[Generate new token]ボタンを選択します。

■ [Note]にトークンの分かり易い名前を入力します。
■ [repo]にチェックを入れ、リポジトリへのフルアクセスを許可します。
■ [Generate token]ボタンを押します。

■ 個人アクセストークンが表示されるので、コピーして大切に保管します。
■ このトークンは、プッシュ時の認証などで使用します。

ページの外に移動すると、再びこのトークンを見ることはできません。
過去1年間使用されていない個人アクセストークンは自動的に削除されます。

ここからはEclipseに戻って操作を行います。[プロジェクト・エクスプローラー]でプロジェクト(hello-world)を右クリックして[チーム][アップストリームへプッシュ]を選択して下さい。

■ ユーザ名と個人アクセストークンを入力します。
■ [セキュア・ストアに保管]をチェックします。
■ [ログイン]ボタンを押して下さい。

ここで入力したログイン情報は保管されるので、以後は認証情報を聞かれる事はありません。また、認証情報に変更があった場合は、プロジェクト名(hello-world)を右クリックし[チーム][リモート][アップストリームからプッシュ構成…]を選び、originのプッシュ構成の[変更]ボタンを押せば、認証情報を変更することができます。尚、この画面をプッシュの前に開いて、予め認証情報を入力しておくこともできます。

■ プッシュ結果が表示されるので内容を確認後、[閉じる]ボタンを押して下さい。

プルリクエストは、共同開発の心臓部ともいえる機能です（この文言はGitHubのヘルプから引用）。これはGitの機能ではなくてGitHubの機能です。プルリクエストは、レビュワーにレビューを依頼してマージの要求を行いますが、まだ作業の途中段階でも、プルリクエストしてディスカッションの場を作ることもできます。プルリクエストメッセージには @メンション を含めることができ、共同開発者がどこに居ようが意見を求めることもできます。尚、プルリクエストは自分自身で開き、そしてマージすることもできます。

筆者は、オンプレミスのSubversionに慣れていたので、初めてGitHubを体験した時、プルリクエストは面倒な作業のように思いました。共同開発者は10タイムゾーンの向こうに居るのではなく、直ぐ隣にいるからです。しかし、よく考えると、GitやSubversionのプライベートリポジトリは今でも私の隣(オンプレミス)にあります。GitHubは公開リポジトリだけの運用にしています。公開リポジトリにマージの履歴や経緯を残してくれるリクエストはやはり大切な存在だったのです。

それでは、実際にプルリクエストを開いてみます。通常この作業は、ブランチに変更をプッシュした開発者が行います。

リポジトリ hello-world の画面を表示します。

■ [Pull requests]タブをクリックします。

プッシュの直後は、ファイルリストの上に [Compare & pull Request >]のリンクが表示されるので、ここからでもプルリクエスト・オープンに進むことができます。

■ 画面右の緑の[New pull request]ボタンを押します。

■ マージするブランチを選択します：

• base: — マージされるブランチ( ここでは master を選択します )
• compare: — マージするブランチ( ここでは readme-edits を選択します )
  これはプッシュしたブランチです

■ ブランチを選択すると、変更の差分が表示されるので、それが正しいことを確認してください。

■ [Create pull request]ボタンを押して下さい。

■ プルリクエストのタイトルと内容を入力します。
■ 内容にはMarkdown書式や@メンションが使えます。
■ [Create pull request]ボタンを押して下さい。

レビューからマージまではレビュワーが行います。（勿論、自分自身でも行えます）

リポジトリ hello-world の画面を表示します。

■ [Pull Requests]タブをクリックします。

■ レビューするプルリクエストを選択します。

■ 変更の差分を表示するには[Files changed]を選択します。

■ コードにコメントを追加したり、[Review changes]ボタンでレビュー結果を送信したりできます。
■ レビューについては以下を参照して下さい：

レビューが終わったら最終段階であるマージに進みます。readme-edits ブランチの変更をまとめて、master ブランチにマージします。

プルリクエスト画面下の緑色の[Merge pull request]ボタンのある所まで進みます。

[This branch has no conflicts with the base branch]の表示があれば、競合は発生していません。マージ可能です。プルリクエストをマージできるようにするには、すべての競合を解決しなければなりません。競合がある場合、競合する変更を持つファイルのリストが表示さ、[Merge pull request]ボタンは無効になっています。この場合は、GitHubのヘルプを参照して対処して下さい。

マージには３つの方法があります。[Merge pull request]ボタン右の[▽]を押すと、その方法が選択できるようになっています。

• Create a merge commit — masterに作業ブランチで行った全てのコミットを個々に含むマージコミット作成されます。（非Fast-forwardマージ：git merge –no-ffと同じ）
• Squash and merge — masterに作業ブランチで行った全てのコミットを１つに集約したマージコミットが作成されます。（スカッシュマージ：git merge –squashと同じ）
• Rebase and merge — 　マージコミットは作成されずmasterに作業ブランチのコミットが個々に追加されます。（リベース：git rebaseと少し異なる。詳細は以下のリンクを参照）

こられについての詳細は、GitHubのヘルプを参照して対処して下さい。

マージに関する詳細は以下のリンクを参照して下さい。

• プルリクエストから変更を取り込む — GitHubヘルプより
• マージコンフリクトへの対処 — GitHubヘルプより

■ マージの方法が決まったら、[Merge pull request]ボタンを押して下さい。マージの方法が分からない場合は、デフォルトの Create a merge commit で問題ありません。

■ 適切なコメントを入力して[Confirm merge]ボタンを押して下さい。

■ マージが終了するとこの画面が表示されます。
■ マージ後に、プルリクエストは自動的にクローズされます。
■ マージ後に、作業ブランチを削除したい場合は、[Delete branch]ボタンを使いますが、特別の理由のない限り作業ブランチを直ぐに消す必要はないと思います。

これで作業フローは完了していますが、最後に忘れてはならないことがあります。

■ マージ終了後に開発者に謝意を伝えることも大切かもしれませんね。