「Git」の記事 - Crieit

Git と OneDrive 等のクラウドストレージを併用する

2023-01-31T23:59:28+09:00

ブログに書きたいネタとか雑多なメモを管理する際、Git によるバージョン管理と、クラウドストレージによる同期を併用したくなる。

具体的には、こんなことがしたい：

コミットに至らないメモ書きの段階では、クラウドストレージで同期させたい
- ついでにそのメモ書きは、タブレット等の複数の端末から更新したい
ブログで記事を公開してからの差分を Git で管理

プライベートのリモートリポジトリ代わりに、ベアリポジトリを OneDrive に共有する話は見たことある (これとかこれ) のだが、私がやりたいこととはちょっと違うんだよな。
そもそも、 Microsoft 買収後に GitHub で無制限にプライベートリポジトリ作れるようになったので、 Git リポジトリの共有自体は GitHub とかで良いので。

以前、ローカルリポジトリをまるごと OneDrive で共有させてみたのだが、複数の端末で編集すると同期の競合が発生しまくってしまった。
特に .\.git ディレクトリ内でコンフリクトすると後処理が面倒くさすぎる。

どうにかならんもんか。

`.\.git` ディレクトリだけ同期除外

先に答えを言ってしまうと、クラウドストレージでの同期で特定のディレクトリの同期を除外させれば良い。

.\.git ディレクトリ内のコンフリクトが面倒なら、 .\.git ディレクトリだけ同期を除外させればいじゃない… という精神だ。

ただ、 OneDrive では一筋縄ではいかなかったので、少々トリッキーな方法を採っている。

そのやり方を、 Windows 上の OneDrive を例に紹介する。

1つ目の端末

既に OneDrive で管理しているフォルダを、 Git 管理させる方法。

同期させたいディレクトリのルート直下に .\.git フォルダを手動で新規作成する
OneDrive の設定から、アカウント → フォルダの選択から、 .\.git フォルダーを同期の対象外にする
- ローカルから .\.git フォルダが消える
git init する
- .\.git 隠しフォルダが再作成される
適当に Git のコミットしたり、 remote の追加・プッシュしたりする

この結果、 Git のリポジトリやステージングのデータを除く、ワーキングツリーのファイルだけをクラウドストレージで同期できる。

難点なのが、 OneDrive 上で「同期の問題」として以下のエラーが出続けることだ。

この名前のファイルまたはフォルダーが、同じ場所にあります。
両方のバージョンを残すには、この PCまたはオンラインのどちらかでこのアイテムの名前を変更してください。両方のアイテムが同じ場合は、この PCにあるバージョンを削除するとオンラインのバージョンをダウンロードできます。

なお、エラーが出ていても同期はされる。

リポジトリの同期

片方で push した後もう一方で pull しようとしても、先に OneDrive の同期によってワーキングツリーのファイルが更新されてしまっているので、 pull がエラーになってしまう。

こればかりはどうしようもないので、2つ目の端末のセットアップと同様、以下のように ワークツリーを維持したまま、 リポジトリとステージングを (--mixed オプション相当で) リセットしてやれば良い。

$ git fetch origin master
$ git reset origin/master

こんな感じで、期待していた環境が整った。

Android からは Jota+ あたりを使って OneDrive 上のファイルを直接更新したりしながら活用している。

【参考】: OneDrive で特定のファイル名パターンのファイルをアップロードから除外する方法

ちなみに、グループポリシーやレジストリをいじることで、「特定の種類のファイルをアップロードから除外」する事ができる (OneDrive ポリシーを使用して同期設定を制御する - SharePoint in Microsoft 365 | Microsoft Learn)。

が、残念ながらフォルダに対してはこの機能が働かないので、上記の用途を満たさない。

参考までに、やり方だけ下記に示しておく。

レジストリを弄る場合:

HKLM\SOFTWARE\Policies\Microsoft\OneDrive\ の下に EnableODIgnoreListFromGPO というキーを作る
その中に「除外したいファイル名」を名前と値の両方に持った、文字列値（複数可）を入れる
PC を再起動する

グループポリシーを使う場合:

「グループポリシーの編集」を使える状態にする
- Windows の Pro エディション以上なら標準では言っている。 Home エディションなら、ググって調べて。
C:\Users\N2633\AppData\Local\Microsoft\OneDrive\<ビルド番号>\adm\ 内の以下のファイルをコピーする
- .\OneDrive.admx を C:\Windows\PolicyDefinitions\ へ
- .\ja\OneDrive.adml を C:\Windows\PolicyDefinitions\ja-JP\ へ
Win+R で gpedit.msc を入力し「ローカルグループポリシーエディター」を立ち上げる
[コンピューターの構成] → [管理用テンプレート] → [OneDrive] → [特定の種類のファイルをアップロードから除外] を選択
構成を有効にして、キーワード一覧に除外したいファイル名（アスタリスク可）を設定する

DockerとKubernetes

2022-05-04T05:16:16+09:00

0 前提

Oracle LinuxとWindows

1 環境構築

準備

1-1 Dockerオフラインインストール

参考にしたURLはhttps://qiita.com/kod314/items/e574ac12c23598e0d903。
オンラインインストールの場合は、
https://qiita.com/kichise/items/f8e56c6d2d08eaf4a6a0
の手順に従えば可能。

今回はオフラインインストールを実行しようと思う。社内規則によりDockerをインストールするサーバがインターネット接続できない場合がある。その場合、インターネット接続できる自席端末からネットに接続してDockerのインストーラーをダウンロード。それをDockerをインストールしたいサーバに転送して実行させる。

1-1-1 OS確認

まずはOSのversionを確認。

$ uname -a
Linux publicpc1 5.4.17-2136.305.5.3.el8uek.x86_64 #2 SMP Thu Mar 17 10:45:33 PDT 2022 x86_64 x86_64 x86_64 GNU/Linux

より詳細

#cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5

Linuxカーネルの確認

$ hostnamectl
Static hostname: publicpc1
Icon name: computer-vm
Chassis: vm
Machine ID: 4c3dc5bfa43b47b8b66789ce778a0711
Boot ID: 226a196eedc746e2848a6f15e9afeb0b
Virtualization: kvm
Operating System: Oracle Linux Server 8.5
CPE OS Name: cpe:/o:oracle:linux:8:5:server
Kernel: Linux 5.4.17-2136.305.5.3.el8uek.x86_64
Architecture: x86-64

x86_64と記載されているので、Intel(AMD)の64bitオペレーティングシステムであることがわかる。

1-1-2 Docker engineをインストール

Docker本体であるDocker Engineと、同時に複数のコンテナを操作するツールであるDocker Composeをダウンロードする。
参考にした公式：https://docs.docker.com/engine/install/binaries/

