はじめに 昨日投稿した以下の記事で「そのうち書こうかな」と言っていたやつです。 gitのデフォルトブランチ名を変えたのに、なぜかgit initしてもブランチがmasterで作成されて困ったという話。 原因 gitのバージョンが古いことが原因でした。恥ずかしい。 どうもconfigでdefaultbranchの名前を変えられる昨日は、バージョン2.28から追加されたようです。 自分のgitのバージョンを調べてみたところ、見事に古いバージョンのものでした。 gitのバージョンを調べるコマンドは以下のとおり。 git version #gitのバージョンが表示されます git version 2.XX.X 解決方法 gitの更新 リポジトリをOSに追加する方法でgitをインストールしてた人は多分apt update apt upgradeで更新できてたと思うけど、自分はなぜかgitのリポジトリが追加されてなかった（多分直接ファイルダウンロードでもしてたのかな）ので、新しくリポジトリを追加してからパッケージを更新する。 add-apt-repository ppa:git-core/ppa apt update apt upgrade これだけです。 この後gitのバージョンを確認してみると、しっかりgit version 2.34.1に更新されていました。 これでちゃんとinitしたときのデフォルトブランチ名が変更されるはず。 init時のデフォルトブランチ名を変える 情報をまとめるついでにconfigを変える方法も書いておきます。 gitのconfigには以下の3つのスコープがあるもよう。 system: システム全体に適用 /etc/gitconfig global: ログインユーザに適用 home/.gitconfig local: gitリポジトリごとに適用 {workspace}/.git/config これらは上から順に読み込まれます。つまり、特定のリポジトリで作業をする際は、localに記述した内容が最優先されます。 今回はとりあえずgit initで新規作成する際のブランチ名を変えたいので、globalのconfigに記述を加えます。 記述はコマンドラインから以下のように打ち込めばok。 git config --global init.defaultBranch {default branch name} #例えばmainに変更したい場合は git config --global init.defaultBranch main #systemレベルで変更したい場合は git config --system init.defaultBranch {default branch name} #sudo必要かも コマンドではなく直接エディタで編集したい場合は、ファイルマネージャでそれぞれのconfigを確認すればいい。 かんたーーーん！！ とりあえずgithubのデフォルトがmainだし、人権問題とかでmasterが復権することは（特に海外では）望めなさそうなので、デフォルトブランチ名はmainに変えておくのがよろしいかな。 おわりに gitの更新忘れというなんとも粗末な原因で余計な手間と時間を消費してしまった。 やっぱりサービス提供者の発表した重要な更新にはしっかり対応しないとまずそう。 というかせっかく登録したサービスなんだからこまめに使っていかないと、事故に蓄積した情報や技術がいつの間にか陳腐化してしまうから、そのあたり意識変えないといけない。 qiitaももっと活用しなきゃ。

通常、秘密鍵やAPI Tokenはソースコードとは分離させ、.envファイルなどに保存しておいて、Gitのコミットには含めない。しかし、実装の初期には.envを一時的にコミットに含めている事例も珍しくない。それを後で削除してコミットしても、履歴としては残っている。 この記事では、スマートコントラクト用の秘密鍵や、APIトークンなどの情報をGitのコミット履歴から検索し、リポジトリを公開する前に安全を確認できるツールを紹介する。 コミット履歴を展開する 私の作ったesightというツールを使う。 git logを使って確認するのが一般的だが、一度全て展開した方が、後の編集や確認が楽になる。 インストール pip3 install git+https://github.com/TakutoYoshikai/elemental-sight.git コミット履歴の展開 出力先ディレクトリに、全てのコミットの差分ファイルが展開される。そこからターゲットとなる文字列を検索し、それを修正すればよい。 esight /path/to/repo {BRANCH} -o {OUTPUT DIR} 展開されたディレクトリはこうなっている コミットが順番に番号のディレクトリに出力されて、差分のファイルが保存されている。 APIトークンや秘密鍵などの文字列を検索するツール このesightを使用して、gitのコミット履歴を展開した後、正規表現でランダムな文字列を検索するツールshibaを開発した。 このshibaは、正規表現によってhex文字列や、普通の文字列を検索した後に、その文字列がランダムに生成されたかどうか、文字の出現頻度の分散を計算し、閾値以上のものを表示する。 インストール git clone https://github.com/TakutoYoshikai/shiba cd shiba ./install.sh #パスを通す echo "export PATH=\$PATH:/path/to/shiba/bin" >> ~/.bash_profile 使い方 # APIトークンを探す shiba /path/to/repo {BRANCH} {TOKEN LENGTH} # ./SHIBA_RESULT にコミット履歴が展開されている # hex文字列を探す shiba /path/to/repo {BRANCH} hex {TOKEN LENGTH} #例: ローカルにcloneしたreactのリポジトリの中から32文字のhex文字列を検索する shiba ./react master hex 32 結果は以下のように表示される ./0/message.json 4hQ0v2z7fNRvvOji0jShV5SpNqYEgajJ ./1/message.json zkjhJgeY336mqEADvkvE494xxi2XyB8u ./2/env oe7tGfeBW1YJga7DieAjtrxCgNhs1c5X コミット履歴を確認した後 公開してはいけないデータを見つけた場合の対処法が、以下のメルカリの記事に修正の方法がまとめられている。

