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

Pass: The Standard Unix Password Manager の紹介

Pass: The Standard Unix Password Manager の紹介

Pass: The Standard Unix Password Manager というパスワードマネージャがあります。gpg と git が pass コマンドという bash スクリプトで組み合わせてあって、利用者の応用力が試されるイケてるアプリケーションです。

ところで私の pass の利用歴は約 2.5 年です。個人用で登録しているパスワードの数はこれくらいです。

$ git -C ~/.password-store/private ls-files | grep .gpg$ | wc -l
     235
$

当初から今まで継続して使っていますが、去年くらいまでは持て余していた気がします。ですが自分で便利な使い方を見つけていくうちに、活用でき始めたなと実感しています。

パスワードマネージャには類似のアプリケーションが数多くあります。ですがモノリシックなツールと違い、pass を構成するアプリケーションはソフトウェア開発で使うものと共通する所が多いです。ぜひ自分に合った応用方法を見つけましょう。

対象者

これは pass コマンドをインストールしてパスワードの出し入れはできたが、それ以外の用途が思い付かない人向けの記事です。

基本的な使い方は pass をインストールしてから man pass を見るか、password-store - Simple password manager using gpg and ordinary unix directories. で確認してください。

もし pass をインストールしてみたが gpg とか git などのアプリケーションを積極的には使いたくない、ソフトウェア開発者以外とパスワードを共有したい、という場合は他のアプリケーションを使うべきです。

git

pass を使い始めるには、パスワードを保存する場所を作る pass init {gpg-id}... を実行します。実行直後はこのようなファイル構成になるでしょう。

$ pass init hoge@example.com
Password store initialized for hoge@example.com
$ cd ~/.password-store
$ tree -a
.
└── .gpg-id

0 directories, 1 file
$ cat .gpg-id
hoge@example.com
$

pass を使い始める動機の 1 つにパスワードを複数人で共有したい、というのがあります。複数人でデータを共有するといえばソフトウェア開発者お馴染みの Git です。pass ではそういう用途に使えるサブコマンド pass git init があります。でもこのコマンドは便利なのでしょうか?
例えば pass を紹介している Arch Linux のドキュメントでは pass に環境変数を渡して利用用途などによって Git レポジトリを切り変えるシェルスクリプトを例示しています。

たしかにこれで複数人が pass を使うときに Git レポジトリを用途によって分けたい、というのは実現できます。ただ運用面を考えると、利用者同士でシェルを揃えるというのは難しい場合があります。そのため pass の呼び出し元のシェルに依存しないほうが運用し易い場面も出てくるでしょう。
ということで複数のレポジトリを使う方法として pass git コマンドを全面的に捨てます。その代わりに自前で Git レポジトリを作る構成で使います。

※ただ git init するだけです。例なので /tmp を HOME にしてやってます。

$ git init ~/.password-store/work
Initialized empty Git repository in /tmp/.password-store/work/.git/
$ git init ~/.password-store/private
Initialized empty Git repository in /tmp/.password-store/private/.git/
$

work レポジトリが仕事用、private レポジトリが個人用という想定です。レポジトリは普通のディレクトリなので環境変数など意識せず pass ${repository}/path/to/target というパスの指定で使えます。ただし Git レポジトリを pull したり push したりする場合 git を直接使う必要があります。該当ディレクトリに移動するか、git -C ~/.password-store/${repository} のように -C を付けて git を使う必要があります。この作戦は git commit に当たる pass の操作のコストを減らしつつ、その分のコストを git pull や git push で払う感じです。
この構成で初めから今まで使ってます。私にとっては必須の構成です。

gpg

gpg は git に負けず、かなり連携を効かせられるアプリケーションです。

pass の利用を始めるとき、gpg の鍵を作ります。(gpg --full-generate-key とかで。)
そのとき gpg は主キーと同時に暗号化機能を持つ副キーを作ります。pass ではこの副キーを使います。この鍵を使えば pass の利用者間でパスワード以外のファイルも暗号化してやりとりができます。ですが、この機能を使いたいタイミングは今のところありません。

