からの続き。 こっちは気を付けることはなさそうなので自分用にメモ。内容はｎ番煎じ。 githubにpushできたリポジトリをクローンするとこからやっていく。 使うコマンド一覧 git clone <githubリポジトリのパス> git branch <任意の名前> git checkout <移動先ブランチ名> git checkout <移動先ブランチ名> git branch git add <ファイル名> git commit -m <"メッセージ"> git push <リモートリポジトリ名> <ブランチ名> git pull git log 以下のコマンドを実行し、パスフレーズを打ち込むとクローン完了。 （なぜか今回はssh://なしでいけた。もうよくわからん） > git clone git@github.com:hemuwan/test.git Cloning into 'test'... Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': remote: Enumerating objects: 9, done. remote: Counting objects: 100% (9/9), done. remote: Compressing objects: 100% (3/3), done. remote: Total 9 (delta 0), reused 9 (delta 0), pack-reused 0 Receiving objects: 100% (9/9), done. ８．ブランチを作成する。 ブランチは枝分かれという意味。もとのデータからいくつも別軸を生み出し、並行して作業を行うのを枝が伸びる様子に例えられているんだとか。 git branch <任意の名前>コマンドを使う。 クローンで作成されたフォルダに移動し、ブランチを作成する。 名前は参考に倣って「feature1」としておく。 > cd test test > git branch feature1 作成した後、該当のブランチで作業するためにはブランチを移動しなければならない。 git checkout <移動先ブランチ名>コマンドで移動できる。 test> git checkout feature1 Switched to branch 'feature1' 名前を指定しないでgit branchコマンドを実行すると、現在のローカルリポジトリに存在するブランチが一覧で見れる。いまは「master」と「feature1」のみ。 作業中のブランチには頭に＊が表示される。 test>git branch * feature1 master ９．ブランチでコミットし、リモートリポジトリにプッシュ とりあえずなんか変化を加える。 新しいファイルでも作成してみる。 test> notepad branchtest.txt // 中身にブランチのテスト、と記述 新しく作成したファイルをローカルリポジトリにコミットし、リモートリポジトリにプッシュする。 以下のコマンドを実行していく。 test> git add branchtest.txt test> git commit -m "[Add] branchtest" [feature1 f73bcd7] [Add] branchtest 1 file changed, 1 insertion(+) create mode 100644 branchtest.txt test> git push origin feature1 Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 4 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 307 bytes | 307.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: Create a pull request for 'feature1' on GitHub by visiting: remote: https://github.com/hemuwan/test/pull/new/feature1 remote: To github.com:hemuwan/test.git * [new branch] feature1 -> feature1 初回の時とは違い、プッシュ先が「feature1」になっている点に注意。 コマンドを実行するとパスフレーズが求められ、入力すると上記のように「プルできたよー」と表示がされるはず。 githubを見にいくと、ブランチが追加されているのが確認できる。 １０．プルリクエスト（コードレビュー）、マージ ブランチでの作業が完了したら、メインとなるブランチ（たぶんmaster）に変更内容を取り込んでいく。これをマージという。 マージを行う際、github上ではプルリクエストと呼ばれる機能を使い、コードレビューを行うことができる。 githubを開き、Pull requestsタブからNew pull requestボタンを押下。 マージ元（base:master）とマージ先（compare:feature1）のブランチを選択 （元と先の関係逆か？　とりあえず矢印に従えばよいか） 変更点確認 Create pull requestボタンを押下。 依頼のコメント書いたり、右上のレビュアーを設定したり 準備できたら再びCreate pull requestボタンを押下。 （draftなんちゃらは下書き的なやつか。準備できてないとマージできないよとのこと） １１．レビューの実施 プルリクエストを受け取ったら「Pull requests」タブを開き、「File changed」から内容を確認。 訂正がある場合などは、該当の行にマウスホバーすると「＋」がでるので、クリックするとコメント追加の領域が現れる。何かほかにもいろいろ機能あるっぽい。すごいなんとなくでやってる。 とりあえず突っ返してみる。 コメント記入 > start a review 押下。 右上のボタンFinish your reviewを押下すると、コメントを書く欄と、以下のラジオボタンが出る。（右は翻訳内容） comment コメント：明示的な承認なしに一般的なフィードバックを送信します。 Approve 承認：フィードバックを送信し、これらの変更のマージを承認します。 Request changes 変更をリクエストする：マージする前に対処する必要があるフィードバックを送信します。 Approveは内容OKだよーで、Request changesはこれさえ直せばOKで、commentがごめんやり直して―ってことかな。 とりあえず、commentでSubmit review押下。 conversationタブに以下の表示が。 こうやって、作業者と承認者がやり取りしていくのかな。 返事うったりスタンプ押したりもできる。 とりあえず直せと言われたの出なおします。 ふたたびローカルリポジトリ更新。 git add .コマンド。.で現在のディレクトリを表し、ディレクトリ全体の変更を反映できる。 test> git add . test> git commit -m "[Update]文修正" [feature1 24ba4a9] [Update] 文修正 1 file changed, 2 insertions(+), 1 deletion(-) んでもう一回pushかな。（手探り） test> git push origin feature1 Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 353 bytes | 353.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:hemuwan/test.git f73bcd7..24ba4a9 feature1 -> feature1 githubを開くとなんか増えてる。 またNew pull requestかな。 View pull requestボタンを押下。 続きにコメントかけるっぽい。 OKのコメント残しとく。 （今気づいたけどpull request出した本人は承認押せないっぽい。） 過去の修正依頼は完了したのち、Resolve conversationボタンを押すと表示を消せる。 問題なくなったのでいよいよマージ。 ConversationタグのMarge pull requestを押下。 コメントはよくわからんのでそのままcomfirm marge マージできたで。ブランチfeature1は完全に消せるでというメッセージ。 masterのブランチを見てみると、feature1ブランチで作成したbranchtest.txtが追加されている。 マージできたあ！ぐっだぐだ。 １２．ローカルリポジトリからプル。 リモートリポジトリのmasterブランチにマージはできたが、自分自身のPCの中のローカルリポジトリ上のmasterにはマージの内容が反映されていない。 マージした内容をローカルリポジトリのmasterに取得し、最適化するにはローカルでmasterブランチに切り替え、git pullコマンドを実行すればよい。 test> git checkout master test> git branch feature1 * master test> dir //test.txtしかないことを確認 test> git pull Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), 624 bytes | 10.00 KiB/s, done. From github.com:hemuwan/test 6ca8868..46d8a35 master -> origin/master Updating 6ca8868..46d8a35 Fast-forward branchtest.txt | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 branchtest.txt パスフレーズを入力するとなんやかんや入ってきそうな流れ。 ファイルを確認すると、マージした「branchtest.txt」がある。 test> dir test.txt branchtest.txt git logコマンドでこれまでの編集履歴を見れる。 test>git log commit 46d8a35b3fb8ーーコミットハッシュ (HEAD -> master, origin/master, origin/HEAD) Merge: 6ca8868 24ba4a9 Author: hemuwan <61411705+hemuwan@users.noreply.github.com> Date: Fri Oct 22 13:09:04 2021 +0900 Merge pull request #1 from hemuwan/feature1 [Add] branchtest commit 24ba4a966e0faーーコミットハッシュ (origin/feature1, feature1) Author: hemuwan <メアド> Date: Fri Oct 22 12:46:26 2021 +0900 [Update] 文修正 ~以下省略、抜けるときはQキーで~ ながかったがとりあえずここで一区切り。 ひとまずこれでチームによる開発も可能になったかなと。 あとは一緒に開発してくれる友達を見つけるべし。

