はじめに

一部タイトル詐欺が含まれます
(SourceTreeの行ごとにコミット機能がない(ブロック単位は可))

JetBrainsの製品はSVNやGit向けのバージョン管理機能を持っています。
その中でもGitに着目し、使い方を紹介します。

スクリーンショットはWindows 10 & IntelliJ IDEA 2019.3.1 (Ultimate Edition)を利用しています
(紹介しているものはIntelliJ IDEA Communityをはじめ、他のJetBrains製品でも利用できます)

なにか詰まったことがあればトラブルシューティングの章を参照してください
それでも解決できない場合はコメントをください

本記事内ではダイアログとモーダルをまとめて「ダイアログ」と表記します

Git機能を有効にする方法

既存プロジェクトで有効にする

ローカルリポジトリを作成するだけの場合

1. IDEで既存のプロジェクトを開きます。

2. メインメニュー内の「VCS -> Enable Version Control Integration」をクリックします
   

3. Enable Version Control Integrationダイアログが開くので、

4. 「Select a version control system to...」が「Git」になっていることを確認し「OK」をクリックします
   

5. 画面左下に「Version Control」タブが挿入され、Gitが有効になります。
   

GitHubでリポジトリを作りつつGitを有効にする場合

1. IDEで既存のプロジェクトを開きます。

2. 「VCS -> Import into Version Control -> Share Project on GitHub」をクリック

3. (GitHubへのログインがある場合もあり)

4. 「Share Project On GitHub」ダイアログにリポジトリ名やプライベートか否かなどの設定を行い、「Share」をクリック
   

5. 画面左下に「Version Control」タブが挿入され、Gitが有効になります。

git(GitHub, GitLab, GitBucket等)からクローンする

1. IDEを開いた際に表示される「Welcome to <IDE名>」ウィンドウから「Get from Version Control」をクリックをします
   

2. 「Get from Version Control」ダイアログ内の左メニュー「Repository URL」を選択するとGitからクローンを行うことができます
   

3. ダイアログ内の「Version control」が「Git」であることを確認し、「URL」にURLを入力、「Directory」に保存先を選択し「Clone」をクリックします。

URLはGitサービス等から取得してください。
GitHubでは各レポジトリページ内の右上にある「Clone or download」をクリックすることで表示されるメニュー内から取得できます。
例)

1. Clone終了後、プロジェクトの構成を尋ねられ(ることが多い)プロジェクトが開かれます

2. 画面左下に「Version Control」タブが表示されていればGitが有効になっています

パネル解説

Version Control

Version Controlパネルは画面左下の「Version Control」タブをクリックすることで表示されます

開いた直後に表示される「Local Changes」タブでは追加/変更/削除されたファイルや、まだバージョン管理に入っていないファイルを確認できます。
また、ファイル名をクリックすることでファイルの内容確認/変更や変更点の確認ができます。

他にもChangelist作成やコミットなども行えますが後ほど解説します。

「Log」タブではブランチの状態やコミットの状態が確認できます。
コミットを右クリックすることでReset, Revert, Cherry-pickなどの操作ができます。

プロジェクトビュー

プロジェクトビューはIDEウィンドウの左上にあるProjectタブから開くことができる。
Gitが有効になっていると、ファイルの状態によって色が変わります。

色	状態
赤	Gitで管理されていない
緑	Gitで管理されている新規作成のファイル
青	Gitで管理されている変更を加えたファイル
黒	Gitで管理されている変更のないファイル
黄	.gitignoreで指定されている無視するファイル

エディタ

エディタは画面中央に表示されるファイルを編集するパネルです

変更点

エディタ内ではファイルの変更を確認できます。
変更がある行は行番号の横に色やアイコンが表示されます。

色 or アイコン	状態
緑	新規追加された行
青	編集された行
▶	削除された行

色やアイコンをクリックすることで過去の状態を確認できます。

Rollbackアイコン()をクリックすることで過去の状態に行を戻すこともできます。

annotate

行番号と編集部分との間を右クリックし、「Annotate」をクリックすると、Annotateが表示されます。

Annotateは誰がいつ変更したのかを表示し、行をクリックすることでどのコミットで変更されたのかを確認できます。

history

エディタを右クリックし、「Git -> Show History」をクリックすることで、ファイルの変更を確認できるパネルが開きます。

