What's New Qiita

20200223のGitに関する記事は7件です。

  • 投稿日：2020-02-23T22:38:55+09:00

よく使うgit stash系コマンド

stashの小ネタです。ふと思い出せないときがあるので、備忘録兼ねて。

gitで作業中に差し込みのタスクが入ってきたときなどに使う、 git stash コマンド。

よく使うコマンドをリストアップします。

作業中のファイルを退避

$ git stash

退避したリストを確認

$ git stash list
stash@{0}: WIP on <branch名>: <コミットハッシュ> <コミットメッセージ>
stash@{1}: WIP on <branch名>: <コミットハッシュ> <コミットメッセージ>
...

退避した内容を確認する

$ git stash show <stash名>
# ex: git stash show stash@{0}
# stashしたファイルのdiffが見れる

指定した退避内容を全て適用する（適用した内容を破棄しない）

$ git stash apply <stash名>

最新の退避内容を全て適用する（適用した内容は破棄される）

$ git stash pop

指定した退避内容から、一部のファイルのみ適用する

指定したstash名に退避されているファイルの中から、指定したファイルの退避内容を適用する

$ git checkout <stash名> <ファイル名>
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-23T19:17:55+09:00

【GitHub】はじめてのgit push がうまくいかない時の対応

はじめに

はじめてGitHubに触れ、リモートリポジトリへの接続、pushを行った際に自分がつまづいた点を記載します。
初学者ゆえに基本的な内容になっているかと思いますが、同じエラーが発生した方のご参考になれば幸いです。
バージョン : git version 2.21.1

前準備　GitHubへの登録・SSH接続

GitHubのユーザー登録を行い、SSH接続の設定を行う。
SSH接続については、主に「GitHub.com ヘルプドキュメント」を参考にしながら進めました。
またssh-agentの理解については「ssh-agentを利用して、安全にSSH認証を行う」が参考になりました。
現段階では秘密鍵はGitHubで使うだけですが、複数サーバーに跨がる場合に真価を発揮するよう。

リモートリポジトリの設定

GitHubでのリポジトリ作成後、そのリモートリポジトリ情報をターミナルで追加。（リモートリポジトリを紐づける）

git remote add origin https://github.com/****.git

リモートリポジトリにpush

設定したリモートリポジトリにpushするところでエラー発生。

$ git push origin master
To https://github.com/****.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/****.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

「ローカルにないworkがリモートに含まれている」
「git pullによりその違いを統合してから再度pushするように」といった内容。

git pullを行なったが、うまくいって・・・ない。

$ git pull origin master
From https://github.com/****
 * branch            master     -> FETCH_HEAD
fatal: refusing to merge unrelated histories

mergeができていないようだ。

試しに再度git pushしてみたところ、、、

$ git push origin master
To https://github.com/****.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/****.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

やはりmergeされていない(git pullがうまくいっていない)ことが問題のようだ。
参考：「non-fast-forward エラーの扱い」

そして試行錯誤の末、下のログにいきついた。

$ git pull origin master
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

「mergeされていないファイルがあるからpullできない」
「ワーキングツリーでそれらを構築し、git addしてcommitせよ」といった内容。

$ git add -A
$ git commit

git pull origin master
From https://github.com/****
 * branch            master     -> FETCH_HEAD
Already up to date.

$ git push origin master

これで成功しました！

考察①　git pullがうまくいかなかった理由

「Gitのマージ概要および、共通の分岐元を持たないブランチ同士のマージ（割としょうもない話）」に書いてありました。
「共通の祖先コミットが無いコミット同士ではマージをすることはできません」とのこと。
もともとローカルで作成していた内容とリモートで新たに作成した内容（READMEファイルが自動生成）は
共通の祖先コミットがないため、今回現象に至ったようです。
そういった場合は(かなりイレギュラーな対応で今後やることはないでしょうが)
「--allow-unrelated-histories」オプションを付けることによりmergeできる。

考察② git addとgit commitでうまくいった理由

