公開鍵と秘密鍵の作成

ssh-keygen

公開鍵の表示

cat  ~/.ssh/id_rsa.pub

なんの記事？

個人開発の新規プロジェクトにて、最初のコミットを忘れていたせいで、（意図せず「最初のコミット」になってしまったコミットの）コメントがなんだかカッコわるい状態になってしまいました。

masterブランチの最初のコミットなのに「作業中断時コミット」ってなんやねん...¹

しかも2つ目のコミットを実施した直後に気づいたので、単純にgit commit --amendするだけでは対処できず。

以下の方法でそれらしいコメントに修正することができたので、記録しておきます。

注意事項

チームで開発しているプロジェクトでは、rebaseは禁じ手かなと思っています。
今回の事例はあくまで個人開発プロジェクトであり、影響範囲がわかっているので実施しました。

方法

最初のコミットを指定するときは、--rootオプションを使います。

$ git rebase -i --root

エディタが起動します。

pick 1b833b2 作業中断時コミット
pick 62d0d4f 最低限の計算ができるようになった。商品数はまだ固定。

編集します。

r 1b833b2 作業中断時コミット
pick 62d0d4f 最低限の計算ができるようになった。商品数はまだ固定。

（以下略）

保存後、すぐに別のエディタが起動しますので、ここでコメントを書き換えます。

変更前

作業中断時コミット

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
（以下略）

変更後

init

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
（以下略）

保存します。

Successfully rebased and updated refs/heads/master.

のように表示されたら成功です。
あとは、リモート側に強制プッシュしておきます。
（チーム開発時には禁じ手です。個人開発で、影響範囲がわかっているからできること。。。）

$ git push -f

リモート側も更新されていることを確認しましょう。

それらしくなりました。

反省点

コミット前に、git statusで、どこのブランチにいるかを確認しましょう。

---

1. 個人開発プロジェクトのトピックブランチでは、作業結果を失わないために中途半端な状態でも意図的にコミットするようにしています。その際につけるコメントを「作業中断時コミット」としていますが、流石にmasterの、しかも最初のコミットがそのコメントなのはいただけません。 ↩

動作環境

Windows

Edition : Windows 10 Enterprise
Version : 1809
OS build : 17763.1217
System : 64bit Operating system, x64 base processor

Git for windows

Git-2.26.2-64-bit.exe

TortoiseGit

TortoiseGit-2.10.0.2-64bit.msi

不具合現象

Git Bash起動時

Git for windowsインストール後にGit Bashを起動すると
Error : Could not fork child process : Resource temporarily unavailable (-1).
DLL rebasing may be required; see rebaseall / rebase --help.
というエラーが発生し起動できず
Git GUIとGit CMDは正常に起動する。

TortoiseGitでgit clone時

下記エラーが発生。レポジトリのクローンは一応できている様子。

0 [main] sh (12996) C:\Program Files\Git\usr\bin\sh.exe: *** fatal error - cygheap base mismatch detected - 0x12C7408/0x1317408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version should
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
0 [main] sh 130 dofork: child -1 - forked process 12996 died unexpectedly, retry 0, exit code 0xC0000142, errno 11
C:/Program Files/Git/mingw64/libexec/git-core\git-submodule: fork: retry: Resource temporarily unavailable
.....
.....
C:/Program Files/Git/mingw64/libexec/git-core\git-submodule: fork: Resource temporarily unavailable

git did not exit cleanly (exit code 254) (195687 ms @ 2020/05/22 10:15:15)

解決策

Windows10 Exploit protectionの「イメージのランダム化を強制する（必須ASLR）をオフに設定することで回避できる。私のPCはなぜかオンに設定されていた。なぜこの設定を切り替えればできるのかは今のところ不明。

コントロールパネルで「アプリとブラウザ－コントロール」と検索して開く
Exploit protectionの設定をクリック

イメージのランダム化を強制する（必須ASLR）がオンになっている

規定値を使用する（オフ）に設定して、再起動する

PC初期化で、Google Authenticatorに登録していた認証情報がなくなってしまいました。
めっちゃ焦りました、、、、。

AWSなど全て消えてしまったのですが、最も困ったのが、GitHubです。

今回は、GitHubの2段階認証が消えた後、復活までにしたことを書いていこうと思います。

GitHubのリカバリーコードを持ってますか？

公式のドキュメントを見ると

2 要素認証リカバリコードを使用する
リカバリコードのうち 1 つを使用して、アカウントへのエントリを自動で再取得します。 リカバリコード は、多くの場合、パスワードマネージャまたはご使用のコンピュータのダウンロードフォルダに保存されています。 リカバリコードのデフォルトのファイル名は github-recovery-codes.txt です。

公式
が解決法としてあります。

早速、PC内を「github-recovery-codes.txt」で検索、、、。
やっぱりない、、。初期化で本当に全てのデータがなくなってしまった！！