からの続き。 こっちは気を付けることはなさそうなので自分用にメモ。内容はｎ番煎じ。 githubにpushできたリポジトリをクローンするとこからやっていく。 使うコマンド一覧 git clone <githubリポジトリのパス> git branch <任意の名前> git checkout <移動先ブランチ名> git branch git add <ファイル名> git commit -m <"メッセージ"> git push <リモートリポジトリ名> <ブランチ名> git pull git log 以下のコマンドを実行し、パスフレーズを打ち込むとクローン完了。 （なぜか今回はssh://なしでいけた。もうよくわからん） > git clone git@github.com:hemuwan/test.git Cloning into 'test'... Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': remote: Enumerating objects: 9, done. remote: Counting objects: 100% (9/9), done. remote: Compressing objects: 100% (3/3), done. remote: Total 9 (delta 0), reused 9 (delta 0), pack-reused 0 Receiving objects: 100% (9/9), done. ８．ブランチを作成する。 ブランチは枝分かれという意味。もとのデータからいくつも別軸を生み出し、並行して作業を行うのを枝が伸びる様子に例えられているんだとか。 git branch <任意の名前>コマンドを使う。 クローンで作成されたフォルダに移動し、ブランチを作成する。 名前は参考に倣って「feature1」としておく。 > cd test test > git branch feature1 作成した後、該当のブランチで作業するためにはブランチを移動しなければならない。 git checkout <移動先ブランチ名>コマンドで移動できる。 test> git checkout feature1 Switched to branch 'feature1' 名前を指定しないでgit branchコマンドを実行すると、現在のローカルリポジトリに存在するブランチが一覧で見れる。いまは「master」と「feature1」のみ。 作業中のブランチには頭に＊が表示される。 test>git branch * feature1 master ９．ブランチでコミットし、リモートリポジトリにプッシュ とりあえずなんか変化を加える。 新しいファイルでも作成してみる。 test> notepad branchtest.txt // 中身にブランチのテスト、と記述 新しく作成したファイルをローカルリポジトリにコミットし、リモートリポジトリにプッシュする。 以下のコマンドを実行していく。 test> git add branchtest.txt test> git commit -m "[Add] branchtest" [feature1 f73bcd7] [Add] branchtest 1 file changed, 1 insertion(+) create mode 100644 branchtest.txt test> git push origin feature1 Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 4 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 307 bytes | 307.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: Create a pull request for 'feature1' on GitHub by visiting: remote: https://github.com/hemuwan/test/pull/new/feature1 remote: To github.com:hemuwan/test.git * [new branch] feature1 -> feature1 初回の時とは違い、プッシュ先が「feature1」になっている点に注意。 コマンドを実行するとパスフレーズが求められ、入力すると上記のように「プルできたよー」と表示がされるはず。 githubを見にいくと、ブランチが追加されているのが確認できる。 １０．プルリクエスト（コードレビュー）、マージ ブランチでの作業が完了したら、メインとなるブランチ（たぶんmaster）に変更内容を取り込んでいく。これをマージという。 マージを行う際、github上ではプルリクエストと呼ばれる機能を使い、コードレビューを行うことができる。 githubを開き、Pull requestsタブからNew pull requestボタンを押下。 マージ元（base:master）とマージ先（compare:feature1）のブランチを選択 （元と先の関係逆か？　とりあえず矢印に従えばよいか） 変更点確認 Create pull requestボタンを押下。 依頼のコメント書いたり、右上のレビュアーを設定したり 準備できたら再びCreate pull requestボタンを押下。 （draftなんちゃらは下書き的なやつか。準備できてないとマージできないよとのこと） １１．レビューの実施 プルリクエストを受け取ったら「Pull requests」タブを開き、「File changed」から内容を確認。 訂正がある場合などは、該当の行にマウスホバーすると「＋」がでるので、クリックするとコメント追加の領域が現れる。何かほかにもいろいろ機能あるっぽい。すごいなんとなくでやってる。 とりあえず突っ返してみる。 コメント記入 > start a review 押下。 右上のボタンFinish your reviewを押下すると、コメントを書く欄と、以下のラジオボタンが出る。（右は翻訳内容） comment コメント：明示的な承認なしに一般的なフィードバックを送信します。 Approve 承認：フィードバックを送信し、これらの変更のマージを承認します。 Request changes 変更をリクエストする：マージする前に対処する必要があるフィードバックを送信します。 Approveは内容OKだよーで、Request changesはこれさえ直せばOKで、commentがごめんやり直して―ってことかな。 とりあえず、commentでSubmit review押下。 conversationタブに以下の表示が。 こうやって、作業者と承認者がやり取りしていくのかな。 返事うったりスタンプ押したりもできる。 とりあえず直せと言われたの出なおします。 ふたたびローカルリポジトリ更新。 git add .コマンド。.で現在のディレクトリを表し、ディレクトリ全体の変更を反映できる。 test> git add . test> git commit -m "[Update]文修正" [feature1 24ba4a9] [Update] 文修正 1 file changed, 2 insertions(+), 1 deletion(-) んでもう一回pushかな。（手探り） test> git push origin feature1 Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 353 bytes | 353.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:hemuwan/test.git f73bcd7..24ba4a9 feature1 -> feature1 githubを開くとなんか増えてる。 またNew pull requestかな。 View pull requestボタンを押下。 続きにコメントかけるっぽい。 再びレビュー者視点。 問題ないのでOKのコメント残しとく。 （今気づいたけどpull request出した本人は承認押せないっぽい。） 過去の修正依頼は完了したのち、Resolve conversationボタンを押すと表示を消せる。 問題なくなったのでいよいよマージ。 ConversationタグのMarge pull requestを押下。 コメントはよくわからんのでそのままcomfirm marge マージできたで。ブランチfeature1は完全に消せるでというメッセージ。 （ブランチはgit branch -d <ブランチ名>で消せる。マージしたら消すものらしい） masterのブランチを見てみると、feature1ブランチで作成したbranchtest.txtが追加されている。 マージできたあ！ぐっだぐだ。 １２．ローカルリポジトリからプル。 リモートリポジトリのmasterブランチにマージはできたが、自分自身のPCの中のローカルリポジトリ上のmasterにはマージの内容が反映されていない。 マージした内容をローカルリポジトリのmasterに取得し、最適化するにはローカルでmasterブランチに切り替え、git pullコマンドを実行すればよい。 test> git checkout master test> git branch feature1 * master test> dir //test.txtしかないことを確認 test> git pull Enter passphrase for key '/c/Users/hemuwan/.ssh/id_rsa': remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), 624 bytes | 10.00 KiB/s, done. From github.com:hemuwan/test 6ca8868..46d8a35 master -> origin/master Updating 6ca8868..46d8a35 Fast-forward branchtest.txt | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 branchtest.txt パスフレーズを入力するとなんやかんや入ってきそうな流れ。 ファイルを確認すると、マージした「branchtest.txt」がある。 test> dir test.txt branchtest.txt git logコマンドでこれまでの編集履歴を見れる。 test>git log commit 46d8a35b3fb8ーーコミットハッシュ (HEAD -> master, origin/master, origin/HEAD) Merge: 6ca8868 24ba4a9 Author: hemuwan <61411705+hemuwan@users.noreply.github.com> Date: Fri Oct 22 13:09:04 2021 +0900 Merge pull request #1 from hemuwan/feature1 [Add] branchtest commit 24ba4a966e0faーーコミットハッシュ (origin/feature1, feature1) Author: hemuwan <メアド> Date: Fri Oct 22 12:46:26 2021 +0900 [Update] 文修正 ~以下省略、抜けるときはQキーで~ ながかったがとりあえずここで一区切り。 ひとまずこれでチームによる開発も可能になったかなと。 あとは一緒に開発してくれる友達を見つけるべし。