とてもわかりやすい記事「git fetchの理解からgit mergeとpullの役割」によると、
「pullはfetchとmergeの両方を組み合わせたコマンド」。
今回git pullではあくまでmerge工程までうまくいかなかっただけで、fetchについては実行がされていた。
その状態でgit addとgit commitを実施してリモートとの差をなくす(ローカルのREADMEファイルを更新する)ことにより、最終的にgit pullがうまくいった。

まとめ

色々と遠回りしましたが少しGitHubの理解が進みました。
また上記考察は僕の推定が多分に含まれておりますので、
誤り・認識違い等ありましたらコメントでご指摘ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-23T16:39:59+09:00

Github投稿 Push

1. git init 取り消し

$ rm -rf .git

2. Gitリポジトリの作成

$ git init

3. リポジトリへの登録

$ git add .

4. コミット

 $ git commit -m "first commit"

5. リモートリポジトリの登録

 $ git remote add origin <URLアドレス>

5. リモートリポジトリの確認

 $ git remote -v

6. リモートリポジトリに反映

 $ git push origin master
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-23T16:37:02+09:00

git lfsを含んだリポジトリを移行する

git lfsで管理されたファイルがある場合、以下のように普通にリモートを足してpushするだけではgit lfs管理下のファイルは移行先にpushされません。

git remote add new https://hogehoge/path/to/repo
git push -uf new master

移行元のサーバーからすべてのファイルを取得して、移行先のサーバーへpushする必要もあります。

git lfs fetch origin --all
git lfs push new --all

参考リンク

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-23T13:27:33+09:00

お前らのコミットは汚い

お前らのXXXXは<ネガティブな形容詞>シリーズ で失礼します。

日頃gitをお使いの皆様におかれましては、キレイなコミットを心がけていらっしゃいますでしょうか。

私も心がけてはいますが、なかなか難しいものがあります。
参考までにこちら、最近業務で書いたプルリクエストのコミットログです。

スクリーンショット_2020-02-22_18_57_29.png

控えめに言って汚いと思われたかと思います。
ではキレイなコミットの例を。

スクリーンショット_2020-02-22_19_01_38.png

プルリクエストというのは、やはり先達の方に見ていただいてご指摘いただこうというものですから、
当然コミットハッシュもゾロ目等でキレイにするというのがマナーです。

では今回はこのキレイなコミットをどうやって作るのか、という話を書きます

(ショート)コミットハッシュ

コミットハッシュとは、gitのコミットごとに生成される、40桁の[0-9a-f]からなる文字列です。

お手元のリポジトリ上で git log --format=%H を叩くとコミットハッシュの一覧が出力されるかとおもいます。
これの頭7桁をとったものがショートコミットハッシュで、先程の画像の右側に表示されていたものです。
git log --format=%h で(ほぼ)ショートコミットハッシュ取得することができます（し、単にコミットハッシュの8文字以降を見なかったことにしても同一のものが得られます）。

ではコミットハッシュはどのように決定されるのかというと、
詳しくは

あたりをご参照いただいて、

簡単に説明すると、
「ディレクトリ構造」と「親コミット(≒直前のコミット)」と「Author」と「Committer」と「コミットメッセージ」によって決定されます。

これらのうちどれか１つでも変更があれば、コミットハッシュは再計算されます。

キレイなコミットハッシュを作る

gitはコミット後であっても過去のコミットについて情報を変更することができるのはご周知の通りです（git commit --amend や git filter-branch 等で歴史を改ざんした経験があるかと思います）。

ということは、コミットした後、ハッシュがキレイでなければ、情報を変更し、またハッシュを再確認し、キレイでなければ.....と続けることで最終的にはキレイなコミットハッシュを持ったコミットを生成することが可能なはずです。

狙ったコミットハッシュを生成するには、このループをおよそ 16 ^ 40 回繰り返せば達成されるはずですが、ちょっとだけ現実的ではないのと、
そもそもそういう衝突が起きないように設計されているのがコミットハッシュですからこれは諦める必要があります。

参考:
How hard is it to get a git hash collision?