再度、公式ドキュメントを見ていくと

検証済みのデバイス、SSHトークン、または個人アクセストークンを使用した認証
2 要素認証の認証情報にアクセスできなくなり、2要素認証リカバリコードを持っていない場合は、検証プロセスを開始してアカウントへのアクセスを回復するために、認証済みメールアドレスにワンタイムパスワードを送信できます。

の方法もあるようです。sshでサーバからgitを使っていたので、これならできるかもと思い、この方法でやっていくことに！

SSHトークンの認証をしてみる

公式ドキュメントの手順通り進めていきます。

One-time passwordを発行される

発行されると「[GitHub]Two-factor-lockout request」というタイトルのメールが届きます。

全ての手順が完了する

全ての手順が完了すると、「[GitHub]Two-factor-lockout request completed」というタイトルのメールが届きます。
メールの本文には、リクエストをキャンセルするリンクも存在するので、もし途中で違う方法で解決できるのであれば、キャンセルもできます。

そしてメールの本文には

GitHub Support will review this request within the next 3-5 business days

の文字が、、、、。3から5日、解除するには時間がかかるようです。

認証依頼した4日後

私の場合は、4日後に「[GitHub]Account recovery request approved」
のタイトルのメールが届きました。
。

本文の中に「Complete account recovery」のリンクがあり、そのリンクを72時間以内にクリックすれば、アカウントのリカバリーが完了します。

ですが、本文をよく読むと、紐付けしていた２段階認証が必要だったorganizationsが外されるので、リカバリーした後に再度紐付けをしてという内容が、、、。

GitHubで2段階認証(MFA設定)ができなくなって思うこと

2段階認証のリカバリ方法はいろいろあります。
GitHubの2 要素認証リカバリ方法を設定する

何かあった時を想定して、しっかりとリカバリーをできるようにしときましょう

一緒に仕事している会社さんが
自分のサーバーにSSH接続させてcloneで納品
仕様違いはbranch切るので勝手に持っていて()のStyle・・・

使い慣れると以外に便利なので自社内でも出来ないかなと調べたら
あっけなくできたんですが、やり方絶対忘れるので自分メモ

操作はwindowsで、とりあえずの動作説明なので
ローカルのPCのCドライブDドライブで操作を行います。

git初心者向けの項目もあるのでgitがわかる方は
適時読み飛ばしてください

１．リモートリポジトリ作成

まず　「d:\test」というフォルダにリモートリポジトリ「try.git」を作成します