パネルではいつどんな内容が変更されたのか、どのコミットで変更されたのかを確認できます。

エディタで範囲選択を行い、「Git -> Show History for Selection」をクリックすることで、選択範囲のみの変更を確認できます。

基本機能

コミット

コミットは「VCS -> Commit...」、または(設定次第で)様々な場所にあるアイコンをクリックすることで行えます。

「Commit Changes」ダイアログでは

• コミットを行うファイルの選択
• コミットメッセージの編集
• Commit Authorの変更
• Amend Commitの有効化
• Sign-off Commitの有効化
• コミット前にコードの分析を行うか(エラーチェックを行うか)
• コミット後にデプロイを行うか

などの設定が行えます

ダイアログ下部の「Commit」をクリックすることでコミットが行えます
「Commit」ボタン内のメニュー、「Commit and Push」はコミット後にプッシュダイアログを表示します。
また「Create Patch」ではコミット予定のファイルのpatchを作成できます

リモート

リモートの設定は「VCS -> Git -> Remotes...」から行えます
「Git Remotes」ダイアログではリモートの追加, 削除, 編集が行えます

プッシュ

プッシュは「VCS -> Git -> Push」から行えます
「Push commits to <ProjectName>」ダイアログではプッシュされるブランチ、コミットの確認や、タグの同期も行うかを設定できます。

ダイアログ下部の「Push」をクリックすることでプッシュが行われます
また、フォースプッシュは「Push」ボタンのメニュー内「Force Push」をクリックすることで実行できます

reset

リセットは「VCS -> Git -> Reset HEAD...」から行えます。
しかしこの方法ではreset先のhashやtagが必要なため、あまり便利とは言えません

便利なresetの方法として、Version Controlパネル内Logタブより、戻りたいコミットを右クリックし
「Reset Current Branch to Here」をクリックする方法を紹介します

「Git Reset」ダイアログではreset後のファイルの扱いを変更できます。

下部の「Reset」をクリックすることでresetが行えます

revert

Version Controlパネル内Logタブより、戻りたいコミットを右クリックし
「Revert Commit」をクリックすることでrevertを行えます

「Conflicts」ダイアログはコンフリクトで解説しています

ブランチ

ブランチの操作は画面右下から行えます

「+ New Branch」をクリックするとブランチの新規作成
「<branchName>」を右クリックするとrename, delete, checkoutなどが行えます。

マージ

マージを行う前にマージされる側のブランチにチェックアウトしてください。
(ex. developブランチをmasterブランチにマージする場合はmasterブランチにチェックアウト)
マージは「VCS -> Git -> Merge Changes...」から行えます。

「Merge Branches」ダイアログではマージ先のブランチの選択、squashやno fast forwardにするかなどの設定が行えます。
ダイアログ下部の「Merge」をクリックすることでマージが行えます。

コンフリクト

コンフリクトが発生すると「Conflicts」ダイアログが開きます

ダイアログにはコンフリクトしたファイルの一覧が表示されます
「Accept (Yours|Theirs)」ボタンをクリックするとすべてのファイルが選択したコミットのファイルになります
また、ファイルをダブルクリックすることで細かくどちらの差分を反映するのか指定できます

またはアイコンをクリックすると、マージに変更を加えることができます。
またをクリックすると変更を破棄できます

すべてのコンフリクトを修正し、下部の「Apply」をクリックすることでマージが完了します

stash

作成

stashの作成は「VCS -> Git -> Stash Changes...」から行えます

「Stash」ダイアログではメッセージを設定することができます。
「Create Stash」をクリックすることでstashを作成できます

復元, 削除

stashの復元, 削除は「VCS -> Git -> UnStash Changes...」から行えます

「UnStash Changes」ダイアログでは

• 「View」をクリックすると含まれている変更を確認
• 「Drop」をクリックするとstashを破棄
• 「Clear」をクリックするとすべてのstashを破棄

ができます。
復元したいstashを選択し、「Apply Stash」をクリックするとstashをファイルに反映できます

Changelist

Changelistを使うと、変更をまとめてリストごとに管理することができます。
標準でDefault ChangelistとUnversioned Filesというリストが存在しています。

Changelistの作成や削除はVersion Controlパネル内のからできます。

ChangelistからChangelistへ変更をD&Dで移動することもできます

また、エディタ内で変更点を選択することで、変更点ごとにチェンジリストに反映できます