それよりもオススメしたいのが ssh-agent の代わりに gpg-agent を使うことです。外部サービスなどで使っている SSH の公開鍵を gpg で管理してみましょう。鍵などの秘匿情報は漏れるものと考えて、その鍵に使用期限を付けることで漏れても使えなくなる安心な鍵を作ることができます。
漏れた先の時刻設定が意図的に古くされたら期限設定も意味ないのかもしれませんが…

その鍵を作った後の状態はこんな感じです。usage: S という署名機能だけを持った副キーに期限を付けています。

$ gpg --edit-key hoge@example.com
gpg (GnuPG) 2.2.25; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa3072/A3DDFADA5A35CF2A
     created: 2020-12-04  expires: never       usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa3072/8B83D07BAA92CEBF
     created: 2020-12-04  expires: never       usage: E
ssb  rsa3072/B1B81A516CEA847C
     created: 2020-12-04  expires: 2021-03-05  usage: S
[ultimate] (1). hoge hige pon <hoge@example.com>

gpg>

この状態で OpenSSH 形式の公開鍵を作れます。

$ gpg --export-ssh-key 'B1B81A516CEA847C!'
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCwrYqzViS9gGQLHxKm+hJ8FF0ELehTyoelI4LgKoCPmOBW10aZ5/uqJp9v3fLeN7Sy2yIpsRYaeNwVpWX+oQ58UjuhUEkil9MZQ5KjXk8F8oYorbykoV15XAr5CP/xlYLIMZAmlOH1mz6VKvJIYvifLQAFQuFCVOER7cmZIJl7S4OH7YZnpJMLAaOvDOqpj9bOiAMGbGnFSfx45eZEa4Jbckv2tdk2YZq7PIkVnAG3eEqSa9pPA9neix4j7/YqsC/EOdc/qz8hhECXkELTFDXfg0Hl5MVEOr/Oz9GdG/ubZYgC5No7WNlhkWA+ROr5p10ce9iJB+6iuywkJb0mR7QDJIqFVfQjjJgzC+S40xyfim/g9AYfyhKPOyveKet7oEK+doG1dRWI1wLK0LQT4nbKJ2KyY/JjbQqcTZ5eZcKOtVdaRZM0kPOJ+l7yZjbpmOmi64kbEvo4kxgj8eNeaYxjX2RvtPbwek3rJ1y4n217g3RLu3d3tjgetScNr75BzeE= openpgp:0x6CEA847C

これに gpg-agent に --enable-ssh-support 引数が渡れば ssh-agent と同じように動きます。ただ直接 gpg-agent を使うよりは、他にもオプションも渡すために設定ファイルを経由したほうがいいです。例えばこんな感じです。

~/.gnupg/gpg-agent.conf

pinentry-program /path/to/bin/pinentry
enable-ssh-support
default-cache-ttl-ssh   600
max-cache-ttl-ssh       1800

設定項目の意味はこの辺りを参照してください。
Agent Options (Using the GNU Privacy Guard)

使う鍵はシェル起動時のシェルスクリプトなどでキーグリップを渡すといいでしょう。ただ gpg-agent の実装のせいか ~/.gnupg/sshcontrol に書き込む鍵が多いと SSH ログインの認証時に上から順に試してるせいか、ログインアタックしてるように SSH サーバ側に見られることがあるようです。2 個とか 3 個程度に留めておきましょう。

# gpg --list-keys --with-keygrip hoge@example.com
echo 鍵のKeygrip > ~/.gnupg/sshcontrol
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent
pass private/path/to/secret.pem | ssh-add -q -

互換クライアント

パソコン以外でも pass は使えます。ここでは Android アプリケーションの Password Store アプリを紹介します。

他の互換クライアントは公式ページに載ってるので確認してください。

Password Store アプリは pass find 相当の検索機能とレポジトリのディレクトリ階層を辿るファイルマネージャ風の UI で操作します。Git や SSH の機能が入っています。ただし SSH で使える鍵は RSA のみです。
設定によっては他の Android アプリケーションのパスワード入力のプロンプトで自動的に呼び出されます。

ただし gpg の機能はないので単独では動作しません。gpg の代わりになる OpenKeychain アプリもインストールして連携する必要があります。Password Store アプリで使う鍵はこれで作ります。

