はじめに

私が午前中を溶かした、git fetchでハマった話を忘備録を兼ねて記載する。

発生した事象

git fetchしても新規作成したブランチ名が表示されない事象に遭遇した。

具体的には、以下のように作業を進めていた。
①リモートリポジトリをローカルにクローン
②リモートリポジトリで新規ブランチを作成
③クローン済みのローカルリポジトリに②で作成したブランチをチェックアウト

この際、③にてブランチのチェックアウトをしようと、
git fetchでリモートブランチの情報取得後、
git branch -aでリモートブランチを確認したが、新規作成したリモートブランチ名が表示されない。
そのため、チェックアウトも出来ずハマってしまった。

原因

./git/config内のfetch対象の指定が、以下のようにブランチ毎になっていた。

[remote "origin"]
    url = https://hogehohehoge
    fetch = +refs/heads/hoge:refs/remotes/origin/hoge
    fetch = +refs/heads/hoge2:refs/remotes/origin/hoge2

解決方法

以下のように、fetch対象のbranchをリモート全体に指定する事で、
クローン後に新規作成した時にも情報を取得してくれるようになった。

[remote "origin"]
    url = https://hogehohehoge
    fetch = +refs/heads/*:refs/remotes/origin/*

参考文献

こちらのページに大変助けられました。ありがとうございます…！

『Git』10.5 Gitの内側 - Refspec
https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%86%85%E5%81%B4-Refspec

githubコマンド一覧

Qiitaの練習と、自分用メモを兼ねてgithubコマンド一覧を作成

• git init 　カレントディレクトリをGitで管理できるようになる
• git status　ワークツリーとインデックスの現在の状態を確認
• git add　ファイルをインデックスに追加
• git commit　インデックスに登録されたのをローカルリポジトリにコミット。-mをつけることで一文のメッセージを付けれる。何もなしだと文章
• git diff　現在のインデックスとワークツリーの差分確認
• git log　コミットの履歴確認
• git reset [識別番号]　前に戻す　git reset HEAD^で1つ前に。
• git push origin [branchname] リモートリポジトリへ反映
• git branch [name]　[name]にブランチの名前を指定してブランチを作成（何も指定しないとブランチの一覧を表示できる。*←これが左についているところが現在のブランチ
• git checkout [name]　　[name]にブランチの名前を指定することでブランチを切り替えられる。

ブランチ

履歴を分岐して記録できるようになる。そうすることで他のブランチの影響を受けないので、同時に複数の変更を進められる。

100日後に1人前になる新人エンジニア(2日目)

早くもエンジニアとして働いて2日が過ぎました。

こちらは昨日の記事ですよかったらどうぞ
100日後に1人前になる新人エンジニア(1日目)

少しずつ業務に慣れてチームに貢献していきたい！！という気持ちと、
自分は何にもわかってないんだなという気持ちを持ちつつ
2日目の記事を書いていきます。

今日やったこと

・フォームの改善
・viewの改善　の2つでした

issueに対してコードを書いてGitHubにプルリクエストを送る
という流れでした。

今日の最も苦戦した部分はGit（もちろん他にも苦戦はしたけど）

そもそも1人で開発していた時はほとんどGitを使っていなかったので、
チームとして働き始めて覚えていかねばと思っています。

ちなみにgitを作った人はLinuxを作った人と一緒なんだね
天才かよ。

ということで今日はGitについてフォーカス

Gitあれこれ

gitはバージョンを管理するシステムだよ。
これによってバージョンを行き来したり修正したりできるよ。

基本的なGitコマンド

git init            #リポジトリを初期化
git status          #リポジトリの状態を確認 addされていないファイルを確認できるよ
git add (ファイル指定) #ステージ領域にファイルを追加
git commit          #リポジトリの歴史として記録
git log             #コミットログを確認。いつ誰がコミットやマージをしたのか
git log -p          #コミットで行われた差分を確認
git diff            #addされていないファイルとコミットされているものの差分を表示

とても簡単だけどこんな感じgit commitは -mのオプションで一行のコメント
オプションなしでは長いコメントが可能だよ。

Branch

枝分かれとか支店とかそうゆう意味がありますよね。
作業を分岐させることでそれぞれ独立した作業を行えるってことですね。

git branch            #ブランチの一覧と現在のブランチを表示
git checkout -b hoge  #hogeブランチを作成してhogeブランチに切り替える
git checkout master   #masterブランチに切り替える

ブランチに関してはまた今度しっかりまとめたいと思います。

GitHubプルリクエスト

実際に書いたコードを他人にレビューしてもらう機能
これはGitの機能ではなくGitHubの提供している機能

この機能ができたからこそSocial codingつまり閉ざされた世界ではなく
真の意味で開かれた状態でコードを共有することができるようになった！！
って本に書いてありました

gitコマンドを参考にして
git add　→ git commit → git push origin branch名
でプッシュをした後にGitHubでプルリクエストをかけばOK！
ここはコードとかではなくGitHubの使い方なので省略。

今日のさいごに

できないことしかないので
できるようになった喜びも多いはず。
楽しみながら成長を。
ちなみに土日もちゃんと更新していきます。

１人前のエンジニアになるまであと98日

前提

さっきコミットしたファイルの記述を一部間違えたので訂正してコミットをやり直したい時。
pushしていないことが前提。git push -fは強制的にpushできるが履歴が壊れてしまうのでNG。

A：直前のコミットをやり直す

①　ファイルを修正する）
②　git add .
③　% git commit --amend
(vim立ち上がりコメントを修正)

• 上記が終わったら、念のためgit --oneline log -p -n 3などでうまくいってるか確認。

• 【vimの使い方】
  iと打つと入力できるようになる→コメント入力やEscキーで切り替え→:wqと入力。

• コメントも修正したい場合はここで修正できる。

B:何個か前のコミットをやり直す

①　% git rebase -i コミットID
②　ファイル修正
③　％　git add ファイル名
④　% git commit --amend
(vim立ち上がりコメントを修正)
⑤　% git rebase --continue

①について

例えば、直前３つのコミットをやり直すときは、

$ git rebase -i HEAD~3

すると下記のようにvimが立ち上がる。

例えば、この３つのファイルのうちfirst.htmlを修正したいならpickをeditに変更しEscキーで切り替え→:wqで閉じる。変更したくないファイルはpickのままにする。

②について

エディタで修正したいファイル（ここではfirst.html）を開き、正しく修正し保存。

③、④のコマンドを入力

【vimの使い方】
iと打つと入力できるようになる→コメント入力やEscキーで切り替え→:wqと入力。

コメントも修正したい場合はここで修正できる。

これでfirst.htmlの修正は終了。

⑤について

次のコミット修正に進むためにgit rebase --continue入力。

①の時点で３つのファイルのうち他のsocond.htmlとthird.htmlはpickにしてたのでこのまま終了となる。もし他のファイルもeditにしていた場合はvimが立ち上がり同じ手順を繰り返す。

念のためgit --oneline log -p -n 3などでうまくいってるか確認。

参考文献：Udemy　もう怖くないGit!チーム開発で必要なGitを完全マスター (山浦 清透)

前提

さっきコミットしたファイルの記述を一部間違えたので訂正してコミットをやり直したい時。
pushしていないことが前提。

A：直前のコミットをやり直す

①　(ファイルを修正する）
②　% git add .
③　% git commit --amend
(vim立ち上がりコメントを修正)

• 上記が終わったら、念のためgit --oneline log -p -n 3などでうまくいってるか確認。

• 【vimの使い方】
  iと打つと入力できるようになる→コメント入力やEscキーで切り替え→:wqと入力。

• コメントも修正したい場合はここで修正できる。

B:何個か前のコミットをやり直す

①　% git rebase -i コミットID
②　ファイル修正
③　% git add ファイル名
④　% git commit --amend
(vim立ち上がりコメントを修正)
⑤　% git rebase --continue

①について

例えば、直前３つのコミットをやり直すときは、

% git rebase -i HEAD~3

すると下記のようにvimが立ち上がる。

例えば、この３つのファイルのうちfirst.htmlを修正したいならpickをeditに変更しEscキーで切り替え→:wqで閉じる。変更したくないファイルはpickのままにする。

②について

エディタで修正したいファイル（ここではfirst.html）を開き、正しく修正し保存。

③、④のコマンドを入力

【vimの使い方】
iと打つと入力できるようになる→コメント入力やEscキーで切り替え→:wqと入力。

コメントも修正したい場合はここで修正できる。

これでfirst.htmlの修正は終了。

⑤について

次のコミット修正に進むためにgit rebase --continue入力。

①の時点で３つのファイルのうち他のsocond.htmlとthird.htmlはpickにしてたのでこのまま終了となる。もし他のファイルもeditにしていた場合はvimが立ち上がり同じ手順を繰り返す。

念のためgit --oneline log -p -n 3などでうまくいってるか確認。

参考文献：Udemy　もう怖くないGit!チーム開発で必要なGitを完全マスター (山浦 清透)

はじめに

「就職してから困る前にGitの最低限の知識を付けておこう」

最近になってそう思って、個人で使い始めました。

チーム開発で使うものというイメージですが、
個人で開発や制作してても非常に役に立つので早めに使い慣れることをお勧めします！

まずは初歩的な機能でいいので使ってみるだけで意識が変わると思います。

ということで
「まだGitを使ったことがない。」
「これから使いたい」

そういった方々に向けて
とりあえず使ってみるまでの進め方を書いていきます。
自分の復習、メモ代わりの為でもあります！

ターミナルを開く

Gitは基本的にターミナルで扱います。（Windowsはコマンドプロンプト）
ターミナルの開き方は以下になります。

Mac

command + Spaceで検索から「ターミナル」と入力。
もしくはFinder→アプリケーションフォルダ→ユーティリティフォルダ内

Windows

スタートメニューの検索で「cmd.exe」と入力。

ユーザー情報を登録

Gitを使うにはまずユーザーの名前とメールアドレスの登録が必要です。
一度登録すれば以降は必要ありません。

$ git config --global user.name "任意の名前"
$ git config --global user.email "登録したいメールアドレス"

これで登録が完了してGitを使う準備ができました！

ディレクトリを新規作成

$ cd desktop #「cd 場所」で作成したい場所に移動
$ mkdir practice #「mkdir ディレクトリ名」で新規ディレクトリ作成
$ cd practice #作成したディレクトリを指定
$ git init #ディレクトリ初期化

これでgitによるバージョン管理を開始できます！

ディレクトリに新規ファイルを作成しGitの追跡を開始

$ echo "hello world" > hello.html #新規ファイル作成
$ git add hello.html #ステージングエリアにhello.html追加
$ git status #new file: hello.htmlと表示すればOK

新規ファイル作成はディレクトリから直接作成しても問題ありません。
元々ファイルがあればいきなりgit addからでOKです。
ここではまずGitの追跡を開始するファイルを決めてください。

ステージングエリアって何？

Gitでは主に
「ワーキングディレクトリ」「ステージングエリア」「リポジトリ」
3つのエリアに分かれていてそれぞれコマンドで移動できます。

ワーキングディレクトリ

git add

ステージングエリア

git commit

リポジトリ

git addすることで「ワーキングディレクトリ」から「ステージングエリア」へ移動します。

移動したファイルはcommitできるようになります。

ステージングエリアへ置くことによってセーブ(commit)したいファイルを選べるようになり、

余計な記録を増やさず、管理や作業をしやすくなります。

個人で使う分にはあまり意識せずadd→commitとすぐ保存してしまっても大丈夫です！

まとめてgit addしたい！

$ git add --all #全てステージングエリアへ追加

一度に複数のファイルで作業して指定するのが大変な時は使います。

commitする

$ git commit -m "first commit" #git add -m "コミットメッセージ"

これでコミットができました！
コミットされたファイルはリポジトリに保存されます。

コミットメッセージって何？

重要な要素なのでしっかり書きましょう。

コミットメッセージを書かなければGitにコミットができません！

コミットメッセージは自分や他人が「今回の修正で何を行ったか」を示しておくものです。

わかりやすい表現を心がけましょう。

そもそもコミットって何？

コミットとは追加や変更したファイルをリポジトリという保存場所に登録することです。

コミットすることでログに記録されていきます。

コミットはステージングエリアに対してのみ実行されます。

git addで追加してからコミットを行って下さい！

コミットするタイミングは自由ですが、

• 一つのタスクが完了した時
• 一日の作業の終わり

などを私は目安にしています。

ログを確認する

こちらのコマンドでコミットのログを表示します。

$git log

以下がコミットのログです。

commit [コミットのハッシュ値（識別IDのようなもの）] (HEAD -> master)
Author: [登録ユーザー] <mailadoress@example.com>
Date:   [コミットした日時]

    first commit #コミットメッセージ

作業を元に戻したい！

何か失敗して上手く動かなくなった時に編集内容を元に戻したい。

個人で使う機能はこれが多いと思うので最後に紹介します。

$ git checkout . #ステージング前の変更内容に戻します。

.で全てを指定。任意のファイル名でも指定可能です。
「ステージング前」とはaddする前の状態と考えて下さい。

---

$ git checkout HEAD -- ファイル名 #ステージ後のファイルを最後にコミットした状態に戻す

最後にコミットした状態からの編集内容を取り消します。

---

$ git reset --hard HEAD #編集とステージングの変更を取り消し最後にコミットした状態に戻す

作業ディレクトリが未保存でも強制で上書きされます。

おわりに

これで始め方はわかっていただけたと思います。

他にもブランチやGitHubと連携しPushするなどGitには様々な機能があります。

これでご興味を持っていただけたらどんどん色んな機能を使ってみて下さい。

私もまだ使い出したばかりなのでこれから慣れていきたいと思ってます。

一緒にがんばってGitを極めましょう！

Links

やりたいことが今すぐわかる 逆引きGit入門
Gitのコミットメッセージの書き方
[git] 戻したい時よく使っているコマンドまとめ

なんでハマったのか

まず、この話の発端ですが、プログラミングスクールのカリキュラムに沿って作った公開鍵、秘密鍵の名前がデフォルトのid_rsaで、githubの登録名がpracticeとかなんとか。

すごくこだわりの強い性格が災いして
・秘密鍵・公開鍵にちゃんと名前をつけてあげたい！
・github上の登録名もしっかりしたい
と思い立って、作り直し、名前を変えたところエラー頻発。

かなりチームメンバーに迷惑をかけてしまいました…
同じようなこだわりの強い性格の人の助けになれたらと思い、メモしておきます。

要約

１．鍵に名前をつけるときは

Enter file in which to save the key (/Users/you/.ssh/id_rsa):
/Users/自分のPCのユーザ名/.ssh/つけたい名前

と絶対パスでつけてあげる

２．gitの仕様上、リモートリポジトリに接続するとき、デフォルトの
id_rsaを探しに行ってしまうので、ssh鍵と同じフォルダに

config

Host github.com
  HostName github.com
  User git
  Port 22
  IdentityFile ~/.ssh/github_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes

っていうファイルを作って、今回はリモートがgithubの場合ですが、
ここに接続するための鍵があるよ！って教えてあげないといけない

３．windowsかつPowershellの人はさらに

chmod 0600 つけた名前

でパーミッション許可してあげる。
と、いう感じです。

ここからの流れは長いので、
読みたい人は見てね

前提条件

・現在スクールでvagrant,VirtualBox,Ruby on Railsを用いて開発中
・vagrantの起動、railsサーバーの起動、gitコマンド等はすべて
　Powershellを用いて行っている

◎ハマリポイント１

Powershellに下を打ち込んでディレクトリの移動。

cd ~/.ssh

ここに作る意味は、gitがssh鍵を探しに行くデフォルトのフォルダがここだから。
ちなみに、vagrant内での.sshフォルダはvagrant upコマンドを打ち込んだときにターミナル or Powershellに表示される

default: /home/vagrant/work => ほにゃらら

ほにゃららの部分のディレクトリ下にできますよん

んで、

ssh-keygen -t rsa -b 4096 -C "githubに登録しているメールアドレス"

-t rsa　＝　rsaというタイプの鍵にしますよ～
-b 4096 ＝ 4096bitの長の鍵にしますよ～（デフォルトは2048bit。長いとセキュリティ向上するよ）
-C "" ＝ 公開鍵の内容のしっぽにコメントが付くんだけど、その内容を""の中身にするよ～（メールアドレスにするのがスタンダードなんやて。）
という意味。

その後

Enter file in which to save the key (/Users/you/.ssh/id_rsa):github_rsa

で名前をつけたのですがこれが間違い、、、
英語読解力がなさすぎるんですが、in which to save（どこに保存する？）的な意味なので、

Enter file in which to save the key (/Users/you/.ssh/id_rsa):
 /Users/自分のPCのユーザ名/.ssh/github_rsa

と打ち込まなくてはならなかったんですよね、、、
これは私が単純に説明書読まないタイプの子なのが悪いです

◎ハマリポイント２

それでも消えないエラー。

Permission denied (publickey).

ここで私は思ったのですが、id_rsa（デフォルトの名前）のときはうまくいってたんだよな～、ということは名前をつけたことでエラーを吐いてるのか。（そりゃそう）

調べてみたら要約の通りで、gitの仕様上デフォルトの名前のid_rsaを探しに行くので、ない！作ってないやんけ！て言われる。

なので、.ssh下にconfigというファイル名で以下を記述

config

Host github.com
  HostName github.com
  User git
  Port 22
  IdentityFile ~/.ssh/github_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes

これでgithub_rsaを探しに行くようになってくれます。

◎ハマりポイント３

まだ消えないエラー。さすがにメンタルが弱る。今度は内容が違う。

Bad owner or permissions on C:/Users/*****/.ssh/config