この機能, 変更点が1ブロックだと分割して別々のChangelistに登録のような操作ができません
公式のYouTrack(GitHubでいうissueを管理するツール)では上記の操作ができないというチケットがあるため、そのうち対応すると思われます
S〇urceTreeなんか目じゃないといいつつ。。。無念

Tasks機能 (issue連携)

Tasks機能とは、IntellIJ内で作業リストを整理できる機能です。
チケット駆動の場合、作業リスト = issueやticketといえます
そしてそれらを管理するJiraやRedmine, Trello, GitHubなどのサービスと連携する機能があります。

連携の設定は「File -> Settings -> Tools -> Tasks -> Servers」から行います

「」をクリックし、Serverの追加を行ったあと、「OK」をクリックし離脱すると画面右上のツールバーにTasksプルダウンが挿入されます。

「Default task -> Open Task...」をクリックするとTaskの作成が行えます

連携したサービスのticketやissueはここから選択します。
また「Create New Task <上のTextFieldの中身>」をクリックすると、IntelliJ上でのTaskを作成できます
(連携したサービスに新しいissueやticketができるわけではない)

Taskの作成を行うと、「Open Task」ダイアログが表示されます。

IntelliJ上ではContextという単位で開いているファイルの状態などを管理しています。
ContextをTaskごとに管理する場合には「Clear current context」のチェックを入れてください。
Task用にChangelistやbranchを作成することもでき、それらの設定もこのダイアログで行えます

この時にChangelistを作成しておくと、どの変更を管理しているのかわかりやすいので利用しましょう

ツールバー内のTasksメニューから他のTaskを選ぶとTaskを変更することができます。
またChangelistに変更がないときにTaskを変更すると、Taskを削除するか尋ねられます

Pull Request確認(GitHub)

IntelliJでGitHubのアカウントを追加しておくとPull Requestを確認できます
「File -> Settings -> Version Control -> GitHub」からアカウントの追加が行えます
GitHubのアカウントが登録されていて、かつGit RemotesにGitHubのリポジトリが登録されていると、Version Controlパネルに「Pull Requests」タブが表示されます。

トラブルシューティング

Version Controlタブが見当たらない

左下のアイコンをクリックすることでタブを表示することができます

おわりに

「この(機能|操作)よく(使う|する)のに紹介されてない！」、「ここ間違ってない？」という方はコメントください。

最後になりますが、JetBrains製品の本質はショートカットの充実だと思っているので、
よく使うものだけでもショートカットを覚えてあげてください

Gitでコミット取り消す

cmd

git log --oneline
git reset --hard xxxxx

github上のソースを取得→実行にすこし手間取ったので手順を残しておく

• メニューバーから「File -> Import」を選択
• Select画面から、「Git -> Project from Git」を選択
• Select Repository Source画面から、「Clone URI」を選択
• 取得したいリポジトリのURLを設定した「Finish」で終了

業界によってはGitを扱えることが現場においてかなりベーシックなスキルになっていると思います。あまり最新の技術をばりばり扱っているわけでない現場であっても同様だと思います。また、たとえ普段は別のバージョン管理システムを用いている場合でも、（案件毎など）突発的にGitでの作業が必要になることもあります。

Webに関してはGithubやGitlab上でGitでのソースコード管理を行うことが業界のデファクトスタンダードとなってかなり経つので、扱えることが当たり前と考える人も多いです。SSHの扱いも同様です。

もし今まで（幸運なことに？）Gitを扱うことなくやってこれていたり、これからそういう業界を目指しているという方は、Githubも無料でプライベートリポジトリの作成が行えるようになったので、下記手順を行ってSSHやGitの練習をしっかり行っておきましょう。

この記事ではGitの利便性などには触れず、あくまで練習のための流れを説明します。細かい環境の違いなどでエラーが出ることもあるかもしれませんが、この流れの上で出るエラーはググったらすぐに解決するものが多いはずです。そこまで含めた練習テンプレートとしましょう。

先にSSHの準備

SSHを使うとこんなことができる

SSHはGitのための仕組みではありません。主にサーバを扱うエンジニアがよく扱うものではありますが、下記にどのような場合に使われているかのイメージしやすい一例を。

• （所謂サーバなどの）リモートマシンに、鍵ファイルだけでログインできる（パスワード管理いらない）
• リモートマシンを操作する
• FTPをセキュアな通信越しに使える
• セキュアな通信でGithub（Gitlab, Backlog）のリポジトリ操作ができる