(cloneするときに「***.git」ってファイルなのかな？と思ってたけどフォルダという事が今回判明
ちなみにリモートリポジトリのフォルダに「.git」つけるのは作法らしい・・・）

$ d:
$ cd test
$ mkdir try.git
$ cd try.git
$ git --bare init --shared

こんなコメントが（多分出ると思うので）出たら成功

Initialized empty shared Git repository in D:/test/try.git/

上4行はまあいいとして
問題は5行目！
git initに何やらオプションが・・・
一応解説

–bare：作業ファイルをもたないpushされるための専用のリポジトリを作成
–share：このリポジトリを共有可能にする。これがないとpushしてもファイルを作成できないらしい・・・

dirとかlsとかで「try.git」フォルダ内にファイルが出来ていれば成功です。
意外にちょろいです。

２－１．ローカルにクローンを作成する場合

c:\に「tmp」というフォルダを作ってそこに先ほどのリモートリポジトリをクローンします

$ c:
$ cd tmp
$ git clone d:\test\try.git

成功するとこんなコメントが
warningとかドキッとするのでやめてください（）

Cloning into 'try'...
warning: You appear to have cloned an empty repository.
done.

リモート先の確認

$ cd \try
$ git remote -v

問題ないことを確認

origin  d:\test\try.git (fetch)
origin  d:\test\try.git (push)

空のコミットをしたほうが良いらしいので実行をします
★参考 @NorsteinBekklerさん
：Gitの最初のコミットは空コミットにしよう

$ git commit --allow-empty -m "first commit"

あとは適当にファイルを作って、普通に操作します

ここから先はNOOB用の参考です。
gitが操作できる方は読み飛ばしてください

とりあえず「test.txt」というファイルを新規に作って中身は「master」とでもしておいてください。

作成したら

$ git add .
$ git commit -m "適当なコメント"

下記みたいなコメントが出たら成功
今回はコメントは「initial addition」

[master (root-commit) 3fbb23f] initial addition
 1 file changed, 1 insertion(+)
 create mode 100644 text.txt

先ほどのリモートリポジトリにpushします。

$ git push origin master

下記みたいなコメントが出たら成功

Counting objects: 3, done.
Writing objects: 100% (3/3), 218 bytes | 218.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To d:\test\try.git
 * [new branch]      master -> master

２－２．既存のフォルダをリモートリポジトリに追加する場合

「d:\test」というフォルダにリモートリポジトリ「try2.git」があり
既存のファイルがあるディレクトリ（c:\tmp\try2）を「try2.git」にリンクさせます。

やっている事は
初期化->空のコミット->にリモートリポジトリのリンクを追加です。

$ cd c:
$ cd \tmp\try2
$ git init
$ git commit --allow-empty -m "first commit"
$ git remote add origin d:\test\try2.git

リンクできているか確認します。

$ git remote -v

リンク先が表示されますので問題ないことを確認

origin  d:\test\try2.git (fetch)
origin  d:\test\try2.git (push)

リモートリポジトリの場所が登録されただけなので
中身を潜影蛇手（）します。
さっきと同じなので説明はなしで

$ git add .
$ git commit -m　"initial addition"
$ git push origin master

ここまで書きましたが、２－１の操作ってあまりやらなさそうなので
２－２の操作だけ書けばよかった気が・・・

次回は他のPCにリモートリポジトリを配置してそこから操作する方法を書く予定です。

issueとは？

「議論すべき重要な話題・論点・争点」 / 「関心事」あたりになる。

リポジトリごとにissueを作成、管理を行える。
issue ではその repository が見られれば誰でも発言でき、議論・報告・連絡・提案などもろもろが可能。
仕事で使う際は単純にタスク単位に issue を切って管理していくためのツールとして使われることも多い。タスク管理ツールとしての使い方だと Todo ツールなどに近い。 issue 単位で Todo = やることを書いていく。

issue の作成方法

issuesタブからNew issueを押すと入力ページへつながる

内容を記載し、[Submit new Issue]をクリックするとIssueの登録が完了。あとはこのリポジトリにアクセス権限のある人なら、誰でもIssueに対してコメントができる。

Title

タイトルだけでIssueの内容が把握できるようにする。

Issueがバグの場合は、設計要素の名称を書く。

【xx画面】xxボタン押下時にエラー など...

問題の内容

複数の問題をひとつのIssueに含めない。面倒だけど問題の数だけIssueを発行する。

書くべき内容

実行環境
自分が行った内容
期待する結果
実際の結果

実行環境

そのツール自体のバージョンや、依存していそうなソフトウェアとそれらのバージョン(OS、依存パッケージ、ホスト言語など)を記載する。
開発者がなるべく同じ環境を再現できるように具体的に書くのが望ましい。

自分が行った内容

具体的に何をやろうとしたのかを記載。
入力として与えた値や問題が起こる直前に行ったことなどの解決に繋がりそうな情報も一緒に記載する。実際に仕様したコードや、その状況が発生するサンプルコード、スクリーンショットや動画などを貼る。

期待する結果

自分がどのような結果になることを想定していたのかを記述する。自明な場合は省略しても可。場合によっては、自分が期待していた結果がそもそも仕様上正しくないということもあり得る。

実際の結果

「正しくない計算結果が出た」、「予期しないエラーが発生した」、といった結果を記載。実際の値などを用いて極力詳細な結果を提供する。長いエラーメッセージを全てそのまま貼り付けるのは可読性を損なうので、そのような場合は必要な部分のみを切り取って記載。

Issueが解決したら[Close issue]ボタンをクリックしてクローズする。クローズしたIssueも、完全に消える訳ではなく、Issueの一覧から確認できる。

担当者を明確にする「Assignee」機能

プロジェクト管理には必須のAssignee（アサイニー）。Issueに担当者を割り当てる機能ある。Issue画面のサイドバーにある[Assignee]という文字をクリックする

Assigneeは途中で付け替えることもできる。そしてIssueの一覧画面ではアイコンが並ぶので、誰がどのくらいのタスクを抱えているかが一目で分かる。

Assigneeに指定することで、通知も逃さず受け取ることができます。1つのIssueに対して1人しかアサインできない。

スケジュールを管理する「Milestone」機能

Issueに締め切りをつける機能。GitHubでは、Issueごとに期日を切るのではなく、マイルストンを先に置いて、それにIssueを紐付ける。

Issueの一覧画面からマイルストンの一覧画面に遷移します。そこから[New milestone]で新しいマイルストンを作成します。

マイルストンの設定画面ではタイトル、概要、期日を入力。タイトルの付け方はチームごとに分かりやすいようにつける。[Create milestone]をクリックすると作成完了です。

マイルストンもAssigneeと同様、Issue画面のサイドバーから設定できる。Milestoneの一覧画面では、紐付けられたIssueの内、何%がクローズされたかという進捗が確認できる。マイルストンを先に設定し、そこに必要なIssueを紐付けていく、という仕組みになっていることが分かる。

増えたIssueを整理する「Label」機能

Issueにラベルを付けて分類できる。