これはwindowsユーザーかつPowershellを使ってる人だけに起こるみたいで、秘密鍵とconfigファイルを一緒のディレクトリに入れてるとこのエラー吐くとか。
（詳しくは引用見て欲しい）

秘密鍵を.sshと違うディレクトリに移動すれば解決らしいけど、
configの中身書き直すのめんどくさいし、

chmod 0600 github_rsa

で権限を与えました。

以上！長かったね、きれいにまとまってなくてごめんなさい。
エンジニアとしてまだ仕事してるわけじゃないので、間違っているところがあったら編集リクエスト？なりコメントなりお願いいたします

参考にした記事
お前らのSSH Keysの作り方は間違っている
https://qiita.com/suthio/items/2760e4cff0e185fe2db9

GitHubユーザーのSSH鍵6万個を調べてみた
https://hnw.hatenablog.com/entries/2014/07/05

Win10のSSHでBad owner or permissions
https://qiita.com/ryota23/items/8d2745c3b275e8ec7ea8

秘密鍵を使った SSH 接続時に WARNING: UNPROTECTED PRIVATE KEY FILE! と表示されて接続できない
https://support.amimoto-ami.com/en/articles/934049-%E7%A7%98%E5%AF%86%E9%8D%B5%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F-ssh-%E6%8E%A5%E7%B6%9A%E6%99%82%E3%81%AB-warning-unprotected-private-key-file-%E3%81%A8%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%81%A6%E6%8E%A5%E7%B6%9A%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84