などなどなど。「関係ねー」って思った人も多いかもしれませんが、扱えて損はないです。（守備範囲が爆広がりします）

SSHには鍵が必要

SSHの仕組み的にはパスワードでの接続も可能ではありますが非推奨であり、接続される側のサーバなどの環境構築時にはパスワードでのSSH接続をさせないように設定する慣習があります。

そこで、パスワードの代わりに接続の認証に用いられるのが鍵ファイル方式です。

推奨されるssh関連の管理ディレクトリに移動。Macではだいたいここがデフォです。

cd ~/.ssh

鍵を生成するコマンド

$ssh-keygen -t rsa

基本的にはエンター連打でよいですが、ファイル名は適宜変更しておくことおすすめします。

ファイル名の例）id_rsa_github_account

account部分に自身のユーザー名などをいれておくとわかりやすいです。
状況によってはパスフレーズを設定したほうがいいこともあるので留意しておきましょう。

二つのファイルが作成される

鍵には「公開鍵」と「秘密鍵」があります。公開鍵は外に出しても（他の人に見られても、どこかに登録しても、公開しても）大丈夫、秘密鍵はローカルマシンの中だけで管理しておく（公開しない、送信なども行わない）のが原則です。

この例のまま作成した場合は、

• 秘密鍵：id_rsa_github_account
• 公開鍵：id_rsa_github_account.pub

となります。

接続のイメージ

• 公開鍵を接続先に登録しておく。・・・①
• 接続時に秘密鍵をもって接続先に問い合わせをすると、・・・②
• 接続先がその秘密鍵と登録されている公開鍵を検証して、・・・③
• ちゃんとあっていれば接続させてもらえる。・・・④

という感じです。

githubに公開鍵を登録する

右上のアイコン - Settings

SSH and GPG keys

New SSH keyボタン

• Title

任意。（マシン名や鍵ファイル名などを推奨。あとで必要のなくなった鍵などは公開鍵であっても削除するべきなので、どのマシンからの接続のために登録した公開鍵なのか判別できるようにしておきます。）

• Key

.pubファイルの内容を過不足なくコピペする必要があります。

$ cat id_rsa_github_account.pub

とりあえず簡易的にはターミナル上でこのようなコマンドにて表示された内容をコピー、githubのKey欄にペーストしてAdd SSH Keyをクリックして登録しておきます。①

先程のSSH Keys一覧画面に表示されていればOKです。

接続確認をする

今回の流れでは、SSH接続するためのコマンドは以下のようになります。

ssh -T git@github.com -i ~/.ssh/id_rsa_github_account

これはsshコマンドの基本が

ssh (オプション) (ユーザー名)@(ホスト) -i (秘密鍵ファイル)

なので、上のコマンドの和訳的には、

「gitというユーザー」で「github.comというサーバー」に「id_rsa_github_accountという秘密鍵ファイル」をもって「-Tオプション」でSSH接続します

という意味のコマンドになります。これが②

このコマンドで、下記のように表示されればOKです。

Hi (user-name)! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

これは「接続はばっちりです、でもコマンドを叩いたりという機能は提供していないので、接続を切りますね。」とgithubからのメッセージです。③と④

リポジトリを作ってみる

ついにGitの話です。

サンプルとなるリポジトリを作ってみましょう。なんでも大丈夫ですが、差分がわかりやすいようにテキスト情報で構成されているものがよいでしょう。

htmlばかりのこのようなファイル構成を作成してみました。

git-test-prj
│  ├─ index.html
│
├─dir1
│  ├─ 1-1.html
│  └─ 1-2.html
│
└─dir2
   └─ 2-1.html

単純なテスト目的ならもっとシンプルでもいいですが、練習ならディレクトリや複数のファイルを用意しておきましょう。

gitリポジトリ化する

リポジトリとは、ソースコードと、今までの変更履歴、および、設定のかたまりみたいなものです。リポジトリにする＝init(=initialize=初期化)と言われたり、ローカルリポジトリの作成といったりします。

appを利用する

Fork

File - Init New Repository

SourceTree

Create

コマンドで行う

cd /path/to/proj/
git init

コミットする

リポジトリはコミットするところからが大事です。

