40
34

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Githubからクローンする時のプロトコルの違い

Last updated at Posted at 2020-11-10

はじめに

GitクライアントツールからGithubのリポジトリをクローンする時に、httpsやSSHの通信プロトコルの話とリポジトリへの権限について、理解できていない部分があった。
友人に手伝ってもらいながら試してみて分かった事があるので、メモとして残しておく。

実行環境

【ローカルPC-OS】
  Windows 10 Pro 

【インストールツール】
  Git for windows 2.29.1
  SourceTree 3.3.9

 ※事前にGithub上にアカウントは作っておく。

本記事の流れ

1.Gitクライアントツールのインストール
2.通信プロトコルの説明(httpsとSSH)
3.アクセス権限の話

1.Gitクライアントツールのインストール

まずはWindows用のGitを以下よりダウンロードして実行する。
  ・git for windows(インストーラー場所  インストール手順の参考サイト

GITクライアントツールは何でも良いが、今回はSourceTreeをインストールする。
  ・SourceTree(インストーラー場所   インストール手順の参考サイト

 ※上記の『git for windows』をインストールしていなくても、SourceTreeのインストール時に一緒にインストールする事が可能っぽい。しかし、他のGitクライアントツールも併用したい場合に何か面倒な事が起こりそうなので、上記の流れを推奨。

SourceTreeのインストールでは、インストールの中でSSH鍵の設定も求められるが、一旦はスキップしてしまって問題ない。

2.通信プロトコルの説明(httpsとSSH)

Github上にあるリポジトリを単純に使いたかったり、共同開発をしたかったりする場合、基本的にはローカルにクローンを持ってくることが多いと思う。

しかし、cloneするにもその後にpushするにも誰でもできる訳ではない。
ローカルのGitクライアントからクローンをする場合、クローンしようとしている人のGithub上のアカウントを把握して、そのアカウントが対象のリポジトリにどんなアクセス権限を持っているかを確認する必要がある。

その際の認証をどのように行うかというのが、httpsプロトコルSSHプロトコル で異なるという理解。
 

httpsプロトコルの場合
初めてGithubのリポジトリをクローンしようとした場合、Basic認証が動き、Githubの [アカウント名] と [パスワード] の入力が求められる。(ブラウザ経由でサインインを求められる事もある様だが、やっている事は同じ。)

※クライアントツールによっては、1度目の認証通過時に資格情報が記録されているため、同じホスト(今回であればgithub.com)に2回目以降接続する際は入力情報が省略される。

 

SSHプロトコルの場合 
自分のGithubアカウントはどれなのかをSSH鍵を使って判断しているイメージ。
そのため、そもそもGithub上で自分のプロフィールに対してSSH公開鍵を設定していない場合、SSHプロトコルによる接続ができない。

SSH鍵の設定後は、クライアントツールの起動のタイミングやリポジトリへの接続のタイミングで、パスフレーズ(SSH鍵を作成した時に設定したもの)を求められるので、それを入力すればリポジトリに接続できる。

※Github上のアカウントで対象のリポジトリに権限を持っていなければ、もちろんclonepushはできない。

   
接続のイメージはこんな感じ
あなたのリポジトリクローンしたいです!
  あんたは誰や?

  httpsプロトコルで接続している場合:Basic認証情報からGithub上のアカウントを判断。
   SSHプロトコルで接続している場合:鍵情報からGithub上のアカウントを判断

  君はOK or 権限ないからダメよー 

3.アクセス権限の話

権限の設定は基本的にリポジトリ単位でできる。
Github上で自分がオーナーのリポジトリを開くと Settings タブがあるはずなので、そこに入り『Manage access』から対象のアカウントに invitation を送る。

※『invite a collaborator』のボタンしかなく、ここでの権限は [collaborator] しかなさそうなので、Github上のどのアカウントに対して [collaborator] としてinvitationを出すのかという話。

アカウントに対する基本的な権限は [collaborator][non-collaborator] しかないという前提で、PublicリポジトリとPrivateリポジトリの権限について整理する。

Publicリポジトリの場合

■non-collaborator
 読み込み権限(clone) ⇒ OK
 書き込み権限(push) ⇒ NG

■collaborator
 読み込み権限(clone) ⇒ OK
 書き込み権限(push) ⇒ OK

Privateリポジトリの場合

■non-collaborator
 読み込み権限(clone) ⇒ NG
 書き込み権限(push) ⇒ NG

■collaborator
 読み込み権限(clone) ⇒ OK
 書き込み権限(push) ⇒ OK

※Privateリポジトリについても [collaborator] としてinvitationを出すしかできなそうなので、以下の権限も作れるかと予想していたがここの権限設定からでは無理っぽい。

 読み込み権限(clone) ⇒ OK
 書き込み権限(push) ⇒ NG
 ↑この権限設定はできない。

しかし、デフォルトが上記というたけで [collaborator] に対する権限は、もう少し細かく設定ができるのかもしれない。

補足

ブランチレベルでの権限設定もできそうだが、それは『Setting』タブにあるbranch protection rule を使えば、メンバー対して細かい権限設定もできそうだが本記事ではここまで。
(例えば、Masterブランチにはpushできる人を特定のメンバーのみにするなどは、ここで設定できるそう)

関連してそうな記事を一応貼っておく。
https://qiita.com/da-sugi/items/ba3cd83e64c689795c50

40
34
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
40
34

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?