背景

業務中でgit-bashを使っているのですが、git-flow運用をしているせいで予測変換も上手く使えずイライラしてました。
おかげでfeatureをタイプする速度は職人技になりつつあります。
工数削減として対策をした結果をお話します。

はじめに

$ git checkout -

↑のコマンドで直前のブランチへチェックアウト出来る事は知っていましたか?
私はこれを知った時感動しました。とても重宝しています。
ですが、いくつかのタスクを並行してると直前のブランチが何だったか思い出すのも大変ですよね。

直前のブランチ何使ってたっけ?

$ git --no-pager reflog | awk '$3 == "checkout:" && /moving from/ {print $8}' | uniq | head | nl

このコマンドは直近checkoutをしたブランチの履歴を頭から10件表示してくれます。
直近のブランチが表示されるので、常に必要なやつだけが表示されて非常に便利ですよね。
私はこれをbrlogというコマンドで呼び出せるようにしました。
これで前章の問題は解決されました。
最後のnlで行番号を表示した理由を次章でお話します。

指定行のブランチ名をクリップボードにコピーしよう

指定した行番号のブランチをクリップボードにコピー出来れば、pullやcherry-pickにも使えて便利だと考えました。
そこで私はshellを書いて、brcopyというコマンドに登録しました。

#!/bin/bash