はじめに リモートにGitHubを、GUIクライアントにSourceTreeを使用した場合の、個人アクセストークンによるGitHubへのアクセスする方法です。 以下の記事を参考に初回の設定をしたところ、どうにも認証に失敗してしまいうまくいきません。 そこで、以下にできるようになった方法を残しておきます。 下準備 個人アクセストークンを取得しておきます。 GitHub上でプライベートリポジトリを作成します。この時に、readme.mdを追加しておくことでクローンできるようにします。 手順 Source Treeでプライベートリポジトリをクローンします。 以下の画面が出るので個人アクセストークンを入れてSign inします。 リポジトリが正しく認識でき、クローン出来たら成功です。 注意事項 パブリックリポジトリをクローンしようとした場合はサインインの画面が出ないと思われる（未確認）ので、プライベートリポジトリをクローンしてください。 おわりに 初めてSource Treeを使う際に、個人アクセストークンの登録をできなかったため書きました。 読んでくださった方々の参考になると幸いです。

概要 「ビルドを自動化したい」といった理由のため、ひとつの端末で、複数のgithubアカウントを使いたいことがあります。その場合、githubに対して複数のssh鍵でアクセスすることになります。その設定方法について説明します。 ここではUNIX系端末(macOS含む)での利用を前提とします。 なぜ複数のssh鍵が必要なのか githubにssh経由でアクセスするには、githubに対し事前に自分のssh公開鍵を設定しておく必要があります。 普段とは別の、もうひとつのgithubアカウントでssh経由でアクセスする場合も、githubに対し、事前に自分の別のssh公開鍵を設定しておく必要があります。なぜなら、他のgithubアカウントに既に設定されているssh公開鍵は、別のアカウントへの設定であろうとも、もはやgithubには登録できないからです。言い換えれば、githubに登録するssh公開鍵は、githubの全ユーザに対しユニークな必要があります。 別のssh鍵を作る というわけで、普段づかいとは別のssh鍵を作りましょう。 以下、hogeなんたらと書かれている部分は、あなたが扱おうとしているプロジェクトの名称などに適宜読み替えてください。 鍵の暗号アルゴリズムはed25519を使いましょう。早くて強いです。ただし(後述) 何のため作った鍵なのか後でわかるよう、きちんとコメントを付けましょう。 既存の鍵とは別のファイル名も指定します。 パスフレーズはなし(空文字列)でok sh ssh-keygen -t ed25519 -C 'ssh key for hogeproj' -f hogeproj-key-ed25519 -N '' ただし、iOSアプリの開発などで、Xcodeに含まれているgit機能も使いたい場合は要注意。Xcodeはed25519鍵に対応していません。Xcode 13でもだめです。Xcodeのメニューからgit使いたい場合は、残念ながらRSA暗号を使いましょう。ビット数はせめて4096にしておきます。 sh ssh-keygen -t rsa -b 4096 -C 'ssh key for hogeproj' -f hogeproj-key-rsa4096 -N '' 私は、Xcodeメニューのgit機能は使わず、shellから単体のオリジナルのgitコマンドのほうを使うことにしたので、ed25519鍵のほうで進めます。 これで、~/.sshの中に、ssh秘密鍵hogeproj-key-ed25519とssh公開鍵hogeproj-key-ed25519.pubが作られました。 念のため、~/.ssh自体はパーミッション700, hogeproj-key-ed25519はパーミッション600, hogeproj-key-ed25519.pubはパーミッション644になっていることも確認しておきましょう。 これらのファイルは、安全なところにバックアップもしておきましょう。私は1passwordの保管庫に入れました。 githubにssh公開鍵をセットする github.comに、もう一つのアカウントのほうでログインしておき、SSH and GPG keysにアクセスし、SSH keysのセクションで、New SSH Keyをクリックします。 Titleには、何のための鍵なのかの説明を記入。上の例にならうとssh key for hogeprojなど。 Keyには、ssh公開鍵の「中身」をそのままペーストします。 Add SSH Keyをクリックして登録します。 登録しようとする内容はgithubがわもきちんとチェックしてくれますし、おかしい場合はエラーを返してくれますので、うまくいかなかった場合はエラー内容をきちんと読みましょう。 ~/.ssh/configを設定 git cloneするとき、使うssh鍵もオプション指定できたなら、本当は便利なのです。たとえばgit clone -i ~/.ssh/hogeproj-key-ed25519 git@github.com:hogerepos/hogesrc.gitといった感じに。 でも残念ながら、gitコマンド自体には、複数のssh鍵を使い分けるための機能はありません。 いま実行するこのgitではsshオプションはこうしてほしい、といった指定を、環境変数やオプションで与えることはできるのですが、これはあくまでも一時的な指定です。後日またここでgit pullなどするときには、もうその指定は効きません。「こんなリポジトリないぜ? 何いってんの?」といった感じのエラーになってしまいます。 ではどうするか。~/.ssh/configに、「このホストにsshするときはこの鍵を使う」という指定を入れる方法がいちばん増しです。~/.ssh/configをエディタで開き、以下を追記します。 Host hogeremote Hostname github.com User git IdentityFile ~/.ssh/hogeproj-key-ed25519 これで、hogeremoteという(仮想的な)ホストにsshする場合は、本当にsshアクセスすべきホストはgithub.comで、sshユーザはgitで、秘密鍵は~/.ssh/hogeproj-key-ed25519を使うんだよ、というルールを定義できました。 git cloneする git cloneしてみましょう。github.comの対象リポジトリにアクセスし、SSHを用いたclone urlを入手します。 clone urlは、通常git@github.com:hogerepos/hogesrc.git といった書式になっています。 このgithub.comの部分を、さきほど~/.ssh/configで定義した、仮想的なホストhogeremoteに置き換えます。cloneしてみましょう。 sh git clone git@hogeremote:hogerepos/hogesrc.git こうしてcloneしたフォルダの中では、今後は、普通にgitコマンドを使うだけで、専用githubアカウントと専用ssh鍵が自動的に使われます。専用githubアカウントと専用ssh鍵を使っていることすら忘れていられます。