コミットとはどのようなファイルが追加されたか、どのファイルにどのような変更が加えられたか、もしくは、なにが削除されたのかの情報です。これらの履歴自体と、その時点のファイルの状態を保存することをコミットと呼びます。前回のコミットから今の状態までが変更になります。

これらの情報を随時保存しておくことにより、いつ・だれが・どのような変更を加えたのかが管理できるようになります。また、それらの変更を区分したり、複数人が同時に様々な作業をできるようにする機能もありますが、今回はその説明は省きます。

現在は新規の４ファイルが追加されたという状況です。

状況を確認する

appを利用している場合は、わかりやすく新規４ファイルが変更点として表示されているでしょう。

コマンドでは以下のように表示できます。

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        dir1/
        dir2/
        index.html

正直わかりにくいです。（もっとわかりやすく表示も可能ですが、オプション覚えるの苦手なんで…）

ステージする

どの変更を今回のコミットに加えるか決めていくことをステージする、と言います。
ファイル単位でも変更点単位でも可能です（が、変更点単位をコントロールするのは少し大変なのでappを使っていない限りお勧めできません…）

４ファイル全てコミットしてしまうので、Stage allボタンなどが便利です。

コマンドではgit add *とすると同じ意味になります。

コミットする

ついにコミット！の前に、コミットのためにはコミットコメントが必要になります。

appの場合はファイルステータス画面や、Changes画面でステージされている内容と、下部にコメント入力欄が表示されているかと思います。ここに任意のメッセージを入力します。

一番初めのコミットはinitial commitとかになっているプロジェクトが多いです。お仕事などでルールや規約がなければそれが一番わかりやすいかと思います。

内容を確認の上、コミットボタンを押すことで晴れてコミット完了です！

コマンドではgit commit -m "initial commit"となります。コメント入力とコミットが同時です。

コミットを確認する

appではコミット一覧画面に表示されているかと思います。

コマンドではgit logですが、これもオプション付けないと見づらいかと…

これで、コミット履歴の存在するリポジトリができました。

余談）Gitリポジトリではなくすには

今までの履歴を全て削除し、新たなリポジトリとして管理しなおしたくなることがあるかもしれません。

そのディレクトリがGitリポジトリであるのは、.gitディレクトリの有無によります。sourcetreeなどにブックマーク情報は保存されていますが、都度.gitの中身を参照しているだけのようです。

なので、.gitディレクトリを削除してしまえば、過去のコミット履歴や接続情報などは消えてしまいます。

Githubにリポジトリ（の入れ物）を作る

Github上でリポジトリを作成します。これは今作ったリポジトリの入れ物になるものだと思ってください。

少し混乱するかもしれないのは、「リポジトリってさっき作ったよね？」ってことかと思います。これはリモートリポジトリとローカルリポジトリという概念があることに起因しますが、この辺りの詳細はおググりくださいませ。

ちなみに、この辺りの流れは人によっては逆の、Githubで（ほぼ空っぽの）リポジトリを作成して後述するクローンを行いローカルマシン上にて最初のファイルを作成し始める人もいます。（Github公式などはそちらを推奨しているようです）

いざ

きっとGithubのどこのページにいても表示されているであろう「＋」ボタン - 「New Repository」からリポジトリを作成できます

Repository Nameはローカルで管理しているものと一致している必要はありません。

公開範囲の「Public」「Private」設定がデフォではPublicになっていることに注意してください。

今回は「Initialize this repository with a README」はチェックを外した状態で大丈夫です。.gitignoreやlicenseも今回はなし（None）にしておきましょう。

「Create repository」をクリックすると、さくっとリポジトリが作成されました。

この画面にすべて書かれており今回の場合は「…or push an existing repository from the command line」の部分ですが、コマンドばかりでやさしくないです。

プッシュしてみる→エラー

さて、ローカルマシン上にはローカルリポジトリ、Githubには入れ物となるリモートリポジトリができました。

このローカルリポジトリの内容を、リモートリポジトリに同期することをプッシュといいます。

コマンドは前述のとおりGithubのリポジトリのページに表記されていますので、app使用例を見ていきましょう。

fork

サイドバーRemotesを右クリック - Add New Remotes

sourcetree

リポジトリ画面の右上、設定 - リモート - 追加

これらで開くダイアログではリモートの名前とURLを入力できます。