天下のGoogle様でも３年前にようやくハッシュが衝突する2つのファイルを生成できるようになった程度です。

狙ったハッシュを生成するのはさらに困難でしょう。

ショートコミットハッシュならどうでしょうか。16^7(≒ 2.7億) 程度であれば総当たりでなんとかなりそうな気がします。

そこで、なんとかしてくれるツールを作りました。

commit_artist

Rustで書いたCLIっぽいものです。

使い方

# cargo を持ってない人はこちらから https://www.rust-lang.org/tools/install
$ cargo install commit_artist

$ cd <直近のコミットを改ざんしたいリポジトリのディレクトリ>

$ git log -1 --format=%H
86637c3f206d228df1dc1dafa49d31b159b8a358

$ commit_artist -p 1234567
173015040 hashes calculated...
Yay! Now your new hash of the latest commit is 12345672abd92a159f3886e08951f29ee7ce0041.

$ git log -1 --format=%H
12345672abd92a159f3886e08951f29ee7ce0041

yay!

ちなみに、 git cat-file (コミットオブジェクトを覗き見るコマンド) をするとこんなかんじです

$ git cat-file -p 12345672abd92a159f3886e08951f29ee7ce0041
tree 839ac38ae8ee7604922680774468473c33162b5c
parent eeeeeeea55ebeec4794897154720d08812304a1c
author rnitta <attinyes@gmail.com> 1582426518 +0900
committer d6dc479254c0faa95cd8ee438a6b6611ce62b1c8 <attinyes@gmail.com> 1582426518 +0900

update comments and did something

commiterの名前が怪しい文字列になっています。

仕組み

仕組みとしては、
外部コマンド git を叩いて最近のcommitに関する種々の情報を取得し、
コミッターの名前を変更して新たにコミットハッシュを再計算し、
これをキレイなハッシュが見つかるまで繰り返す、というものです。

コミッターの名前を変更している理由は、

「ディレクトリ構造」と「親コミット(≒直前のコミット)」と「Author」と「Committer」と「コミットメッセージ」によって決定されます。

この中で改ざんしやすいものはAuthorとCommiterとコミットメッセージで、
Authorを改ざんするのはよろしくないし、
コミットメッセージは人の目に触れやすいので改ざんはよろしくないし、
Committerの名前かメールアドレスなら改ざんしてもいいだろうと。

architecture.png

アーキテクチャを説明した風の図がこちらです。

マルチスレッドにしているのが工夫ポイントかなと思います。
こういった終わらなければ無限にタスクを積み続けるようなプログラムだと、ワークスティーリングなランタイムを使ったasync/awaitが相性良いかなとは思ったんですが、async/awaitなーんもわからん状態に陥ったので任意のサイズのイテレーションを回す感じのマルチスレッドで実装してみました。

Issue, PR, Star! お待ちしております。
https://github.com/rnitta/commit_artist

CLI

書いたプログラムをCLIにするにあたって、
(--path とか --jobs みたいなオプションを受け取るために)
Rust製のCLIフレームワークである、 Seahorse を使っています。
ロゴがかっちょいいでお馴染みのSeahorseです。まあ僕がロゴ(アイコン)作ったんですけど。

d3e77500-51a0-11ea-845e-3cc87714278b.png

ミニマルですし、外部クレートに依存していないし、コード量も多くないのでサクッと読めます。
https://github.com/ksk001100/seahorse
こちらもぜひ

免責

Committer nameを書き換えますし、コミットハッシュを意図的に頭数文字固定してしまおうというevilみがあるプログラムなので、業務で使って怒られてもしりません。
あと最悪リポジトリ壊れてもしりません。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-23T13:05:20+09:00

Git Action でリポジトリのミラーを行う

要件

  • リポジトリを他人と共有したい
  • 特定の人物には閲覧のみさせたい。もしくは push を無効にしたい
  • 閲覧できるソースの範囲を限定したい

対応

  • リポジトリを別のリポジトリにミラーコピーして、そのリポジトリを共有する
  • git push された際に、Git Action で自動的にミラーコピーできるように設定する