せっかくなので OpenKeychain アプリで Password Store アプリが暗号化に使う鍵に加え、SSH で使う鍵も作ります。↑で紹介した gpg の鍵から OpenSSH 形式の公開鍵を作る方法を組み合わせてみます。
ただし OpenSSH 形式の公開鍵をエクスポートする機能は OpenKeychain アプリにないです。結局使い始めるときは OpenKeychain アプリから公開鍵だけをパソコンにコピーして gpg を使う必要があります。

こういう感じです。

# hoge2@example.com の公開鍵が hoge2.asc に保存されている想定
gpg --import hoge2.asc

# SSH の公開鍵に使う鍵の鍵 ID を確認する
gpg --list-keys --keyid-format LONG hoge2@example.com

# SSH の公開鍵を表示する
gpg --export-ssh-key '鍵ID!'

まとめ

gpg も git も応用範囲が広いアプリケーションです。まずは慣れましょう。慣れたら YubiKey 等のスマートキーを使うのもオススメです。
今後もパスワードマネージャアプリは増えていくでしょうが、自分の使い方をよく考えてパスワード管理の運用コストを下げましょう。

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

GitのタイムアウトPermission denied (publickey)

こちらの記事を参考にして進めた

https://qiita.com/tetsu-upstr/items/e72147250701cf30ee72

$ pbcopy &lt; ~/.ssh/id_rsa.pubが使えなかった
だから画面上にはid_rsa.pubは表示することが出来ない(出来なかった)

最後だけ↓のコードを使った

cat id_rsa.pub | clip

これでid_rsa.pubがコピーされるのでgithubの設定ページでコピペして完了した

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

スーパー初学者のためのGitHub講座

あいさつ

はじめまして。初アドベントカレンダーです。
今年の2月末に中小のSIerを辞めて、独学でiOSの開発を学習してきました。以下、自分の過去の記事です。
仕事を辞めて独学でiOSエンジニアを目指して

ちょうどiOSアプリのリリース申請を出しました。(他のアプリと差別化してくれとリジェクトされましたがw)
以下l、作成しているアプリのGitHubリポジトリのURLです。
https://github.com/kaz-engineer-github/AiBC

IT系であるSIerにいたとはいえ、フルスクラッチでアプリを開発するのは難しかったです。Gitに関しては開発に直接関わらないと後回しにして後悔しました。以下、過去の自分の記事で理由を記述しました。
最初にGitを触るべきだった
※念のためGitについて説明しておくと、ソースコードを管理するための技術です。GitHubはGit技術で管理しているソースコードをインターネット上においておけるサービスだと思っていただければ大丈夫だと思います。

ちなみに本日1社内定がでまして、1次面接でGitHubについて質問されたのでGitHubのこと知っておくと良いと思いますw
学習初期でUdemyで学んだ良い講座を今回のアドベントカレンダーに載せたいと思いました。
Git:はじめてのGitとGitHub
結構有名な講座だと思います。なぜ良いのかを書いていきたいと思います。

本講座の特徴

  • 最低限のGit/GitHubのことがわかる
  • 動画の視聴時間が1時間弱
  • 無料

という感じです。
この中で特に個人的に良いなと思うのが、動画の視聴時間が1時間弱という点です。
Udemyって特に開発系の動画の視聴時間が長いんですよ。本当に。
で、全部観終わる頃には最初の方の内容を忘れていて、2周観るだけでめっちゃ疲れるということがあります。その点この講座は1時間弱なのでそもそも2周観なくても内容覚えていられます。2周観るのも楽です。

講座内容

おおざっぱに講座の内容をまとめておきます。

セクション1: Gitの世界へようこそ 計13分

GitとGitHubの大まかな仕組みとその説明。

セクション2: 事前準備 計8分

Gitのインストール、GitHubの登録。

セクション3: GitとGitHubの基本的なワークフロー 計44分

GitとGitHubの最低限の使い方。

セクション4: まとめ 計3分

講座で学んだことのまとめ

セクション5: ボーナス 計3分

Gitで使えるコマンド一覧表。
本講座の応用編講座の割引クーポン。

こんな感じでボリューミーな内容にはなっておりません。
個人的にはそれが逆に良いと思っております。この講座で学んだのちに、Qiita等で少しづつGitコマンドを覚えて、使ってを繰り返していけば良いと思います。

おわり

最近、GitLabというGitHubと同じようなサービスで別のモノが使われているみたいですが、まずはGitHubから学習すれば良いと思います。