リモートの名前とは今回のGithubにあたるリモートリポジトリをローカル側で管理上の通称として扱うようなものですが、多くの方はGithub公式のおすすめ通り、originとしています。また他のチュートリアルなどでも困らないようにoriginとしておくのがおすすめですが、これが任意で決められるものであることは留意しましょう。

URLにさきほどのGithubのページに表示されていたURLを入力すれば登録ができます。今回はせっかくSSHの設定をしたので、SSH URLのほうを使いましょう。下記のような見慣れた形式のURLを見つけましょう。

git@github.com:account/git-test-prj.git

登録が完了したら、プッシュボタンを押してみましょう。

プッシュ画面にて対象のブランチをmasterにしてプッシュ。ブランチとかmasterとかを詳しく知りたい場合はおググりくださいませ。今は「masterと呼ばれる管理上の束なりを指定してリモートリポジトリに同期した」、って感じのふわっとした認識で大丈夫です。

エラーが表示されなければばっちりなのですが、この手順だと確実にエラーになります。

SSHでエラーでるやん？→SSHの便利機能

さてなぜエラーが出たのでしょう。上記で登録したURLと最初にSSHでgithubにSSH接続したURLを見比べて考えてみてください。

appを使っていても内部的には登録された内容に基づいてコマンドを実行しているのと同じです。そして登録されたURLがSSH URLの場合はSSHコマンドを用いているのと同じと考えましょう。
そして、このSSHコマンドには「特定のホストに対する接続の際にあらかじめ設定を決めておけばオプションを省ける」という便利な機能があります。
そうなると目指すべきはappで提供されているインターフェイスに合わせて、URLだけでSSHアクセスができることとなり、それはつまり、

$ ssh -T git@github.com

でSSH接続できること、となります。

先ほどコマンドでSSHした際のURLと違うのは-iオプションがないことですね。なので、これを省略できれば良いということになります。

この指定をするには先ほどの.sshディレクトリにconfigという拡張子なしのファイルを作成することで可能になります。Macにはこの設定のためのAppがありますが、簡単な内容なので手動で作成しちゃいましょう。

cd ~/.ssh/
vi config

以下の内容を書き込み。viの使い方は近くにいるVimmerに聞くかおググりくださいませ。もしくはconfigというファイルを.sshディレクトリに作成しテキストエディタで書き込んでもOKです。（が、この際viの最低限の扱いもできるようになっておいていいと思います。qiitaにはviの優良記事がたくさんありますよ！）

Host github.com
  User git
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_github_account
  IdentitiesOnly yes

IdentityFileのところが、-iと同義ですね。

これで晴れて下記コマンドでアクセスできるようになったかと思います。

$ ssh -T git@github.com

上の方に記述したHi!のメッセージが出ればOKです。鍵も持たずアクセスできるとは、顔パス気分ですね。

クローンもプッシュもSSHでできる！

ということで、リモート設定にGithubのSSH URLを指定してプッシュしてみましょう。

Githubのリポジトリページにいまプッシュした内容が反映されていればOKです。エラーが出たらしっかり読んでみましょう。出るとしたら鍵周りか、リポジトリの状態あたりではないでしょうか。

（余談）クローンから

さて、自分が管理するプロジェクトならば前述の手順でプロジェクトが開始できますが、業務などではすでに存在しているプロジェクトをもとに自身が手を入れていくことが圧倒的に多いでしょう。

そのような既存のプロジェクトを自身のマシンにコピーすることをクローンといいます。

どう違う？

githubをはじめgitのホスティングサービスでは、リポジトリのソースコードをクローンするためにhttps urlとssh urlを提供してくれています。クローンのコマンドは

$ git clone URL

という感じになります。
プライベートリポジトリの場合、このコマンドを実行するとユーザー名とパスワードを求められるかと思います。

プッシュする際にもユーザー名とパスワードの入力が必要になります。

この手間を省くため、ここまでの手順で鍵ファイルを用いたSSHによる接続が可能になっていればSSH urlを用いてgithub上のgitリポジトリをパスワード認証なしで操作することができますね。

適当に公開されているリポジトリでもよいのですが、ここまで進めてくださっている場合は自分の作ったリモートリポジトリが存在しているので、それを使いましょう。

ということで、先ほど作ったローカルマシン上のプロジェクトディレクトリを削除しちゃいましょう。ちゃんと変更した内容をコミットしプッシュ出来ていれば、その全てはすでにgithub上に同期されています。何も怖くないです！