手順

01. ミラー先リポジトリを作成する【ブラウザ：ミラー先リポジトリ】

ブラウザから Github に入り、 アカウントのリポジトリリストから New で、空のリポジトリを作成します。
READMEを作成するにチェックを入れると、リポジトリがすぐに作成されるのでそちらの方が楽だと思います。
中身は手動では何も入れなくて大丈夫です。

02. パスフレーズなしのSSH鍵を生成する【ローカル】

Action では対話ができないので、通常のSSH鍵ではなく、パスフレーズなしのSSH鍵を指定する必要があります。
そのためのSSH鍵を作成します。
ミラー先（閲覧用） のリポジトリをcloneする際のSSH鍵のある場所に移動します。

$ cd .ssh

パスフレーズなしのSSH鍵を生成します。
OpenSSHの構成が OpenSSH 7.8 から変わりヘッダが -----BEGIN RSA PRIVATE KEY----- から -----BEGIN OPENSSH PRIVATE KEY----- に変わり、ActionでのSSH接続が失敗する場合があります。
その対策のため、 -m PEM をオプションに追加してSSH鍵を生成してください。

$ ssh-keygen -t rsa -b 4096 -m PEM -C <githubアカウントメールアドレス>

SSH鍵の名前を id_rsa_nopass にして生成します。
（id_rsaのままだと上書きしてしまうので注意してください。）
怖い場合は、.ssh-nopass とか別のフォルダを作成して、その中で作業すると安全だと思います。

Generating public/private rsa key pair.
Enter file in which to save the key (/<ユーザーディレクトリ>/.ssh/id_rsa): ./id_rsa_nopass

パスフレーズには何も入力せず、Enterで進みます。

Enter same passphrase again:
Your identification has been saved in ./id_rsa_nopass.
Your public key has been saved in ./id_rsa_nopass.pub.
The key fingerprint is:
<フィンガープリント> <githubアカウントメールアドレス>
The key's randomart image is:
+---[RSA 4096]----+
（略）
+----[SHA256]-----+

参考：【OpenSSH 7.8】秘密鍵を生成する形式が変更になった件について

03. git secret に秘密鍵を登録する【ブラウザ：ミラー元リポジトリ】

先ほど作成した秘密鍵を、リポジトリの　secret（暗号化領域） に登録します。

参考：　Githubの secret について

ミラー元（作業用） のリポジトリの Settings ＞ Secrets を開きます。

image.png

Add a new secret のリンクを押下します。
secret登録欄が開きます。

image.png

id_rsa_nopass（秘密鍵） の内容をクリップボードにコピーします。

$ clip < ./id_rsa_nopass

Name 欄に SSH_PRIVATE_KEY と入力します。
Value 欄で、Ctrl+Vで、クリップボードにコピーした内容を貼り付けます。

Add secret ボタンを押下します。

image.png

このように登録されていたらOKです。

04. SSH鍵を登録する【ブラウザ：アカウント】

SSH公開鍵を登録して、SSHログインができるようにします。

image.png

githubのアイコンから Settingsを選択します。

image.png

Settings メニューから SSH and GPG keys を選択し、SSH keysの「New SSH key」を選択します。

一旦、git bash に戻って、公開鍵キーをクリップボードにコピーします。

$ clip < ./id_rsa_nopass.pub

Key欄にペーストします。
Titleは任意のキー名（半角英数がよいでしょう）を設定します。

image.png

「Add SSH Key」をクリックするとパスワードを求められるので入力確認します。

image.png

登録が完了すると、キー名とフィンガープリントが表示されます。

image.png

github に SSH接続します。
SSH鍵を<ユーザディレクトリ>以外で作成した場合、-iオプションで鍵のパスを指定する必要があります。
SSH鍵のパスフレーズなしに接続できることを確認します。

$ ssh -T git@github.com -i ./id_rsa_nopass
Hi miu200521358! You've successfully authenticated, but GitHub does not provide shell access.