#validate
if [ $# != 1 ]; then
        echo 'You should input argmen'
        exit 1
fi

#main
ESC=$(printf '\033')
# ↓ head -n $1 | tail -n 1で特定行から一行だけ抽出してます。
OUT=`git --no-pager reflog | awk '$3 == "checkout:" && /moving from/ {print $8}' | uniq | head -n $1 | tail -n 1`
printf "${ESC}[32m%s${ESC}[m\n" "coping '$OUT' to clipboard"
powershell set-clipboard $OUT #これでクリップボードに任意の文字がコピーできます(Windows専用)

以下が実際に使用した場合の挙動です。

$ brlog
     1  release/patch_20200530
     2  feature/develop_test3-name
     3  feature/develop_test2-name
     4  feature/develop_test1-name
     5  develop

$ brcopy 4
coping 'feature/develop_test1-name' to clipboard

上記のコマンドでクリップボードへのコピーが完了してますので、checkoutするなりpullするなり好きに使ってください!

さいごに

皆さんはこの問題ってどのように対応しているのでしょうか?
何か対応方法がありましたらコメントで教えていただけると嬉しいです:)
(参考資料があったのですが、履歴をたどっても見つからなかったため、見つかり次第貼ります)

概要

ターミナルでgit操作している場合、PRレビューお願いしますと言われ、やらなきゃいけないのは山々だけど今から見るのは作業中ファイルもあるし、面倒だなぁということがあります。