はじめに 最近、大学入学時くらいに作成しただけしておいたgithubのアカウントをなんとかせにゃならんな～、と唐突に思った。 あとついでにDockerの知識確認もしたかったから、試しにDockerを使ってNext.jsのサンプルアプリでも立ち上げて、git push origin mainしてみたところ、記事タイトルのエラー発生。 しばらくハマったので戒めのために書いておくことにする。 環境 OS: Linux(KDE neon 5.23.5) git version: なんか.22とか.23くらいの古いやつだったはず 発生したエラー たしか下記の2つ。 fatal: Authentication failed for 'https://github.com/{your user name}/{your repository name}.git' error: src refspec {your branch name} does not match any. 原因 原因は多分下の2つ。多分。 push時に用いるgithubのパスワードが、アクセストークンとやらに変わっていた ローカルとリモートでブランチ名が違っていた（masterとmain） 超初歩的でくだらないミスなので恥ずかしい限り。 解決方法 アクセストークンを取得する パスワードの代わりに使用することになったアクセストークンとやらを取得する必要がある。 これはgithubのSettingsページから取得可能。 アカウントのSettingsページへ行ったら、サイドバーにあるDeveloper settings -> Personal access tokensへ。 Personal access tokensへ行ったら、Generate new tokenで新しくトークンを発行できる。 なにやら色々設定項目があるけども、それぞれ多分以下のような感じ。 Note: トークンの使用目的（多分適当でいい） Expiration: トークンの有効期限（リポジトリに触りそうな期間を目安で設定すればよさそう） Select scopes: トークンに付与されるアクセス権限の設定（適当にrepoとdelete_repoにチェック） はい。どうやらこれでGenerateして出てきたトークンをコピペして使用すればいいのかな。 ただネットで調べた感じ、いちいち長ったらしいトークンを入力するのは面倒って人が多いっぽい。 おまけにトークンは生成時に表示されるページで一度しか確認できないみたいだから、どこかに控えなくちゃいけない。 これが面倒な人は、ローカルのgitに登録するリモートURLに、トークンを追加してあげればいいみたい。 書き方は以下の通り。 .git/config [remote ""origin] url = https://{access token}@github.com/{your user name}/{your repository name}.git 意外と単純。 ただこの方法は将来的に場合によってはセキュリティ的な問題になりやすいみたいだから、注意が必要かも。 個人で遊ぶ分にはまあどうってことなさそうではあるから、自分は気にしないけど。 gitのブランチ名をmasterからmainに変更する 「githubのデフォルトがmainになったんだからgitも対応してくれよ（あるいは逆）」とは思ったけど、してくれないからとりあえず自分でブランチ名を変えるしかない。 これも単純で、ターミナルに以下のコマンドを打ち込めばいい。 git branch -m {old branch name} {new branch name} #現在のブランチ名を変えたいなら引数短縮できて git branch -m {new branch name} 今回だとmasterをmainに変えたいってことだったから、git branch -m master mainとした。 これで多分エラーは出なくなると思う。一件落着。 「いちいちgit initするたびに名前変えるのダルいな！」と思って、デフォルトのブランチ名変えようしたらハマった話もそのうち書くかも。 おわりに 今回引っかかった原因は、どちらも情報としてはキャッチアップしてたのに、実際に手元で確認したり対応していないものだった。 特にgithubのデフォルトブランチ名がmasterからmainになる話なんかは結構大きかったから、やっぱりサービスの提供元からなにか大きな変更が発表されたら、しっかりとそれに対応しなくちゃいかんなー、とかなんとか。 とにかく今後こんなたわけたミスをしないように、情報には敏感に、対応は素早くを心がけたい所存。 あと、もう少し定期的にqiitaとかgithubとか更新しないとせっかく登録したのにもったいないから、そこもなんとかせねば。