参考：Testing your SSH connection

05. .gitattributes を登録する【ブラウザ：ミラー元リポジトリ】

ミラー元（作業用） のリポジトリのルートに .gitattributes がない場合、新規ファイルを作成してください。
既にある場合は、そのファイルに下記を追記してください。

.github/ export-ignore
.git*    export-ignore

これは、Actionが保存される github/workflow のフォルダと、.gitattributes 等、gitの設定ファイルを、export時に除外する、という指定です。
この指定を追加していくことで、ミラー先（閲覧用） のリポジトリにミラーコピーされるファイルをコントロールできます。

06. Git Action を登録する【ブラウザ：ミラー元リポジトリ】

ミラー元（作業用） のリポジトリのメニューから Actions を押下します。
新規Actionに登録するワークフローを選べますが、無視して右上の Set up a workflow yourself をクリックします。
image.png

このような入力画面が出てきたら、下記コードを適当なテキストエディタにコピーしてください。

image.png

下記コードの設定項目（env: の下の <日本語の項目>）を書き換えて、既存のコードはすべて削除した上で、下記コード全文を main.yml に貼り付けてください。
コメントもそのまま貼り付け可能です。

name: Mirror Repository 

on:
  push:
    branches:
      - master  # branch:master に対する push が行われた時にのみ処理を実行する
jobs:
  build:
    runs-on: ubuntu-latest  # 最新のubuntuイメージを使用する
    env:
      # ミラー先リポジトリ名
      MIRROR_REPOSITORY_NAME: <ミラー先リポジトリ名>
      # ミラー先のリポジトリSSHパス
      MIRROR_RIPOSITORY:  <ミラー先リポジトリのclone用SSHパス(git:github～っての)>
      # gitアカウント名(git config user.name）
      GIT_NAME: <Github のアカウント名>
      # gitメールアドレス（git config user.email）
      GIT_MAILADDRESS: <Github のメールアドレス>
    steps:
    - uses: actions/checkout@v2
    - name: set-git
      run: |
        git config --global user.name $GIT_NAME
        git config --global user.email $GIT_MAILADDRESS
    - name: set-ssh
      run: |
        mkdir ~/.ssh                                            # SSHディレクトリ作成
        chmod 700 ~/.ssh                                        # 権限を設定
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa   # secretに保存されているパスフレーズなしの秘密鍵を出力する
        chmod 600 ~/.ssh/id_rsa                                 # 権限を限定する
    - name: clone
      run: |
        mkdir ~/mirror                                          # ミラー用ディレクトリ作成
        cd ~/mirror                                             # ミラー用ディレクトリに移動
        git clone $MIRROR_RIPOSITORY                            # ミラー用リポジトリをclone
        echo | ls -l ./                                         # ファイル存在確認
    - name: export
      run: |
        git archive --format=zip HEAD > ~/original.zip          # リポジトリの最新ソースを zip でexportする
        echo | ls -l ~/original.zip                             # ファイル存在確認
        mkdir ~/original                                        # 保持用ディレクトリ作成
        unzip -o -d ~/$MIRROR_REPOSITORY_NAME ~/original.zip    # zipを展開する(既存上書き)
        echo | ls -l ~/$MIRROR_REPOSITORY_NAME                  # 中身表示
    - name: copy
      run: |
        cp -r ~/$MIRROR_REPOSITORY_NAME ~/mirror                # オリジナルをミラーにコピーする
        echo | ls -l ~/mirror/$MIRROR_REPOSITORY_NAME           # 中身表示
    - name: push
      run: |
        cd ~/mirror/$MIRROR_REPOSITORY_NAME                     # ミラー用リポジトリに移動
        echo | ls -l                                            # 中身表示
        git diff                                                # 差分表示
        git add -A                                              # 全部追加
        git commit -m "mirror from original"                    # commit
        git push origin master                                  # push

コピペできたら、右上のStart commitを押下します。

image.png