制作者の方が同じで応用の講座としてGit: もう怖くないGit!チーム開発で必要なGitを完全マスターというモノがあります。近いうちにこちらの講座も学習して本記事に追記できればなと思います。

簡単な内容ではありますが、以上になります。
読んでいただきありがとうございました。

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

Intelli JでGitHub操作する

概要

Intelli Jを使ってGitHubに接続し、Pull requestをするまでの操作メモです。

Intelli Jについて

JetBrainsが提供しているJava系の言語での開発をメインとしたIDEです。
(Java, Kotlin, Groovy, Scalaなど)
ダウンロードURL

IntelliJ IDEA Community版はオープンソースで利用することが可能です。

今回はterraformの改修に当たって利用しましたが、PluginとしてHashiCorp Terraform / HCL language supportを追加することで入力補完やsyntax highlightなどの機能を使うことができます。

環境

IntelliJ IDEA 2020.1.1(Community Edition)

GitHubアカウント登録

GitHubにログインした状態でpreferencesVersion ControlGitHubを開き、Add Accountをクリックします。 Intelli JにGithubアカウントを登録できます。

git clone

上部メニューのVCSGitcloneからGitHubを選択すると、アカウントに紐づくリポジトリを選択出来るのでcloneします。

git brunch

画面右下にローカルのブランチが表示され、クリックすると派生元を指定して新しいbrunchを作成出来ます。

git commit

画面右上のcommitボタンを押すとcommitされます。changelistを押すとdiffで変更内容を確認出来ます。
問題なければ左下のcommitボタンによりcommitが出来ます。
ezgif.com-gif-maker.gif

git pull

上部メニューのVCSGitpullを選択するとPull画面が表示され、Rootやbranch、オプションを指定してpullすることが出来ます。

git push

上部メニューのVCSGitpushを選択するとPush画面が表示され、diffで変更内容を確認しpushすることが出来ます。

git brame

ファイルの行番号を右クリックしAnnotateを選択するといつ誰が変更したかが表示されgit brameが確認できます。

pull request

上部メニューのVCSGitCreate Pull Requestを開き、必要事項を入力し、OKをクリックすることでPull Requestを作成することができます。このままレビューも行えます。

Github画面にも反映されています。

結果

簡単なGitHub操作についてIntelli Jで行うことが出来ました。
CUIで視覚的に操作出来るので初心者でも分かりやすいです。

参考

https://blog.mmmcorp.co.jp/blog/2020/02/02/compare-vscode-intellij/
https://dev.classmethod.jp/articles/intellij-idea-pull-request/

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

Gitのmerge時に「~ 'ディレクトリ名': permission denied」でエラーになった時

Railsチュートリアルの学習環境を途中でAWS Cloud9からローカル環境に変えた際、Gitのmergeで引っ掛かったので対処法を覚え書き。

■環境
OS:Windows 10
エディタ:Atom 1.53.0

一通りコードの更新が終わってmergeした時に、以下のメッセージが出てmergeが上手く行かず。

console
$>git merge static-pages
error: cannot stat 'app/views/static_pages': Permission denied
error: cannot stat 'app/views/static_pages': Permission denied
error: cannot stat 'app/views/static_pages': Permission denied
error: cannot stat 'app/views/static_pages': Permission denied
Updating fede20e..e73741a

原因

他のアプリケーションで当該フォルダを開いていたことが原因でした。
AWS Cloud9の場合はその辺りの競合をオートマティックに解消してくれていたようです。

今回の場合はAtomを閉じることで以下の通り正しくmergeできました。

console
$>git merge static-pages
Updating fede20e..e73741a
Fast-forward
 app/assets/stylesheets/static_pages.scss         |  3 +++
...
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git ~コンフリクト が起こる前、起こった後~

はじめに

プログラミングバイトをしていて、自分の作業スピードが早くないのは技術不足という要因もあるが、gitの扱いに慣れていない、知識が十分にないという要因もあるということに気づいたのでgitに関するアウトプットを増やしていく。
今回の記事はバイト先で『この前出してもらったマージリクエストコンフリクト 起こしてるよ』と言われることに恐怖を覚えている人向けになっている。バイト先ではgitlabを使用しているのでプルリクエストのことをマージリクエストと呼ぶ。
コンフリクト を起こしてしまうと、業務の予定がくるってしまうのでできるだけ起こしたくない。今回の記事ではコンフリクト を起こさないための対策とコンフリクト が起こってしまった際の対処についてまとめる。
なお、コンフリクト を起こさないための対策に関しては自分も実践したことがなく、以下のサイトを参考にまとめた。
コンフリクト させないための覚書