概要 「ビルドを自動化したい」といった理由のため、ひとつの端末で、複数のgithubアカウントを使いたいことがあります。その場合、githubに対して複数のssh鍵でアクセスすることになります。その設定方法について説明します。 ここではUNIX系端末(macOS含む)での利用を前提とします。 なぜ複数のssh鍵が必要なのか githubにssh経由でアクセスするには、githubに対し事前に自分のssh公開鍵を設定しておく必要があります。 普段とは別の、もうひとつのgithubアカウントでssh経由でアクセスする場合も、githubに対し、事前に自分の別のssh公開鍵を設定しておく必要があります。なぜなら、他のgithubアカウントに既に設定されているssh公開鍵は、別のアカウントへの設定であろうとも、もはやgithubには登録できないからです。言い換えれば、githubに登録するssh公開鍵は、githubの全ユーザに対しユニークな必要があります。 別のssh鍵を作る というわけで、普段づかいとは別のssh鍵を作りましょう。 以下、hogeなんたらと書かれている部分は、あなたが扱おうとしているプロジェクトの名称などに適宜読み替えてください。 鍵の暗号アルゴリズムはed25519を使いましょう。早くて強いです。ただし(後述) 何のため作った鍵なのか後でわかるよう、きちんとコメントを付けましょう。 既存の鍵とは別のファイル名も指定します。 パスフレーズはなし(空文字列)でok sh ssh-keygen -t ed25519 -C 'ssh key for hogeproj' -f hogeproj-key-ed25519 -N '' ただし、iOSアプリの開発などで、Xcodeに含まれているgit機能も使いたい場合は要注意。Xcodeはed25519鍵に対応していません。Xcode 13でもだめです。Xcodeのメニューからgit使いたい場合は、残念ながらRSA暗号を使いましょう。ビット数はせめて4096にしておきます。 sh ssh-keygen -t rsa -b 4096 -C 'ssh key for hogeproj' -f hogeproj-key-rsa4096 -N '' 私は、Xcodeメニューのgit機能は使わず、shellから単体のオリジナルのgitコマンドのほうを使うことにしたので、ed25519鍵のほうで進めます。 これで、~/.sshの中に、ssh秘密鍵hogeproj-key-ed25519とssh公開鍵hogeproj-key-ed25519.pubが作られました。 念のため、~/.ssh自体はパーミッション700, hogeproj-key-ed25519はパーミッション600, hogeproj-key-ed25519.pubはパーミッション644になっていることも確認しておきましょう。 これらのファイルは、安全なところにバックアップもしておきましょう。私は1passwordの保管庫に入れました。 githubにssh公開鍵をセットする github.comに、もう一つのアカウントのほうでログインしておき、SSH and GPG keysにアクセスし、SSH keysのセクションで、New SSH Keyをクリックします。 Titleには、何のための鍵なのかの説明を記入。上の例にならうとssh key for hogeprojなど。 Keyには、ssh公開鍵の「中身」をそのままペーストします。 Add SSH Keyをクリックして登録します。 登録しようとする内容はgithubがわもきちんとチェックしてくれますし、おかしい場合はエラーを返してくれますので、うまくいかなかった場合はエラー内容をきちんと読みましょう。 ~/.ssh/configを設定 git cloneするとき、使うssh鍵もオプション指定できたなら、本当は便利なのです。たとえばgit clone -i ~/.ssh/hogeproj-key-ed25519 git@github.com:hogerepos/hogesrc.gitといった感じに。 でも残念ながら、gitコマンド自体には、複数のssh鍵を使い分けるための機能はありません。 いま実行するこのgitではsshオプションはこうしてほしい、といった指定を、環境変数やオプションで与えることはできるのですが、これはあくまでも一時的な指定です。後日またここでgit pullなどするときには、もうその指定は効きません。「こんなリポジトリないぜ? 何いってんの?」といった感じのエラーになってしまいます。 ではどうするか。~/.ssh/configに、「このホストにsshするときはこの鍵を使う」という指定を入れる方法がいちばん増しです。~/.ssh/configをエディタで開き、以下を追記します。 Host hogeremote Hostname github.com User git IdentityFile ~/.ssh/hogeproj-key-ed25519 これで、hogeremoteという(仮想的な)ホストにsshする場合は、本当にsshアクセスすべきホストはgithub.comで、sshユーザはgitで、秘密鍵は~/.ssh/hogeproj-key-ed25519を使うんだよ、というルールを定義できました。 git cloneする git cloneしてみましょう。github.comの対象リポジトリにアクセスし、SSHを用いたclone urlを入手します。 clone urlは、通常git@github.com:hogerepos/hogesrc.git といった書式になっています。 このgithub.comの部分を、さきほど~/.ssh/configで定義した、仮想的なホストhogeremoteに置き換えます。cloneしてみましょう。 sh git clone git@hogeremote:hogerepos/hogesrc.git こうしてcloneしたフォルダの中では、今後は、普通にgitコマンドを使うだけで、専用githubアカウントと専用ssh鍵が自動的に使われます。専用githubアカウントと専用ssh鍵を使っていることすら忘れていられます。

はじめに 今更ながら、GitHubを使い始めた。 GitHubを使い始めたときに参考にさせていただいた記事をまとめておく。 トラブルシューティング等を自分でまとめようと思ったが、皆様がまとめていただいた記事で、ほぼ何のトラブルもなく使い始められた。 今後も、GitHubを使いながら、参照させていただいた有益な記事等を随時整理していく。 参照記事 チュートリアル トラブルシューティング これから参照させていただこうと思っている記事 MS Officeファイルの管理 論文執筆 謝辞 記事を執筆していただいている皆様に感謝申し上げます。