直接 push してしまって良い場合は上のラジオボタン、pull request を生成する場合は下のラジオボタンを選択してください。
上のラジオボタンを選択して commit した場合、直後に Action が実行されます。
下のラジオボタンの場合、pull request をマージしたタイミングで Action が実行されるはずです。
image.png

image.png

実際のログを確認します。

image.png

image.png

image.png
（どの項目にも簡単なログを出してます）

image.png

このように、緑のチェックマークがついていれば、その処理は成功しています。
赤い×だと失敗しているので、中を確認してください。

07. ミラー先を確認する【ブラウザ：ミラー先リポジトリ】

ミラー先リポジトリを確認すると、初回は全ファイルがcommitされています。
2回目以降は、更新のあったファイルがあげられています。

image.png

蛇足

Git Action では、デプロイやtest等、様々なワークフローが実行できます。
herokuへの自動リリースもできると思います。

以上

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-23T00:20:24+09:00

Cloud9からGitHubのレポジトリへアップする手順（エラー解決方法含む）

  • Git BashなどでGitを動かしたことがある。
  • GitHubのレポジトリは作成済。

という方で、

  • 「初めてAWS Cloud9上で開発を始めたため、作成したソースを、既にあるGitHubのレポジトリへアップしたい」

という方向けに作成しました。

私自身はgit bashでGit/GitHubを操作したことはありましたが、初めてCloud9でgitを扱う際、色々とエラーが出て困ったので、Cloud9用の記事が欲しかったなと思って作成しました。

なお、GitHubのレポジトリは「公開」にしている前提です。
（非公開だとまた手順が異なるよう）

※Git/GitHub初学者の方は以下の動画がおすすめです。
https://www.udemy.com/share/101vBkAEMYcFxTTHgE/

はじめに

まずはcloud9のターミナルを用意。
念のため、gitが入っているか確認します。（Cloud9だと当然入っていますが）

$ git --version
git version 2.14.5

ローカルレポジトリ作成

ローカルレポジトリを作成したい任意のディレクトリに移動し

$ git init

を実行すると、「.git」ディレクトリ（ローカルレポジトリ）が生成されます。

ステージングエリアにadd

まずは、ステージングエリアにadd

$ git add [file]

※git addのオプションについては以下がわかりやすかったので参照下さい。
https://note.nkmk.me/git-add-u-a-period/

ローカルレポジトリにcommit

そして、ステージングエリアにあるファイルをローカルレポジトリにcommit

$ git commit -m "[任意のメッセージ]"

リモートレポジトリの登録とgit push

commitできたら、cloud9上で作成したgitのローカルレポジトリには登録完了です。
次に、GitHubのレポジトリ（リモートレポジトリ）にpush（アップロード）する必要があります。
まずはリモートレポジトリの登録から

$ git remote add origin git@github.com:[自身のGitHubのレポジトリ].git

その後、

$ git push -u origin master

ここで下記のようなエラーが出る方がいると思います。

Permission denied (publickey). 
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

上記のエラーは、それぞれの行ごとに、以下のような意味です。 

パブリックキーで権限が拒否された。
リモートリポジトリが読み取れない。
アクセス権持っている？それともリポジトリ自体存在している？

エラーを解決していきましょう。

先ほど、リモートレポジトリの登録は完了したかと思います。
そのため、先ほどのエラーメッセージの「リモートレポジトリ自体存在している？」は問題ないということになり、
「アクセス権持っている？」が問題になります。

では、アクセス権を得ましょう。

GitHubへアクセスには、公開鍵が必要です。
開発環境で公開鍵を作成し、GitHubへ公開鍵を登録することでアクセスできるようになります。

公開鍵の作成

まずは、cloud9内のディレクトリに、公開鍵を作成します。

$ ssh-keygen -t rsa -C "[リモートレポジトリを登録した自分のメールアドレス(・・・@gmail.comなど)]"

（-Cより後のコメント部分はなくても実行可能ですが、GitHubに登録しているEmailアドレスを指定するのが一般的のようです）