そんな問題を解決できる方法を考えてみました。

PRレビューデバッグまで

まず、共通作業であるGithubでPRを見てブランチをコピペするところから始まります。

作業中ディレクトリでブランチを切り替えて見るケース

• git stash
• git fetch
• git checkout ブランチ名
• yarn dev

いいところ
- ディレクトリをひとつにできる
- 頻繁に更新されているのでpullやfetchがあまり必要ない

つらみ一覧
- 現在の作業を保存してブランチを変えるのがだるい

そもそもレビュー用ディレクトリを分けて見るケース

test-projectというリポジトリの場合、test-project-reviewのようにわかりやすいディレクトリを切り管理する
もしくは、作業ディレクトリのgitignoreでignoreしてディレクトリごと入れる？

いいところ
- 現在の作業が干渉しない

つらみ一覧
- pull, fetchがだるい
- エディタをもう1個開くのが面倒(ターミナルなら楽な気もする)

作業中ディレクトリで見る場合の便利なスクリプト

.zshrcなりにコピペしてsourceすれば使えるようになる
branchdebugの略です
bd fix/pages/remove-unused-variable のような感じで実行すると

• このブランチに移動したときのファイルだよという名前付きgit stashを行う
• git fetch
• git checkout
• yarn dev

を一連のセットで行います。