いざ

sourcetreeやforkでは、既にGithub上にリモートリポジトリが存在している場合、クローンするのに必要なのは下記の情報です

• Repository Url（リモートリポジトリのURL）
• Parent Folder（そのリポジトリをクローン（保存）するフォルダー）
• Name（管理用の名前）

リモートリポジトリのURLはGithubのリポジトリ画面の右上Codeボタンから取得できます。

sshのconfigの設定が済んでいればこの設定でクローンができるので、あとは、上記同様クローンしたディレクトリにてファイル変更を行いコミットしプッシュする流れでリモートリポジトリを変更することが出来ます。

実際の案件でもだいたいこの流れです。SSHキーを登録済みのアカウントを案件のリポジトリに招待してもらう形であれば、即クローン可能です。

（余談）複数のアカウントの場合

さて、なにか事情があり、Githubアカウントが複数あり、その場合まじめにこの手順を進めると困ったことになることに気が付くかと思います。

現在は、id_rsa_github_accountの鍵を用いてgithub.comへのアクセスを行います！と設定されているので新しいアカウント用に作成した鍵が使えないですね。理由は今までの流れをよく読み解くとわかります。

解決策

~/.ssh/configファイルでgithubへの接続を複数定義します。
現在はgithub.comへの接続はすべて同じ設定が適用されるようになっています。これを疑似的にgithub-user1.comとgithub-user2.comへの接続という形に分けてしまいます。

Host github-user1.com
  User git
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_github_user1
  IdentitiesOnly yes

Host github-user2.com
  User git
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_github_user2
  IdentitiesOnly yes

こうすることで、github-user1.comへのSSHアクセスとgithub-user2.comへのSSHアクセスは区別され、別々の設定（鍵）が適用されますが接続先はどちらもgithub.comです。（このHostの命名は自由で、gh-1などでも大丈夫です。）

少し不思議な感じがするかもしれませんが、こんな感じになります。

$ ssh -T git@github-user1.com
Hi user1! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

$ ssh -T git@github-user2.com
Hi user2! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

なので、Gitを扱ううえでの接続先となるリモートURLの変更が必要になりますので適宜変更しましょう。
リモートリポジトリのURLはこのようになります。

git@github-user1.com:account/git-test-prj.git

うまくいけばフェッチ・プル・プッシュなどが行えるかと思います。

まとめ

SSH＋Git周りで扱いはじめの頃に「まずどうしたらいいんだろう」と悩んでしまう辺りをざーっと書いてみました。盛りだくさんになりましたが、ローカルでリポジトリを作る、クローンする、Githubにリポジトリを作る、リモートの設定を行うなど一通り出来て、sshのconfigを作成しsshを試すなど、これらを一通り成功させておくといざという時に困ることがなくなるでしょう。これらはgithub, gitlab, bitbucket, backlogなどプラットフォームをまたいでも（それぞれ機能の呼称が変わることがあっても）gitという仕組みの上になりたっているので概念は基本的に同じです。

そして、実際の現場ではブランチの扱い方やコミットの流れ、プルリクエストのルールなど所謂ローカルルールに則って業務を行うことになります。それは現場に入ってから・案件にアサインされてから共有されたドキュメントを読んだり前任者に確認して学ぶことになるでしょう。その前準備として、スムーズに業務にはいっていけるように、これらの基本をしっかり身につけておきましょう。

gitの様々な機能を使いこなすためにハードルとなるコマンドの多さも、各種appを使うことで簡単に乗り越えられますので、機能を知るためにも一つでもいいのでappを使いこなせるようになっておきましょう。逆に基礎的なコマンドを覚えることも強い武器になり得ます。git logやgit statusなどは誰でも使えるべきだと個人的には考えています。（守備範囲がまた爆広がりするかも）

本稿の最も基本の部分を押さえられたら、それに続くたくさん用意されているGitの便利機能にチャレンジしてみましょう。Gitは共同作業のための仕組みだということを忘れず、少人数やひとりでのプロジェクトでも積極的に活用し大規模プロジェクトにアサインされた時のための準備をしておくのが大事です。またgithubはOSSのためのプラットフォームでもあります。そこにプッシュ出来たということは、世界中のエンジニアとつながることができる第一歩を踏み出せたということを意味します。どんどん活かしていきましょう。