「ssh-keygen」はSSH（Secure SHell）の公開鍵と秘密鍵を作成するコマンドです。
ちなみにオプションの意味は

  • 「-t rsa」・・・作成する鍵の暗号化形式を「rsa」で指定
  • 「-C "コメント"」・・・コメントを指定

もっと詳しく知りたい方は以下記事がよいと思います。
https://www.atmarkit.co.jp/ait/articles/1908/02/news015.html

実行すると、以下のメッセージが出てきます。Enter～から始まる行が3回あり、各行にて入力を求められますが、すべて何も入力せずEnterを押して問題ありません。

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:

上記でEnterを３回押すと、以下のメッセージが表示され、公開鍵が作成されます。（randomart imageの箇所は適当に書き換えています）

Your identification has been saved in /home/ec2-user/.ssh/id_rsa.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:・・・・・・・・・・・・・・・・・・・・・・・・・・ 　……………@gmail.com
The key's randomart image is:
+---[RSA 2048]----+
|....................       |
| ..........        |
|   ......= ......       |
|    *..... .....        |
|   ...... BS+       |
|    =...........o..      |
ho
host github
|   .................       |
|    ......o*=.....＋       |
|    .E..........*......      |
+----[SHA256]-----+

その後、.sshディレクトリを確認すると、公開鍵が作成されているのがわかります。

$ ls ~/.ssh/
authorized_keys  id_rsa  id_rsa.pub  known_hosts

id_rsa.pubファイルの内容をコピー

下記コマンドでid_rsa.pubのファイル内容を表示し、中身をコピーします。
（lessコマンドで中身を見るのではなく、ファイルの中身をすべてコピーしてもＯＫ）

$ less ~/.ssh/id_rsa.pub

ファイル内の以下のssh-rsaから始まる部分をコピーします。（メールアドレスまでコピーに含めても含めなくても特に変わりないのでどちらでも構いません）

ssh-rsa ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・ [メールアドレス]

公開鍵をGitHubに登録

今コピーした部分を、GitHubに登録するのですが、まずGitHubにブラウザからアクセスし、右上の自分のプロフィール画像から「settings」をクリック

image2.png

そして、左側のメニューから「SSH and GPG keys」を選択し、「New SSH key」をクリックします。

image3.png

すると、登録画面が出てきます。
登録画面の「key」部分のテキストエリアに先ほどコピーした「ssh-rsa」から始まる文言を貼り付けます。
ちなみに、タイトルは何でも構いません。

image4.png

貼り付けができたら「Add SSH key」をクリック。

ここで、下記コマンドを打てば接続に成功できると書いている記事が多いですが、エラーが出て接続に失敗する場合もあります。

$ ssh -T git@github.com

configファイルの作成

接続に失敗する場合は、.sshのディレクトリ内に「config」というファイルを作成します。
vimで、ファイルの作成と中身の記述を行います。

$ vim ~/.ssh/config

configファイルの中身に、下記の文言を貼り付けます。
なお、IdentityFileの後のパスは、自身の「id_rsa」ファイルを格納しているパスに変えてください。

Host github github.com
  HostName github.com  IdentityFile ~/.ssh/id_rsa
  User git

新規作成ファイルの権限設定

作成できたら、権限設定をします。
新規でファイルを作成したので、適切な権限を設定し、適切に実行できるようにします。

作成した当初は、configファイルに何も権限がない状態。

しかし今回は、「所有者に読み取り権限があり、その他のユーザには権限がない」という状態にする必要があります。

そのため、権限は600か400にします。
（書き込み権限はあってもなくてもよいため）

所有者以外には権限を与えてはいけません。
600にするならば、以下を実行します。

$ chmod 600 ~/.ssh/config

ssh実行

そして、下記を実行。

$ ssh -T git@github.com

実行し、下記のような文字列が出力されたらOK！

Hi [username]! You've successfully authenticated, but GitHub does not provide shell access.

これで、git pushが可能になります。

最後に、git pushを行う

git pushで、ローカルレポジトリのファイル類をリモートレポジトリにアップロードできます。

$ git push origin master

これで完了です！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