コンフリクト とは?

コンフリクト はファイルの同じ箇所を編集したためにマージすることが出来なくなってしまう現象のことである。タイミングとしては一通りの作業を終え、マージリクエストを投げた際に起こる。

コンフリクト を起こさないためには

現在作業している作業ブランチをworking_branchとして、統合ブランチをkitchenブランチとする。
自分の作業用ブランチを切った後に統合ブランチkitchenが更新されているとマージリクエストを出す際にコンフリクト が起こってしまう可能性がある。(自分と同じ部分を編集したブランチがマージされているかもしれないため)コンフリクト を防止するための手順を示す。

作業内容をコミットする

git status

自分の作業状況の確認。

git add -p

addする。pオプションは差分を確認しながらaddすることができるのでお勧め。

git commit -m "コミットメッセージ"

コミット。

ローカルの統合ブランチkitchenを最新の状態にする

git checkout kitchen

kitchenにブランチ切り替え。

git pull

プルして最新の状態に。

git checkout working_branch

作業ブランチにチェックアウト

git merge kitchen

最新のkitchenを作業ブランチにマージ。

このタイミングでコンフリクト が起こる可能性がある。これをローカルで解消する。結局コンフリクト が起こるなら一緒じゃないかと思う人もいるかもしれないが、コンフリクト が起こるかもしれないという気持ちで投げるマージリクエストと、コンフリクト が起こらないことがわかって投げるマージリクエストでは次の業務に取り組む心持が変わってくると思う。
ここで注意しておきたいのが入力側の内容も取り込んでおかないとマージリクエストを出すときまたコンフリクト が起こってしまうので注意。

コンフリクト が起こってしまったときの対処

先ほどまではマージリクエストを投げたときにコンフリクト を出さないための対策についてまとめていたが、それでもコンフリクト が起こってしまう可能性はあると思う。ここではコンフリクト が起こってしまったときの対処について述べる。

マージリクエストを投げたらコンフリクト が発生したことを知らせる表示が出てしまった!!
スクリーンショット 2020-12-04 11.06.05.png

このときの対処をまとめる。

ローカルのkitchenを最新にする

git checkout kitchen 

git pull

git checkout working_branch

作業ブランチにマージする

git merge kitchen 

ここでコンフリクト した部分がエディタに反映されるので適切にコンフリクト を解消する

addする←gitにコンフリクト を解消したことを知らせる

git add コンフリクトを解消したファイル 

commit,pushする

git commit 
git push origin 作業ブランチ

これで問題なければコンフリクト解消できると思う。

さいごに

コンフリクト を起こさないための対策は自分自身も業務内で実践してなんらかの知見を得ることが出来たらまた追記しようと思う。

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

git log を1行表示にする+日付を表示する

git log を1行表示にするには、以下のコマンドで実行できる。

git log --pretty=oneline

結果:

c00ebdb099430502f90718b4e2d15f51fc351e27 (HEAD -> develop, origin/develop, origin/HEAD) Merge branch 'xxxxx' into 'develop'

しかし、この表示方法だと、日時が表示できない。そこで、--pretty=format 使うことで、日付も併せて表示させることができる。

git log --pretty=format:'%H (%ai) %s'

結果:

c00ebdb099430502f90718b4e2d15f51fc351e27 (2020-11-12 13:13:23 +0900) Merge branch 'xxxxx' into 'develop'

フォーマットの種類

公式ページに一覧が載っているが、いくつか自分が使いそうなものをピックアップしておく。

フォーマット 意味
%H コミットID
%h コミットIDの短縮版
%ai 日時表示。日時表示にも色々種類があり、このフォーマットの場合、表示は「2020-11-26 09:16:07 +0800」となる。
%an コミットした人の名前
%ae コミットした人のメールアドレス
%s コミットメッセージ(タイトル)。Bodyを表示させるには %b を使える。

参考

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