まずはdocker本体
https://download.docker.com/linux/static/stable/x86_64/
→バージョンがいろいろあるので、最新のdocker-20.10.9.tgz をダウンロードしてみた。
自分の端末(クライアント側にダウンロードしたファイルをLinuxサーバに転送してから解凍する。

$ ls -al /home/opc/docker-20.10.9.tgz
-rw-r--r--. 1 opc opc 63350495 May  4 04:23 /home/opc/docker-20.10.9.tgz

展開

$ tar zxvf docker-20.10.9.tgz

すると、カレントディレクトリにdockerディレクトリが作成される。
dockerディレクトリの中身を/usr/bin/配下にコピーする。

$ sudo cp docker/* /usr/bin/

試しに起動するには

$ sudo dockerd &

1-1-3 Docker Composeをインストール

続いてはdocker-compose
インストール手順は以下に記載されているので以降この指示に従う。
https://github.com/docker/compose/blob/v2/README.md

さきほど(1-1-1節)でOSとCPUを確認したので、
それに従ってdocker-compose-linux-x86_64をダウンロードする。
https://github.com/docker/compose/releases

自分のwindows端末(クライアント側）にダウンロードしたdocker-compose-linux-x86_64をdockerをインストールしたLinuxサーバに転送。
転送したら、バイナリファイルの名前をdocker-composeにリネーム。

$ mv docker-compose-linux-x86_64 docker-compose

docker-composeをいどうする。移動する先は目的に応じて移動先が異なる。
今回は

$ sudo mv docker-compose /usr/local/bin/
$ sudo chmod +x /usr/local/bin/docker-compose
$ docker-compose -v
Docker Compose version v2.5.0

1-1-4 Docker イメージのオフラインで利用する

$ tar zxvf helloworld_img.tar.gz
$ docker load < helloworld_img # dockerイメージをload
$ docker images # hello-worldイメージが存在することを確認

1-1-5 Dockerグループ作成

Docker daemonはrootユーザで実行しなければならず、毎回sudoを使うのは面倒である。
その場合、dockerグループを作成してそこに任意のユーザを所属させてあげる。

groupadd docker
usermod -aG docker opc

1-1-6 トラブルシュート

docklerをサービスでenebleにしようと思ったができなかった。

[root@publicpc1 system]# systemctl enable docker
Failed to enable unit: Unit file docker.service does not exist.

以下のサイトを参考に対応してみた。
https://jhooq.com/docker-daemon-centos/

/usr/lib/systemd/system配下にdocker.socketファイルを作成し以下の内容を記載した。

[Unit]
Description=Docker Socket for the API

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

続いて、/usr/lib/systemd/system/配下にdocker.serviceを作成する。

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.service

[Service]
Type=notify
#the default is not to use systemd for cgroups because the delegate issues still
#exists and systemd currently does not support the cgroup feature set required
#for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

#Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
#Both the old, and new location are accepted by systemd 229 and up, so using the old location
#to make them work for either version of systemd.
StartLimitBurst=3

#Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
#Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
#this option work for either version of systemd.
StartLimitInterval=60s

#Having non-zero Limit*s causes performance problems due to accounting overhead
#in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

#Comment TasksMax if your systemd version does not support it.
#Only systemd 226 and above support this option.
TasksMax=infinity

#set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

#kill only the docker process, not all processes in the cgroup
KillMode=process
OOMScoreAdjust=-500

[Install]
WantedBy=multi-user.target

この中身をみるとRequires=docker.socket containerd.serviceと記載されている通り、containerd.serviceが必要。なので/usr/lib/systemd/system配下にcontainerd.serviceサービスを作成する必要がある。

#Copyright The containerd Authors.
#Licensed under the Apache License, Version 2.0 (the "License");
#you may not use this file except in compliance with the License.
#You may obtain a copy of the License at
#http://www.apache.org/licenses/LICENSE-2.0
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an "AS IS" BASIS,
#WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#See the License for the specific language governing permissions and
#limitations under the License.

[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/bin/containerd

Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
#Having non-zero Limit*s causes performance problems due to accounting overhead
#in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=infinity
#Comment TasksMax if your systemd version does not supports it.
#Only systemd 226 and above support this version.
TasksMax=infinity
OOMScoreAdjust=-999

[Install]
WantedBy=multi-user.target

上記を作成する。

ちゃんとリロードしとく。

systemctl daemon-reload

1-2.Kubernetesの準備

1-2-1. インストール

オフライン環境でKubernetesを構築する手順。
手順の参考にしたのは以下
https://docs.genesys.com/Documentation/GCXI/latest/Dep/DockerOffline

まずはネットにつながる端末から

$ pwd
/etc/yum.repos.d
$ cat kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

以下のコマンドを実行してファイルをダウンロード。
の部分は自分で適当なディレクトリを作成して
そこのパスを指定。

yumdownloader --assumeyes --destdir= --resolve yum-utils kubeadm-1.21.* kubelet-1.21.* kubectl-1.21.* ebtables

続いて、ダウンロードしたファイルをインストールしていく。

yum install -y --cacheonly --disablerepo=* /*.rpm

インストールする際、バージョンが異なるファイルが存在してインストールエラーになるかもしれない。
その場合は、必要のないバージョンのファイルは削除してから
再度インストールするとうまくいく。
うまくいくと以下のようになる。

Complete!

必要なイメージが揃っているか確認してみよう。

$ kubeadm config images list
I0504 23:15:36.977910  309762 version.go:254] remote version is much newer: v1.24.0; falling back to: stable-1.21
k8s.gcr.io/kube-apiserver:v1.21.12
k8s.gcr.io/kube-controller-manager:v1.21.12
k8s.gcr.io/kube-scheduler:v1.21.12
k8s.gcr.io/kube-proxy:v1.21.12
k8s.gcr.io/pause:3.4.1
k8s.gcr.io/etcd:3.4.13-0
k8s.gcr.io/coredns/coredns:v1.8.0

1-2-2. kubectlの概要

参考URL:https://kubernetes.io/ja/docs/reference/kubectl/_print/
Kubernetesクラスタを操作するコマンド

2.Docker入門

Git で別ブランチから特定のファイルのみチェックアウトする

2021-12-12T12:39:24+09:00

Git で別ブランチから特定のファイルのみチェックアウトする方法を知ったので試しました。なお、 Git は 2.33.1.windows.1 で試しました。

今回は Ambergrease で。該当プロジェクトは mainブランチと MySQL のバージョンを 8.0 から 5.7 に落とした mysql5.7ブランチが存在するため、うってつけの条件でした。

別ブランチのファイルを参照

> git show main:workspace/entrypoint_web.sh

#!/bin/bash

# gen key & certificate
openssl req -new -newkey rsa:2048 -nodes -out /etc/ssl/private/server.csr -keyout /etc/ssl/private/server.key -subj "/C=/ST=/L=/O=/OU=/CN=*.lvh.me"
openssl x509 -days 365 -req -signkey /etc/ssl/private/server.key -in /etc/ssl/private/server.csr -out /etc/ssl/private/server.crt

# 略

mysql5.7ブランチで mainブランチの workspace/entrypoint_web.sh を参照。OKです。

別ブランチから特定のファイルをチェックアウト

試しに、 WP-CLI のインストールの条件分岐を mainブランチには入れているが mysql5.7ブランチには入れていない状態のリポジトリを作ります。

このリポジトリで mysql5.7ブランチに移動し、次のコマンドを実行。

> git checkout main -- workspace/entrypoint_web.sh
>

これで mainブランチから WP-CLI のインストールの条件分岐の部分が入ったエントリポイントのシェルスクリプトが mysql5.7ブランチにチェックアウトされ、上書き&ステージングまでされました。

今回のケースではWebサーバ側は共通なのでバッティングも気にせず、そのままコミットで大丈夫なケースです。こういう場合は便利ですね。

別ブランチから特定のファイルをチェックアウト (コンフリクト想定)

次に、DB側のエントリポイントで一ヶ所修正をします。

修正内容は該当リポジトリでは「 MySQL のログを削除せずにコンテナを再度ビルドすると、ログの最初の初期パスワードを拾ってしまうため、 root のパスワード置換処理でコケることを回避するために最後の結果を使用するように awk コマンドを修正」というもの。

先程とは逆に mysql5.7ブランチで先に修正を施します。

-    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk '{print $11}')
+    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk 'END{print $11}')

awk に END を追加しています。

一方、 MySQL8.0 環境用の mainブランチでは該当箇所は次のようになっています。

    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk '{print $13}')

ログの出力フォーマットが変わった結果、空白区切りで11番目ではなく13番目に初期パスワードが出現します。そのため、 awk の中身が {print $11} ではなく {print $13} 指定になっています。

この状態で、先程と同じようにチェックアウトのコマンドを実行。

> git checkout mysql5.7 -- workspace/entrypoint_db.sh

すると、次のようになりました。

-    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk '{print $13}')
+    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk 'END{print $11}')

完全に mysql5.7ブランチの内容で上書きされていますね。どうやら、そのままだと上書きしてしまうようです。

こういうケースでは注意するか、コンフリクトと同じような状態を起こすオプションがあったりするのでしょうか(未確認)。

とはいえ、先程の共通部分をチェックアウトできるだけでも便利なので、覚えておいて損はなさそうです。

Git の認証情報について

2021-03-13T23:47:53+09:00

AskPass.exe のエラー関係の対処の続きです。

エラーでフォーカスが外れて入力を邪魔されることはなくなりましたが、一瞬表示されては消えるダイアログが気になるので、追加調査です。

相変わらず認証情報で何らかの問題が発生していると考えられるため、認証情報周りの状況を確認します。

ます、何によって Git の認証情報が管理されているか確認します。

> git config --list

## 略

credential.helper=manager

## 略

今回は Windows PC なので manager は「Git Credential Manager for Windows」を指すことになります。

また、検索すると git config --show-origin --get credential.helper のコマンドから辿っていくこともできます。

> git config --show-origin --get credential.helper
file:PATH/TO/Users//.gitconfig       manager

ユーザディレクトリ直下の .gitconfig に情報がある、と出ます。

[credential]
    helper = manager

.gitconfig を見ると、こちらも manager になっていることが確認できます。

上述より「Git Credential Manager for Windows」であることが分かったので、次にその情報を確認します。

「コントロールパネル」→「ユーザーアカウント」→「資格情報の管理」を開き、「Windows 資格情報」をクリックします。

この中に Git 関連の資格情報も含まれています。……が、特に怪しい情報はなし。

Git の認証情報の管理の仕方は分かりましたが、今回は原因究明には至りませんでした。

追記

その後、 SourceTree で開いているリポジトリを一つずつ調べていった結果、ユーザ名をコピペミスで間違えていたリポジトリを発見しました。

これが原因 (開きっ放しにしているリポジトリのリモートリポジトリに該当するユーザ名が SorceTree で管理されていない → AskPass.exe でエラーが多発(or 認証画面ダイアログが表示されては一瞬で消えるを繰り返す)) な気がしてきました。

ユーザ名のミスを修正して、またこれで様子見にしたいと思います。

Askpass.exe の「アプリケーションを正しく起動できませんでした」というエラーへの対処 (アカウント追加編)

2021-03-13T23:39:32+09:00

ある日突然 Askpass.exe から「アプリケーションを正しく起動できませんでした」というエラーが表示されるようになってしまったため対処の2点目。アカウントがいくつか足りないので設定し直します。

今回足りないアカウントは GitLab EE のアカウントです。

SourceTree の「ツール」→「オプション」→「認証」に進み、「追加」をクリック。

ホスティングアカウントを設定」ダイアログが開いたら、「ホスティングサービス」から「GitLab EE」を選択し、「ホスト URL」を入力します。 Credentials の「認証」は「Personal Access Token」しか選べないのでそのままで、続いて「Personal Access token を再読み込み」をクリックします。

すると Personal Access Token の認証ダイアログが開きます。「ユーザー名」は自分のユーザー名を入れます。

問題は「パスワード」。これは通常のパスワードではなく、上述の Personal Access Token を入力します。

そこで GitLab にログイン。

ユーザーのアバターアイコンからメニューを開き、「設定」画面を開きます。続いてサイドバーから「アクセストークン」へ。

Personal Access Token 発行画面をひらいたら、「Scopes」の中で「api」を選択し、「Create personal access token」ボタンをクリック。

すると、「Your New Personal Access Token」が表示されます。この Personal Access Token はテキストボックスのミュートテキストの通り、この画面でしかアクセスできず、一度他のページに遷移したり閉じたりすると二度とアクセスできません ( Revoke して再発行になる)。必ず控えておきましょう。

発行が完了すると、発行画面の下に一覧で表示されます。ご覧の通り「Revoke」しか表示されておらず、先程のページで表示されていたトークンへはアクセスできません。

さて、先程の Personal Access Token を開きっ放しにしていた SourceTree の認証ダイアログの「パスワード」にコピペして「OK」をクリックします。

すると、認証が成功し、「ホスティングアカウントを設定」画面で「✅認証に成功」が表示されるようになります。これでOKです。

Askpass.exe の「アプリケーションを正しく起動できませんでした」というエラーへの対処 (仮)

2021-03-05T00:02:35+09:00

現象

ある日突然 Askpass.exe から「アプリケーションを正しく起動できませんでした」というエラーが表示されるようになってしまいました。

Askpass.exe - アプリケーションエラー

アプリケーションを正しく起動できませんでした (0xc0000142)。[OK] をクリックしてアプリケーションを閉じてください。

しかも一度だけではなく、放置していると同じエラーダイアログが溜まって数～十数回「OK」をクリックするはめになります。

発生するタイミングはランダムのように見えるため、文字入力やコーディング中にエラーダイアログが起動して入力を妨げられることも……。

さすがに作業しづらいので、対処することにしました。

調査

検索すると Askpass.exe はどうも SourceTree のコンポーネントで Git で使用する SSH の鍵を管理する部分に関する GUI を担うようです。

Solved: What is askpass.exe?

関連する場所としては、 SourceTree の「ツール」→「オプション」→「認証」のところの設定周りでしょうか……。

以上より、 SourceTree 周りの環境を整理すると以下の通りです。

OS: Windows 10 環境
Git: SourceTree が持っている Git ではなく、システムインストールの Git を使用。バージョンは 2.30.0.windows 。
SourceTree: 3.4.2.0

対処1 (失敗)

Askpass.exe 自体は Gitクライアントにも類似のファイル (git-askpass.exe) が存在していた (PATH\TO\INSTALLED_DIRECTORY\Git\mingw64\libexec\git-core下)のと、 Git のマイナーバージョンが上がっていたので以下のようにしました。

Gitクライアント本体: 上書きインストールによるアップデート (2.30.0.windows → 2.30.0.windows.2)
SourceTree: コントロールパネルからアンインストール→再度インストール (3.4.2.0)

が、改善せず。 SourceTree にいたっては設定などの情報が残っていたため、アンインストールで綺麗に消えていたわけでもなさそう……。

対処2

そこで今度は SourceTree 関連のファイルを削除することにしました。

SourceTree の「ツール」→「オプション」→「認証」で保存されているアカウント情報を手動で全て削除
SourceTree を閉じる
コントロールパネルから SourceTree をアンインストール
PATO\TO\Users\\AppData\Local\Atlassian 配下のファイルを別フォルダにバックアップ
PATO\TO\Users\\AppData\Local\Atlassian 配下のファイルを全部削除 (過去バージョンのものも含めて)
- SourceTree のナレッジベースでは個人設定情報をリフレッシュさせるには以下の手順で良いそうですが、今回はきれいさっぱりにしたかったためあえて全部削除しました
  1. SourceTree を閉じる
  2. PATO\TO\Users\\AppData\Local\Atlassian\SourceTree\ と PATO\TO\Users\\AppData\Local\Atlassian\SourceTree.exe<ランダム文字列>\<バージョン番号(今回は 3.4.2.0)>\ フォルダのファイルをバックアップ
  3. PATO\TO\Users\\AppData\Local\Atlassian\SourceTree\下の以下の3つのファイルを削除
    - bookmarks.xml
    - opentabs.xml
    - userhosts
  4. PATO\TO\Users\\AppData\Local\Atlassian\SourceTree.exe<ランダム文字列>\<バージョン番号(今回は 3.4.2.0)>\下の user.config ファイルを削除
  5. SourceTree を起動し、正常に動作するか確認する
SourceTree を再度インストール
- Bitbucket or Bitbucket Server の選択: スキップ
- オプション:
  - Mercurial もインストール
  - 改行の自動設定: チェックを外す (Git本体側で LF 統一するようにしているため)
  - ユーザ名・メールアドレス: Git本体に記憶されている情報を使用
  - SSH鍵の読み込み: 「いいえ」でスキップ
- インストール完了後: 「ツール」→「オプション」→「Git バージョン」で「System」となっていることを確認 (SourceTree 本体で持っている Git ではなく、インストール済みの Git を使用)

これでSourceTree の「ツール」→「オプション」→「認証」を開くと……なぜかいくつかのアカウント情報が記録されていました。おそらく Git 本体に記録されていた情報だと思います詳細は不明……。

ただし、全てではないので改めて追加する必要があります。それについては別途設定するということで、ひとまず今回はこれで様子見とします。

様子見の結果

様子を見ていた結果ですが、冒頭のエラーは表示されなくなりました。

代わりに、同じようなタイミングで認証のダイアログが表示されるのですが、一瞬で閉じられるため今のところさほど影響は出ていません。

一旦解決、といったところでしょうか。

【GitBash】黒い画面でコミット履歴をGUIっぽく見たい

2020-12-25T00:50:10+09:00

黒い画面のうえでもうちょっと見やすくコミットログが見たい！！！

コマンド上でも、GUIにまけないくらい見やすいログの見方をメモ( ..)φ

以下は一般的なもの、枝とかわからないし見づらい。。。
コマンド:git log

git log --graph --oneline --decorate

ちょっとコミット数が少なくてわからないが、樹形図みたく表示できる

参考リンク

tig --all

何日とかその辺まで表示される。

この画面から抜けるときはqを押下すること

参考リンク

PowerShell で Git の reset/stash などを使う際に履歴を指定する方法

2020-10-04T23:29:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: PowerShell で Git の reset/stash などを使う際に履歴を指定する方法 - 雑木林

TL; DR

中括弧で表記する文字列は ' で囲みましょう。

はじめに

みなさんおなじみ、履歴を戻すコマンドは、下記の通りです。

gitで履歴を戻すコマンド（実行不可）

git reset HEAD@{0}

また、スタッシュを適用するコマンドは、下記の通りです。

gitでスタッシュを適用するコマンド（実行不可）

git stash pop stash@{0}

しかし、 PowerShell で上記を実行しようとすると、次のエラーが発生し、履歴リセット／スタッシュ適用できません。

PowerShellで履歴を戻そうとした際のエラー

error: unknown switch `e'

解決策

PoserShell では、中括弧に特別な意味があるため（スクリプトブロックと呼ぶらしい）、中括弧内の文字列をコマンドとして実行してしまうからみたいです。

about_Script_Blocks - PowerShell | Microsoft Docs

' で囲み文字列化することで、実行できます。

gitで履歴を戻すコマンド（文字列化）

git reset 'HEAD@{0}'

gitでスタッシュを適用するコマンド

git stash pop 'stash@{0}'

または、中括弧エスケープ処理をすることでも可能です。
PowerShell のエスケープシーケンスは ` ですよね。

gitで履歴を戻すコマンド（エスケープ処理）

git reset HEAD@`{0`}

git reset HEAD@{1} results in error · Issue #106 · dahlbyk/posh-git

おわりに

エラー文だけでは理解できず、地味に苦労しました。
PowerShell は ~~めんどくさい~~ 奥が深いですね。

Gitのコミットメッセージに絵文字付きプレフィックスを適用する

2020-10-04T23:25:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Gitのコミットメッセージに絵文字付きプレフィックスを適用する - 雑木林

TL; DR

コミットメッセージのプレフィックスは、Angularスタイルを基準としています。
また、各プレフィックスに絵文字を付ける際は、下記のようにしています。

プレフィックス	絵文字	絵文字の綴り
feat	✨	sparkles
fix	🐛	bug
docs	📝	memo
style	📁	file_folder
refactor	♻️	recycle
perf	⚡️	zap
test	✅	white_check_mark
chore	🍰	cake
init	🎉	tada
merge	🔀	twisted_rightwards_arrows
review	👌	ok_hand
wip	🚧	construction

はじめに

コミットメッセージにプレフィックスを付ける文化が、少しずつ広がっています。

一方、コミットメッセージに絵文字を付ける文化も、広まりつつあります。

両者を組合せれば、最強のプレフィックスが出来上がるのではないかと考えました。
ということで、絵文字付きプレフィックスという考え方を提案し、ここに記すこととします。

コミットメッセージにおける絵文字の付け方

コミットメッセージに、絵文字名を : で挟むことにより、GitHub上で表示できます。
また、コンソール上では、 emoji-cli などを利用することで、表示が可能です。

コマンドラインで emoji を扱う - Qiita

例えば、 ✨ (sparkles) という記号をコミットメッセージに書きたい場合、コミットメッセージを次のように記述します。

:sparkles: feat(ruby): やさしい日本語ページのルビタグ対応

すると、GitHub上のコミットメッセージとして登録されます。

covid19-miyazaki/covid19: 宮崎県(非公式) 新型コロナウイルス感染症対策サイト / Miyazaki COVID-19 Task Force website

コミットメッセージの1行目は、表示できる文字数に制限があるため、長すぎる絵文字名の絵文字は気をつけたほうがいいかもしれません。

git commit 時に書くコミットメッセージ1行目の表示文字数上限を調べてみた - Qiita

各プレフィックスと絵文字の紐付け

大前提として、プレフィックスを使う場合は、リポジトリ内で統一する必要があります。
これは、プレフィックスを使ったとしても、意味がわからなければ伝わらないからです。
同様に、多くの種類の絵文字を使うことも否定的です。
これからの時代は、プロジェクト毎に、コーディングスタイルと共にコミットメッセージスタイルも定義する必要があると思います。

今回は、Angularスタイルのプレフィックスを参考にします。
~~理由は、それ以外のスタイルを知らないからです。~~

angular.js/DEVELOPERS.md at master · angular/angular.js

また、絵文字については、Gitmojiを参考にします。
~~理由は、サイトが綺麗だからです。~~

gitmoji | An emoji guide for your commit messages

オリジナル絵文字を利用する場合は、GitHubで使える絵文字チートシートを参考にします。

🎁 Emoji cheat sheet for GitHub, Basecamp, Slack & more

以降、各プレフィックスの内容を説明し、それに見合った絵文字を紹介します。

feat

feat: A new feature

新機能を追加する際に利用します。

Gitmojiでは、同等の絵文字として ✨ (sparkles) を定義しています。
新機能を導入する際に使う絵文字です。

:sparkles: Introducing new features.

ということで、 feat には ✨ (sparkles) を利用します。

余談ですが、新機能というと、無かった機能を追加した際のみにも聞こえます。
僕の場合は、既存機能を変更する際や、既存機能を削除する際にも使っています。
変更／削除についても、変更することによって統一性が図れるとか、削除することによってUIが向上するとか、変更／削除そのものが機能追加という場合が多いなーと思っていたからです（いわゆる enhansement と同じ意味として捉えています。
これについては、プロジェクト毎に決めておくといいかもしれません。

fix

fix: A bug fix

不具合を修正する際に利用します。

Gitmojiでは、同等の絵文字として 🐛 (bug) を定義しています。
意味は全く同じです。

:bug: Fixing a bug.

ということで、 fix には 🐛 (bug) を利用します。

また余談ですが、個人的には、修正コミットに 🐛 を付けることは、若干抵抗があります。
GitHubでIssueファーストの開発をしていると、Issueでは不具合発見として 🐛 を付けて、修正プルリクとして 🐛 の絵文字を付けてしまいませんか？
🐛 という絵文字自体には2つの意味があるからです。

不具合発見時
不具合修正時

前者は 🐛 で問題ないのですが、後者については考える余地があるはずです。
もし虫網や虫籠の絵文字があれば、それを使っていたのですが......

コミット時に不具合を意図的に入れることは考えられない点と、不具合発見時をコミットメッセージで表すことが無い点、さらに不具合 == バグ == 🐛 を知らないエンジニアがほぼいない点を考慮して、 fix には 🐛 がいいかなと考えました。

docs

docs: Documentation only changes

ドキュメント類を修正する際に利用します。
修正と言っていますが、追加や削除時にも使ってよいと思います。

Gitmojiでは、同等の絵文字として 📝 (pencil) を定義しています。
ドキュメント類を記述する際に利用します。

:pencil: Writing docs.

また、 pencil と memo は、GitHubでは同じ絵文字として認識されます。

ちなみに、鉛筆だけの絵文字は pencil2 です。
~~これは酷い......~~

ということで、 pencil では文字ベースとして判断しづらい点から、 📝 (memo) を利用します。

style

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

ソースコードの可読性を変更する際に利用します。
Lintを適用した際や、空行を追加した際など、振舞いに変化を与えない変更が該当します。

Gitmojiでは、 🎨 (art) が当てはまるかもしれません。
🎨 は、ファイル構造を変更する際、または、ソースコードのフォーマットを変更する際に利用します。

:art: Improving structure / format of the code.

style という観点で言えば、2番目の意味に該当することは間違いありません。
また、1番目の意味も、ファイル構造の style という側面で見れば、該当すると見ることもできます。

しかし、 art という単語からは、UIに関連しそうなイメージが付きます。
実際、下記のようなIssueも上がっています。

🎨 for design and 📐 for structure · Issue #320 · carloscuesta/gitmoji

style という内容に合わせるため、ここでは 📁 (file_folder) を利用します。

📁 File Folder Emoji

refactor

refactor: A code change that neither fixes a bug nor adds a feature

ソースコードの可読性を向上する際に利用します。

Gitmojiには、同等の絵文字として ♻️ (recycle) を定義しています。
意味はほとんど同じです。

:recycle: Refactoring code.

ということで、 refactor には ♻️ (recycle) を利用します。

perf

perf: A code change that improves performance

パフォーマンスを向上する際に利用します。

Gitmojiには、同等の絵文字として ⚡️ (zap) を定義しています。
意味は全く同じです。

:zap: Improving performance.

ということで、 perf には ⚡️ (zap) を利用します。

test

test: Adding missing or correcting existing tests

テストコードを追加する際や、既存テストコードを修正する際に利用します。

Gitmojiには、同等の絵文字として ✅ (white_check_mark) を定義しています。
意味は全く同じです。

:white_check_mark: Updating tests.

また、チェックマークの絵文字は、他にも ✔️ (heavy_check_mark) が存在します。

正直、どちらでもいいとは思います。
個人的には、Windowsでの開発が多かったため、 ✔️ を利用していました。
✔️ のチェックの色が緑色で、わかりやすかったためです。

しかし、他OSではチェックの色が黒色で、わかりづらくなっています。
一方、 ✅ は、殆どのメーカーが緑色矩形の白抜きチェックであり、わかりやすくなっています。

ということで、 test には ✅ (white_check_mark) を利用します。

chore

chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

自動生成ツールによりファイルを変更する際に利用します。
chore とは、雑務という意味があります。

choreの意味・使い方・読み方 | Weblio英和辞書

Gitmojiには、該当する絵文字はありません。
一部分で該当しそうな絵文字は、いくつか定義しています。

少し頭を悩ませましたが、英語圏のスラングである 'It's a piece of cake' から取って、 🍰 (cake) を利用します。

it's a piece of cakeの意味・使い方・読み方 | Weblio英和辞書

Angularスタイル以外

以下は、Angularスタイル以外のコミットメッセージで利用する絵文字です。
プレフィックスは付けても付けなくても構いません。

First commit

最初のコミットとしてよく使われる first commit ですが、Gitmojiでは 🎉 (tada) として定義しています。

:tada: Initial commit.

ということで、 first commit には 🎉 (tada) を利用します。
プレフィックスは init とします。

余談ですが、個人的には first commit を空メッセージにするのは懐疑的です。
必要無いから消したのか、書き忘れたのか、空メッセージでは判断できないためです。

Gitの最初のコミットは空コミットにしよう - Qiita

Merge commit

マージ実行時のコミットですが、Gitmojiでは 🔀 (twisted_rightwards_arrows) として定義しています。

:twisted_rightwards_arrows: Merging branches.

ということで、マージコミットには 🔀 (twisted_rightwards_arrows) を利用します。
長いですが、マージコミットの1行目はあまり重要であることは少ないため、問題なしとします。
プレフィックスは merge とします。

Review commit

レビュー指摘反映時のコミットですが、Gitmojiでは 👌 (ok_hand) として定義しています。

:ok_hand: Updating code due to code review changes.

ということで、レビュー指摘反映コミットには 👌 (ok_hand) を利用します。
~~あまり個人的には多用しないようにすべきとは思いますが......~~

WIP commit

作業中コミット (WIP: Work in Progress) ですが、Gitmojiでは 🚧 (construction) として定義しています。

:construction: Work in progress.

ということで、作業中コミットには 🚧 (construction) を利用します。
プレフィックスは wip とします。

おわりに

現在ではプライベートリポジトリでしか利用してませんが、個人的には可読性が上がっている気がします。
これを開発チームに展開して共有できれば、また違った世界が見えるかもしれません。

絵文字は、用法用量を守り、適切にご利用ください。

ちなみに

Gitmojiでは、本記事と似たようなIssueが立っていました。
もしかしたら、Gitmoji側で方針が決まるかもしれません。

Add a "semver" field for each emoji · Issue #429 · carloscuesta/gitmoji

こんなリポジトリもあります。
これを使えば、本記事の内容をPJで統一しやすくなりますね。

negokaz/git-fancy-message-prefix: A Git prepare-commit-msg hook for fancy commit message

WindowsのVSCodeでファイルをgit addしようとするとoutside repositoryエラーが出る

2020-07-27T08:40:30+09:00

VSCodeのUIで編集したファイルのプラスボタンを押してgit addしようとすると、下記のようなエラーが出るようになっていた。結構古いプロジェクトだった。他のプロジェクトでは発生しない。Windowsだけ発生する現象かもしれない。

fatal: d:\users\documents\apps\app\src\entity\Answer.ts: 'd:\users\documents\apps\app\src\entity\Answer.ts' is outside repository

これによりaddができない。試しにシェルでaddしてみたら普通にaddできた。VSCodeのUIでだけaddできない。

調べてみると、 git update-git-for-windows でgit自体をバージョンアップすれば良いらしい。詳しくは下記の情報。

https://stackoverflow.com/questions/13790592/how-to-upgrade-to-the-latest-version-of-git-on-windows-still-showing-older-vers

とにかくgitのバージョン2.13あたり以前だと発生するらしい。多分ドライブ文字列が小文字になってるところが原因っぽいのだろうと。何にしろ詳しくはわからないが、バージョンアップすれば改善した。

バージョンの確認

git version

アップグレード

git update-git-for-windows

共通の設定をリポジトリ化する

2020-01-13T14:41:18+09:00

経緯

現在、私が運営しているサービスのうち、

野球スコア掲載プラットフォーム
みんなのSCORE
キャップ野球総合サイト
キャップ野球情報局

この2サービス、共通のアプリケーションサーバを持っていてUIが異なるだけなのです。

画像や設定など、2つのサイト(異なるリポジトリ)間で同じものを共有したい場合、
別のリポジトリからnpm installするのがよいようです。

実際に作ってみる

今回は試合のIDとyoutubeやtwitterのツイートを紐づけするconfigファイルを
共通リポジトリに置きます。

今回作ったリポジトリのindex.js

export { twMovieConfig } from './config/twMovieConfig';
export { youtubeConfig } from './config/youtubeConfig';

共有したいファイルをexportする。

package.json

{
  "name": "common",
  "version": "0.0.202001131200",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "description": ""
}

インポートする側のpackage.json

 {
    "dependencies": {
    ........
        "common": "https://github.com/ckoshien/common.git"
    }
  }

課題

変更があった場合は毎回npmインストール
package-lock.jsonを削除しないとインストールできない
package.jsonのバージョンを上げないと変更があったと認識されない

MinQ開発日記 (7) 認証情報を含んだプロジェクトをGitで管理する

2019-12-21T15:38:21+09:00

認証情報を含んだプロジェクトをGitで管理する

モチベーション

GORMでデータベースへアクセスする場合ユーザー名やパスワードが必要でした. こうした認証情報をgitで管理してGitHubのようなリモート・リポジトリに上げてしまうのは例え非公開でも大変危険です. かといってこれをプロジェクト外部で管理すると, デプロイ時にめんどいうになりそうです. 後間違えコミットしてしまうということも有り得ます.

用語

PGP (Pretty Good Privacy)

暗号化プログラムで, 公開暗号方式を使うようです.

GPG (GnuPG)

GNUによるオープンソースなPGPです.

pinentry

GnuPGがパスフレーズやPIN番号を読み取れるようにするプログラムのようです. なくても良さそうでは有ります.

gpg-agent

秘密鍵を管理してくれるデーモンのようです. ssh-agentと同じようなもののようです.

gpg-agent is a daemon to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities.

gpg-agent(1) - Linux man page

If the agent process has the key, it provides it to gpg. If it doesn't, it attempts to load the encrypted key from your keyring, and prompts you for the key's passphrase. Once the agent has obtained the decrypted key, it passes it to the gpg process. In addition to GPG keys, Gpg-agent can similarly store SSH keys and provide them to SSH processes, like the ssh-agent program that comes with SSH.

How does GPG agent work?

gpg-agent is mostly used as daemon to request and cache the password for the keychain.

gpg-agent

gpg-agent can be configured via the pinentry-program stanza to use a particular pinentry user interface when prompting the user for a passphrase.

pinentry

用語の整理

名前	用途
GPG(GnuPG)	暗号化や署名の生成を行うプログラム
Pinetnry	GPGにパスフレーズやPIN番号を安全に渡すプログラム
gpg-agent	GPGの代理として鍵を管理するプログラム?

GPG本体とgpg-agentの違いというか役割分担がよく分かっていませんね😅

GnuPG

導入

brewを使うと簡単にできます

brew install gnupg gnupg2 pinentry-mac gpg-agent

gpg-agentにpinentry-programを指定します.

which pinentry-mac
echo "pinentry-program /usr/local/bin/pinentry-mac" >>~/.gnupg/gpg-agent.conf
cat ~/.gnupg/gpg-agent.conf

ところがgpg-agentは存在しません. GPG 2.1以降はgpg-agent付属して配布されているようです.

gpg-agent not found for homebrew

It expects that the reader is familiar with GnuPG version 2.0 and aware that GnuPG consists of gpg, gpgsm, and gpg-agent as its main components.

GnuPG

これでGPGで鍵を生成するときにパスフレーズが求められるとpinentry-programであるpinentry-macが起動するはずです. が, どうも2.0以降はpinentry-programの設定が変わっているようで動きませんでした. Stackoverflowに質問しておきました.

Where should I specify a pinentry program for GnuPG 2.0 and later?

とりあえずなしでいきます.

鍵の生成

必要となる情報は以下です.

名前
e-mail
パスフレーズ

gpg --generate-key

で用意した情報を入力しましょう.

git-crypt

導入

こちらもbrewでインストールします.

brew install git-crypt

利用

git-crypt を使って秘密情報を版管理するを参考にしてやってみましょう.

まとめ

これで公開鍵を知らない人は中身を見れなくなりました. よってGitHubにアップロードして問題ないと思われます. VPSに公開鍵をアップロードしておけばgit crypt unlockで復号化されます.

課題

デプロイするときに面倒が増します. Gitのフックはpush時しか出来ないからです. のでGitHubはリモート・リポジトリと割り切ってデプロはAnsibleとか使った方が良いと思いました.

AnsibleでGoアプリをデプロイ

Reference

An Introduction to Managing Secrets Safely with Version Control Systems
本番用の.envを外部に一切知られずに安全にgithubで保存する方法
 git-crypt を使って秘密情報を版管理する

C#を本業にしているスクリプトキディが思いついた、私史上最強の三文未満小説執筆環境

2019-10-08T01:05:45+09:00

3畳に足りるか足りないか分からないシェアハウスの個室で、間接照明とディスプレイの明かりを頼りに、
この文章を自作した左右分離式キーボードで書いている。

Emacsで。厳密に言うと、DOOM Emacsだ。

そんな私がなぜ久々に文章を打っているかといえば、
就業中にわだかまっていた三文小説未満のライトノベルにも満たないプログラミング入門以前物語のそれを書きたくなったり、
書くに至って良いやり方をいろいろ考えていたら、思いついたのでまとめているわけである。

Emacsは最強の執筆環境

この記事に何らかのきっかけで行き着いた方々には釈迦に説法だとは思うし、
もっとLispを使いこなしているEmacsユーザーに対しては僭越だが、
一応Emacsというエディタについて簡単に自分が今（2019-10-07T22:46）資料を見ないでできる限りの
紹介をさせていただく。

Emacsという古来から存在するテキストエディタ

古来（といってもUNIXが生まれてからではあるので、西暦1980年以降である）から存在するテキストエディタであるが、
その拡張性の高さと、拡張性ゆえの可能性の多さから、このエディタのファンは多く、根強い支持を得ている。

とかく書いてる私自身も2年前から少しずつEmacsを触り始めた口で、それまではVimという双対をなすテキストエディタを使っていた。

（ほぼ）文字だけで表現するテキストエディタ

これら（Emacs,
Vim)の特徴としては、ほぼすべてを文字で表現することにある。

ドットインパクトプリンタなどの出力機器しかなかった時代から見るとずいぶんと贅沢かもしれないが、
2000年以降に生まれた若い人たちからすると、ずいぶんと貧相に思うかもしれない。
今日のEmacs,
その拡張機能と適切なフォントをインストールすれば、絵文字などを利用して見栄えは良くなる。

「ダサい」？　違う、洗練されているのだ。

とはいえ、EmacsはCtrlやAltなどの装飾キーを酷使し、Vimは3つのモードを把握しなければいけないなどの
参入障壁があり、それ以前におそらく最初の見た目はWindowsのメモ帳と代わり映えしないだろう。

「ダサい」と思われるかもしれない。しかし本当にダサいのだろうか。

私は憧れる。必要な時に必要な道具をサッと出し、作業に取り掛かり、必要が無くなったらしまう。

それができるのがこれらのエディタの強さである。

Org-modeは至高の（ドキュメント｜タスク管理｜プロジェクト管理）テキストフォーマット

執筆に適したテキストフォーマットを作るという行為の非現実性

とはいえ、テキストエディタが優秀で拡張性に優れているからと言って、自前で執筆に適した拡張機能を作るのは骨が折れる。

ましてや進捗やHTMLファイル（Webブラウザで閲覧できる形式）への変換出力機能も実装するのは、自分のような専門学校卒業程度の、
ほぼ文系コーダーに毛が生えてるか生えていないか程度のプログラマというのもおこがましい劣化知的生命体には無茶な話で、
仕事の余暇に作るなんて、人間の平均寿命から20年ほど引いた年数ではできるものではない
（たまにそれを成し遂げる者も居るが、それは天才と言われる超人類にしか当てはまらない）。

巨人の肩に腰を据える

今日、オープンソースソフトウェア・フリーソフトウェアという文化が広まり、インターネットにつながるパソコンがあれば、
天才達が考えたプログラムを自由に利用し、技術があれば改造したり、更にその天才が気づかなかった不具合を治すことだってできる。
　
Emacsの文化から生まれたOrg-modeもその一つだろう。

Org-modeはそのよく考えられたテキストフォーマットと、文字列情報を解析して機能を与えるEmacsが織りなす、

メモ
ジャーナル
文書
タスク管理
プロジェクト管理

上記全て（さらに数個以上）に対応するテキストフォーマットなのである。

MarkdownやreStructuredTextも拡張することでこれらを全て受け持つテキストフォーマットになるだろう。
ただ、Emacs
Lispという強力なテキストエディタの拡張性により、テキストエディタとシンプルな軽量マークアップ言語
で実装できたと私は思う。

実際にどう書くのか。

さて、ここからそんなEmacsとOrg-modeを利用して執筆する方法を見てみよう。

とにかく見出しを作る

とにかく見出しを作る。

更に細分化した見出しを作る

その見出しを細分化する。

アニメの絵コンテの一枠や、マンガのヒトコマくらいに細分化してしまっていい。

そのシーンを1行でまとめた描写を

更にその見出しを細分化する。段落レベルまで細分化してしまっても良い。

私の様な人間は特に、「これは5分で書けるだろう」　
くらいのレベルまで細分化してしまったほうが良いと思う。

見出しを `TODO` にしてしまう

Org-modeのテキストを、Emacsの org-mode を適応して開いていれば、
キーボード・ショートカットで見出しを一瞬でタスクに切り替えることができる。

この機能を最大限利用し、先程まで書いた見出しを全て TODO
にしてしまおう。

もちろんだが、全ての見出しを TODO
にするスクリプトを書いてしまっても良い。
むしろそうやって積極的に拡張できるのがEmacsの強みだと私は思う。

書け。羅列されたシーンを描写しろ。

さあ、何を書きたいか決まった。書こう。

細分化された見出しはほぼ穴埋めだ。

細分化された見出しに答えるように書いていくだけで良いはずだ。

それで筆が進まないのは、もしかしたら細分化が足りない。

どんな風に書くか迷ったら、 #
を行頭につけてコメントアウトしてとりあえず書いてみる。

余談：テストを行うプログラムから書く「テスト駆動開発」

昨今になってソフトウェア開発の世界で注目されているのが、「テスト駆動開発」という手法だ。

雑に説明してしまうと、
「作ったものの動作が正しく動作するか検証するプログラムを書きながらソフトウェアを作っていく」
という手法だ。

この執筆手法も、このソフトウェア開発手法からヒントを得た。
「自分の書きたいことをある程度ハッキリさせたら筆が進むはず」
という、結構安直な考えである。

この際なのでここに、「ドメイン駆動設計」
の考え方も混ぜ込みたくもなったが、まだそこまで考えがまとまってないので、後日うっかりひらめいたら。

見出しを消す

よしっ！

（ヘルメットを被った猫の絵は省略）

あとは大見出し以外を消すなり、大見出しを書き直したら、大分いい感じになってるはずだ。

Orgで書いたテキストを変換。

とはいえ、書いたテキストを他の人が見やすいフォーマットにできないと、
なかなか見せづらくて寂しいと思われる。

EmacsとOrg-mode標準でもいくつかのファイルフォーマットに出力できるが、Pandocなどのツールを使うと、
更に幅が広がる。

LaTeX形式に一度吐き出して、PDF形式に変換することも可能だ。

Git（とMagit）を合わせると鬼に金棒。

GitとMagitを使って共同執筆する方法についても書きたかったが、私個人の時間切れに付き、ここまで。

Gitを使った執筆活動の方法は他の方も各所で書いているので、興味のある方はぜひ調べてみるといいだろう。

まとめ

私の眠気もいい具合にキマってきた午前0時40分。

割と思いついたことは書き留めれたはず。

なお、この記事を書くに当たって、八田真行さんの「モーレツ！ Org
mode教室」を多大に参考にさせていただいた。
ちょっとでもEmacsとOrg-modeに興味を抱いた方は、ぜひ確認していただきたい。

Emacsディストリビューション

しかしながら、この記事の最初でも記したとおり、Emacsは素のままでは結構難解なテキストエディタである。

そこで、そんなEmacsにパッケージを追加して使いやすくしたEmacs達を紹介して話を締めたいと思う。

Graphene: 比較的優しそうな見た目
Emacs Prelude: ディストリビューションでは結構人気
Spacemacs: ちょっと重くて音沙汰ないけど、元祖Emacs + Vim
DOOM Emacs: Spacemacsの意志を受け継いだ？　チョットワカル人向け。とはいえ自分みたいなニワカでも割と扱える。
Emacs: 弘法は筆を選ぶのではない。作るのだ。
Vim-Org-mode: VimでもOrg-mode
VSCode + VS Code Org Mode: Visual Studio CodeでもOrg-mode。すげぇな。

P.S.

このテキストの原稿もOrg-modeで書きました。
GIstに原稿を上げてますRawボタンを見ると、生テキストファイルが見れます。
参考になれば幸いです。

submoduleのざっくりとした流れ

2019-06-06T14:15:54+09:00

2個のリポジトリをまとめて管理したかっただけなので込み入ったことはしていません。

git submodule: 現在のsubmoduleの状態を見る
git submodule add : 追加したいリモートリポジトリを指定

前提

submoduleは予めpushしておくこと

登録

git submodule add でsubmoduleの追加。配下に登録される。

更新

submodule化したプロジェクトでpushしても自動更新されないことに注意。

cd 
git pull origin

git diffで差分が出ていることを確認。

後は普通にadd->push

参考リンク：

https://qiita.com/kinpira/items/3309eb2e5a9a422199e9
https://qiita.com/sotarok/items/0d525e568a6088f6f6bb

ojichatのおじさん文章をコミットメッセージのデフォルトにする

2019-06-05T22:47:35+09:00

こんにちは。ななめ210(@naname210)です。
個人開発で、物書きさん向けライブ配信サービス TxT Live などを作ってます。

最初に

これは、最近Twitterなどで話題になっているおじさん文章ジェネレーターで作られた文章をGitのコミットメッセージにする方法をまとめたものです。

おじさん文章ジェネレーターは、@3qgtさんが作成されて公開しているサービスです。

ヤッホー😃♥ 😘（笑）😃☀ はなチャン、元気かな❗❓🤔⁉そういえば、昨日は例のバー🍷に行ってきたよ。結構いい雰囲気だったから、オススメダヨ(^з<)(^_^)

はなちゃんのお目々、キラキラ😆(^o^)してるね(^з<)こんなに可愛く😃☀ なっちゃったらお姫様みたいで僕困っちゃウヨ(・_・;

のような、おじさん風のクソリプを自動生成してくれるものになります。

おじさん文章を作るプログラムは、@grethlenさんが作成しているojichatが使われています。

なぜ作ったか

理由は、簡単！TwitterのTLでコミットメッセージをおじさん文章にしているのを見たからです！
(これを作って記事にしようと思ったときに再度探してみましたが、見つけられませんでした。。。

先駆者の方のものを見て、
日頃、個人開発をしているけど、共同開発と違いコミットメッセージを書くのがめんどくさくて画像のような「aaaa」「ddddd」などが並んでるなー。

そこで、意味のない文字列が並んでるよりおじさん文章が並んでる方が見ていて楽しくなるなー、できれば自動で挿入されてほしいなーと思ったので作りました！

環境

・git version 2.16.2
・go version go1.12.5 darwin/amd64
・ojichat v0.2.0

作り方

前提として、

$ ojichat

でojichatが使えるようになってるとします。
ojichatのインストール＆使い方はojichatのGitHubをみてください。

Git フック

Git フックを使って作っていきます。
Gitフックについては、参考文献のURLの記事を見てみてください。

まずフックスクリプトを読み込む設定をします。
今回は、個人開発のプロジェクトのみ適用していきたいので対象をローカルにします。

$ cd git_project
$ git config --local init.templatedir '~/.git'

次にフックスクリプトの作成を行います。

$ touch ~/.git/hooks/prepare-commit-msg

#!/bin/sh

if [ "$2" == "" ] ; then
  echo "`ojichat`\n`cat $1`" > $1
fi

最後にhookファイルのパーミッションを変更します。

chmod +x ~/.git/hooks/prepare-commit-msg

これで完成です！

使用すると

画像みたいにデフォルトでおじさん文章が挿入されます！

これでGitログが華やか？に！

問題点

エディタでVScodeを使ってるのですが、VScode内のGit機能には反映されない。
どうにかできないか調査中。

最後に

日頃、「aaaa」「hogehoge」などでコミットメッセージをしている方、華やかになりますよ！
個人開発に華が！おじさんだけど！

いいねやコメントをしてくださると、嬉しいです。よろしくお願いします。

参考文献

Git フックについて、Gitフックの設定の仕方で参考にさせていただきました。
・ https://qiita.com/noraworld/items/c562de68a627ae792c6c
・ https://qiita.com/mkiken/items/b7d4731a31e5559cd090

Git Revert 複数コミットをまとめて取り消すときにコミットメッセージを設定する

2019-05-20T18:32:12+09:00

｢ここからここまでのコミット｣と範囲を指定したrevertをして、いい感じのコミットメッセージを作る方法です。

複数のコミットをrevertしたい場合は、単に複数のコミットを指定するか、オプション--no-commitでrevertコマンドを繰り返した後にrevert --continueして確定します。どちらの場合も、コミットメッセージをコマンドラインで指定することができません。オプション-eはコミットメッセージを編集するためのエディタを開くもので、メッセージをコマンドラインで指定できません。*コマンドリファレンス Git - git-revert Documentation

メッセージを指定するには、オプション--no-commitを実行した後に通常のコマンドgit commitをオプション-mと共に実行します。from: stack overflow

ところで、gitには｢ここからここまでのコミット｣を表す記法があります。例えば、master..HEADの｢..｣みたいなやつ。詳しくはここに書いてあります、Git Book コミットの範囲指定。revertコマンドでは、この記法で複数コミットを指定できます。

以下のコマンドではbashの文字列展開を使って、すべての取り消し対象コミットのメッセージの先頭行を結合したテキストを作ります。

$ ref=[ここまで戻したいコミット、タグ]
$ git revert --no-commit $ref..HEAD
$ git commit -m "Revert to $ref" -m "$(eval "git log --pretty=oneline $ref..HEAD")"

# 確認
$ git diff $ref HEAD

revert --no-commitで、チェリーピッキング
- revert --continueするとメッセージが指定できない
commit -mしてしまえばいい
- -mオプションを複数書いたら改行して追加される
bashで入れ子の文字列展開にはevalを使う
- "$(eval "$var")"

URLパラメータで簡単画像リサイズ。netlify の Large Media が便利！

2019-04-21T22:24:31+09:00

netlify の Large Media とは

Git レポジトリでサイトコンテンツを管理する際に、画像やPSD/ZIPなどの大きいファイルを含めて管理するために Git LFS（Git Large File Strage）と仕組みがある。
LFS については細かく触れないが、LFS を使って netlify にデプロイされた画像を、URLパラメータをつかってリサイズやクロップが便利に扱えるように使える神機能である。

Large Media 公式ドキュメント
https://www.netlify.com/docs/large-media/#enabling-netlify-large-media

Git LFS 公式サイト
https://git-lfs.github.com/

netlify Large Media のサンプル

例えば、普通に gitレポジトリに含めて github などを介して netlify デプロイすると、このようなURLで画像にアクセスできる。

https://netlify-photo-gallery.netlify.com/images/apple.jpg

これにこんな形で、最後に ?nf_resize=fit&w=200 を加えてやると、リサイズされた画像を生成して返してくれるのだ。
https://netlify-photo-gallery.netlify.com/images/apple.jpg?nf_resize=fit&w=200

さらに次は、画像URLにの最後に ?nf_resize=smartcrop&w=200 を加えてやると、クロップされた画像を生成して返してくれる。

１つ画像をアップするだけでいい感じにリサイズされた画像やクロップされたをすぐに使えるのだ！神すぎないか？

これが netlify Large Media 機能だ。

公式サンプルに Transformation demo とジェネレーターがあるので、もう少し触ってみたいかたはこちら。
https://netlify-photo-gallery.netlify.com

netlify Large Media の使い方

環境準備

最初に一度ローカル環境を準備する必要がある。

バージョン確認

git lfs version
Git LFS version: v2.5.1以上　を確認
なければ、Git LFS をインストール。詳細は公式サイトで割愛
https://git-lfs.github.com/

netlify -v
netlify-cli: 2.6.4以上を確認

なければ、netlify-cli をインストール。詳細は公式ドキュメントで割愛
https://www.netlify.com/docs/cli/

large media プラグインインストール

バージョン確認後、netlify-cliのプラグインをインストール

netlify plugins:install netlify-lm-plugin
netlify lm:install

これで環境準備は完了

サイト（レポジトリ）ごとの設定

Large Media 機能を使うには、サイトごとに機能を ON にしないといけないので、サイトごとで設定。
1. まずは、netlifyでプロジェクトを作成と github レポジトリが紐付いていることを確認
2. その後、ローカルのレポジトリも紐付ける

netlify link

3.セットアップコマンドをつ

netlify lm:setup

4.セットアップコマンドをつ
git status で、.lfsconfig が生成されていることを確認し、git add で.lfsconfigを git の管理下におく。

LFS で管理する

サイトごとの設定の他に、LFS でファイルを管理する必要があるので、

画像ごとでトラッキングしていくか、gitignore の pattern rules も使えるので、LFSで管理するように指定していく。

git lfs track "sample.jpeg"
git lfs track "*.jpeg"

トラッキングされたファイル一覧はこちらで確認可能。

git lfs track

トラッキング時には .gitattributes が生成されるので、こちらも git add と commit して管理する。

詳しくは netlify のドキュメント、または、Git LFS 公式サイトで。
https://www.netlify.com/docs/large-media/#large-media-file-tracking-configuration

確認

うまくnetlify large media の設定と LFS で設定できていれば、あとはいつもどおりレポジトリに push をするだけで、large media 機能がつかえるようになる。

https://lfs-test.netlify.com/sample.jpeg?nf_resize=smartcrop&w=100&h=200

最初のサンプルのようにパラメーターをつけるだけで、Large Media が使えるようになっている！

正常に動いていれば、netlify 管理画面もこんな感じに、ドキュメントのリンクの画面から管理している画像の一覧に変わります。

公式のサンプルもあるけど、自分でためしたサンプルも一応
https://github.com/yahsan2/lfs-test

netlify Large Media と CMS

この netlify large media 機能は、 netlify CMS をつかって画像をアップロードする lfs として画像をコミットしてくれるので、この機能を簡単につかえるので、netlifyCMS もおすすめですね。つまり画像リサイズをもった JAMstack な CMS も簡単につくれるわけです。
https://www.netlifycms.org/docs/netlify-large-media/

なんか静的サイトホスティングサービスでシンプルなのに、このかゆいところにどんどん手が届いてく netlify 拡張具合ほんとファンです。

一人プルリクエストのすゝめ

2018-09-25T22:40:57+09:00

プルリクエストといえばGitHub等で業務の際やOSSに貢献する際などに利用する、自分の対応したブランチを取り込んでもらうための仕組みですが、何気に一人で使うのにもメリットがあったりします。どういったメリットがあるのか紹介します。

とりあえずGitHubでプルリクエストを作成してみる

何にしろまずプルリクエストをGitHub上で作成してみます。ちなみにGitHubだけでなく、BitBucketやGitLab等でも同様のことは可能です。

ブランチを作成

まずはブランチを作成します。エディタやGitクライアントの機能でも良いですし、コマンドラインで作成する場合は下記のように実行します。

git branch prtest

これで現在のブランチを基底にしたprtestというブランチが作成されます。作業ブランチをこのprtestに切り替えておきます。

git checkout prtest

ブランチにコミットする

適当に何かのファイルを編集し、コミットします。今回はREADME.mdを更新しました。

git add README.md
git commit -m "Update README"

GitHubにpushする

pushしてGitHubのリポジトリを更新します。

git push origin prtest

すると、この時点でGitHubのリポジトリを見てみると下記の画像の様に黄色背景のところのような感じで、最近pushしたブランチが表示されています。このようにして簡単にプルリクエストを作成できるようになっています。ここの「Compare & pull request」ボタンを押してプルリクエストの作成画面へ移動しましょう。（プルリクエスト一覧ページからでも作成できます）

プルリクエストを作成する

ボタンを押すと下記のような画面が表示されます。

色々と入力欄がありますが、一人でやっている場合はとりあえずわかりやすい件名を入れておけば十分でしょう。あとは整理したければ気分で色々と入力しておいてください。必要な箇所を入力したら「Create pull request」を実行します。

プルリクエスト詳細画面

作成すると、下記のようなプルリクエストの詳細画面にアクセスすることができるようになります。

この画面では、先程追加したコミットが表示されています。今後このブランチにコミットを行うと、ここに列挙されます。そのため、このブランチで何をやっているかというのが非常にわかりやすくなります。

コミットの粒度

Gitについて調べた方の中には、「コミットの粒度」がどうとか、というのを見たことがある人もいるのではないかと思います。このプルリクエスト画面を見ると、どういったコミットが積まれているかをわかりやすく見ることができますので、なんとなくいい感じに並べてみたい気分になったりしませんか？

一人でやっている場合は恐らくセーブ感覚で適当なところで「ひとまずセーブ」みたいな感じでコミットしている場合も多いかもしれませんが、せっかくなので各コミットで何をやっているかをわかりやすく書いてコミットしてきましょう。「投稿機能を追加」とか、「トップページのデザインを変更」のような感じです。OSSにも貢献してみたい場合などは英語で練習しておいても良いと思います。

File Changed

File Changed画面も非常に有用です。開いてみると下記のような画面が表示されます。

このように、このプルリクエストの差分を見やすく表示してくれます。今まではコンソール上でgit diff等で差分を確認していた方もいると思いますが、このようにGitHub上で確認ができると便利です。マージ前に自分でざっとセルフレビューして変なデバッグ処理が混じってしまっていたりしないかなどを見ることができますし、このプルリクエストはマージしてプルリクエストがクローズされた後も閲覧できますので、「あの時のプルリクエストって何を変更してたっけな～」という場合にもブラウザだけで非常に簡単に確認しやすいです。

ただ、ここもファイル数や行数がとんでもない量になるとカクカクになってしまいますので、プルリクエスト自体もなるべく必要最低限の粒度に調整することが、綺麗なプルリクエストの運用の仕方になります。

Git log --graph を美しくする

2018-09-10T17:12:08+09:00