git tagのデフォルトだと、情報量が少なくてあんまりよくわからんこと多いので使い方調べたメモ 基本 めんどくさくてwebで調べがちだけど、manを一度読むべき. $ man git-tag NAME git-tag - Create, list, delete or verify a tag object signed with GPG SYNOPSIS git tag [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] <tagname> [<commit> | <object>] git tag -d <tagname>... git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] [--points-at <object>] [--column[=<options>] | --no-column] [--create-reflog] [--sort=<key>] [--format=<format>] [--merged <commit>] [--no-merged <commit>] [<pattern>...] git tag -v [--format=<format>] <tagname>... タグ付けする使い方 git tag [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] <tagname> [<commit> | <object>] タグを削除する使い方 git tag -d <tagname>... タグをリストアップする使い方 git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] ... タグのGPG signatureをverifyする使い方 git tag -v [--format=<format>] <tagname>... タグのリストアップ デフォルトだとタグのみ $ git tag -l 0.0.5 0.0.7 v0.0.1 v0.0.2 v0.0.3 v0.0.4 v0.0.5 v0.0.6 v0.0.7 v1.0.0 v1.1.0 v1.1.1 v1.1.2 v1.1.3 v1.2.0 v1.2.1 v1.3.0 format --format でフォーマット指定. デフォルトは %(refname:strip=2). $ git tag -n -l --format='%(refname:strip=2)' 0.0.5 0.0.7 v0.0.1 v0.0.2 v0.0.3 v0.0.4 v0.0.5 v0.0.6 v0.0.7 v1.0.0 v1.1.0 v1.1.1 v1.1.2 v1.1.3 v1.2.0 v1.2.1 v1.3.0 使えるkeyの一覧はmanにはのってなかった. 直接sourceをみるとこれっぽい. - https://github.com/git/git/blob/v2.17.0/ref-filter.c#L328-L371 よく使いそう - refname: tagの名前とか - authorname: 作った人 - authordate: 作った日付 - subject: コミットメッセージ $ git tag -n -l --format='%(refname:strip=2) %(authordate:short) %(authorname) %(subject)' 0.0.5 2019-05-15 Juan Leni fixing linter issues 0.0.7 2020-03-27 Joshua Harshman Partial Revert of #922 (#1068) v0.0.1 2017-10-12 Thomas Cyron Create new buffer if not present yet (#549) v0.0.2 2018-03-21 Michael Update the Travis and CircleCI Go versions (#651) v0.0.3 2018-04-27 Zef Hemel Fixed code sample for bash completion (#687) v0.0.4 2019-03-21 Willi Eggeling added variable to allow configuration of mousetrap message duration (#809) v0.0.5 2019-05-15 Juan Leni fixing linter issues v0.0.6 2020-02-20 Alexandr Burdiyan Add support for context.Context v0.0.7 2020-03-27 Joshua Harshman Partial Revert of #922 (#1068) v1.0.0 2020-04-10 Marc Khouzam Fish completion using Go completion (#1048) v1.1.0 2020-10-14 Adam Demuri Add example for making persistent flags required (#1135) v1.1.1 2020-10-18 Sascha Steinbiss fix manpage building with new go-md2man (#1255) v1.1.2 2021-02-09 Anthony Fok Update CHANGELOG.md for v1.1.2 v1.1.3 2021-02-10 Anthony Fok Fix typo v1.2.0 2021-07-01 Marc Khouzam Fix documentation (#1434) v1.2.1 2021-07-02 Paul Holzinger Fix flag completion (#1438) v1.3.0 2021-12-14 dependabot[bot] Bump github.com/spf13/viper from 1.9.0 to 1.10.0 (#1561) authordateなんかのフォーマットはここらへんっっぽい - https://github.com/git/git/blob/e773545c7fe7eca21b134847f4fc2cbc9547fa14/Documentation/rev-list-options.txt#L1007-L1062 - relative/local/iso/iso-strict/rfc/short/raw/human/unix/format/default/rfc2822 なんかが使えるっぽい formatが何でも自由にできて便利 $ git tag -n -l --format='%(refname:strip=2) %(authordate:format:%Y-%m-%d_%H:%M:%S)' 0.0.5 2019-05-15_18:53:39 0.0.7 2020-03-27_14:38:32 v0.0.1 2017-10-12_20:25:33 v0.0.2 2018-03-21_14:39:34 v0.0.3 2018-04-27_15:45:50 v0.0.4 2019-03-21_01:05:52 v0.0.5 2019-05-15_18:53:39 v0.0.6 2020-02-20_07:29:50 v0.0.7 2020-03-27_14:38:32 v1.0.0 2020-04-10_15:56:28 v1.1.0 2020-10-14_09:53:09 v1.1.1 2020-10-18_20:59:26 v1.1.2 2021-02-09_18:39:00 v1.1.3 2021-02-10_12:40:59 v1.2.0 2021-07-01_11:49:30 v1.2.1 2021-07-02_17:25:47 v1.3.0 2021-12-14_11:22:51 sort 表示したらsortもついでにやりたいのが人の常. --sort でkeyを指定してソートできる. $ git tag -l --sort refname | head 0.0.5 0.0.7 v0.0.1 v0.0.2 v0.0.3 v0.0.4 v0.0.5 v0.0.6 v0.0.7 v1.0.0 keyのまえに-をつけることでreverse sortできる. $ git tag -l --sort -refname | head v1.3.0 v1.2.1 v1.2.0 v1.1.3 v1.1.2 v1.1.1 v1.1.0 v1.0.0 v0.0.7 v0.0.6 key listはformat同様に使えるっぽい - https://github.com/git/git/blob/v2.17.0/ref-filter.c#L328-L371 authordateとか使うと最新順で並びそう $ git tag -l --sort -authordate | head v1.3.0 v1.2.1 v1.2.0 v1.1.3 v1.1.2 v1.1.1 v1.1.0 v1.0.0 0.0.7 v0.0.7 おわり git-tagでsortとformat使えると便利. いろんなOSSのプロジェクトでgit-tag表示すると楽しい. vつけるのミスってたり、夜中にコミットしてたりで人間味が感じられるよね.