なんか間に処理入れたい人は自分でカスタマイズしてください。

 function bd () { git stash save -u "some files when checkout $@ branch" && git fetch && git checkout $@ && yarn dev  }     

感想

githubで任意のブランチ名のローカルホスト上げられたらなぁ〜〜〜〜〜〜〜

レビュー終わった後に作業用ブランチに戻る用コマンドもあったら楽そう。
- git checkout
- git stash apply

のセットで。

DockerでPHPの環境作っていたらエラーに遭遇

Using version ^3.1 for laravel/installer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 16 installs, 0 updates, 0 removals
  - Installing symfony/process (v5.0.8): Downloading (failed)       
Downloading (failed)       
Downloading (failed)    Failed to download symfony/process from dist: The "https://api.github.com/repos/symfony/process/zipball/3179f68dff5bad14d38c4114a1dab98030801fd7" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
    Now trying to download from source
  - Installing symfony/process (v5.0.8): Cloning 3179f68dff


Installation failed, deleting ./composer.json.


  [RuntimeException]                                                                                                                       
  Failed to clone https://github.com/symfony/process.git via https, ssh protocols, aborting.                                               

  - https://github.com/symfony/process.git                                                                                                 
    Cloning into '/composer/vendor/symfony/process'...                                                                                     
    fatal: unable to access 'https://github.com/symfony/process.git/': server certificate verification failed. CAfile: none CRLfile: none  

どうやら、以下でソースをgitからcloneしてくる処理でコケたらしい。
composer global require "laravel/installer"

対策

DockerfileのRUNコマンドにexport GIT_SSL_NO_VERIFY=1を追記

RUN export GIT_SSL_NO_VERIFY=1 \
  && composer global require "laravel/installer"

ちなみにexportコマンドはターミナルからログアウトもしくはexitするまで保持される。

経緯

エンジニアになりたての頃、Githubに適当なユーザーネームで登録してしまって、後から変更したくなることってありますよね。（私だけ？）

---

セッティングページがらさっそく変更してみましょう！

↑ここですね

---

↑めっちゃ脅してくる笑

---

簡単に訳すと、

以下を読まないと、予想もしない悪いことが起こるかもしれないよ！

• 旧プロフィールページの（新プロフィールページへの）リダイレクトは設定しないよ
• Pagesサイトのリダイレクトは設定しないよ
• リポジトリのリダイレクトは設定するよ（webとgitアクセス）
• リネーム完了には数分かかるかもよ

OKOK。understandしたので変更します。

---

新しいユーザーネームを入力し、「Change my username」をクリック！
実際には数分もかからず、20秒くらいで完了しました。

---

変更してから気付いたのですが、ユーザーネーム変更に伴うサイドエフェクトの詳しい説明は↓のページに記載されていました。ちゃんと読んでから変更しましょう。
https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/changing-your-github-username

---

この中で気になる記載がありました。

If the new owner of your old username creates a repository with the same name as your repository, that will override the redirect entry and your redirect will stop working. Because of this possibility, we recommend you update all existing remote repository URLs after changing your username. For more information, see "Changing a remote's URL."

---

訳すと、

旧ユーザーネームの新しい所有者があなたのリポジトリと同じ名前のリポジトリを作成した場合、そのリポジトリはリダイレクトエントリを上書きしてしまい、リダイレクトは動作しなくなります。このため、ユーザーネームを変更した後は既存のリモートリポジトリのURLをすべて更新することをお勧めします。詳細は"リモートのURLを変更する"を参照してください。

---

ユーザネーム変更の際、リポジトリのリダイレクト設定は自動でしてくれるので、リモートリポジトリのURLを自分で更新する必要はないと思っていましたが、上記の記載を見ると更新したほうが良さそうですね。

---

リモートリポジトリのURL更新は以下のコマンドで変更できます。

git remote set-url origin <new url>

---

これで快適なGithubライフを送れますね。