commitメッセージの先頭に#Issue番号を手動でつけてcommitしています。
手動のため、チーム内でつけ忘れるメンバーが出てきたため、自動で追加できないか調べたところ、prepare-commit-msgなるものが。
featureブランチの名前で先頭をIssue番号にするルールがあるため、それを利用して、ブランチ名からIssue番号を取り出し、commitメッセージ自動追加するようにしました。

$ cd <リポジトリパス>
$ mkdir .githooks
$ touch .githooks/prepare-commit-msg
$ git config core.hooksPath .githooks
$ chmod +x .githooks/prepare-commit-msg

.git/hooks内のファイルを利用することもできますが、チームで開発している場合は設定を共有するため、リポジトリへ含められるようにフォルダを作成します。
.githooks/prepare-commit-msgを編集します。

#!/usr/bin/env ruby

current_branch = `git branch | grep '*'`.chomp.sub('* ', '')
if /(feature|hotfix)\/(\d+)-/ =~ current_branch
  issue_no = $2
  commit_msgs = File.readlines(ARGV[0], encoding: 'UTF-8')
  exit if commit_msgs[0] =~ /^##{issue_no}\s/
  open(ARGV[0], 'w') {|file|
    file.print "##{issue_no} "
    file.puts commit_msgs
  }
end

SourceTreeやForkからcommitしたとき、ASCIIがうんたらと怒られてしまい、コミットに失敗しましたが、encodingを明示的に指定することで解決しました。

commit_msgs = File.readlines(ARGV[0], encoding: 'UTF-8')

Flaskのアプリをherokuとgithubを使ってデプロイしてみます。
メモのために書きます。と思ってやってたんですが、デプロイしたページを見ようとするとエラーが出てします。前はできたんだけど、、、

まずプログラムを入れるファイルを作ります。

(base) PS C:\working\web_app> python -m venv 新しく作るファイル名(今回はmessage_app)

仮想環境を設定する。
下のコマンドを打つと仮想環境が稼働します。

(base) PS C:\working\web_app\message_app>Scripts\activate

次にライブラリを仮想環境にインストールします。

(message_app) PS C:\working\web_app\message_app>pip install 使うライブラリ名（今回はflaskとrequestとgunicorn)

pip install -r requirements.txt(requirements.txtを使ってインストールもできる）

Procfileという名前のファイルを作るってエディタでファイルに以下の文を書いておく

web: gunicorn app:app --log-file=-

requirements.txtを作って中にしたのコマンドで出てきたインストールされてるライブラリの情報をコピペする

pip freeze

以下のコマンドを実行する

git init

git add .

addと.の間に半角スペースがあるのに注意

git commit -m “コメント”

heroku login

heroku create

git push heroku master

ってやってみたけど、できなかった　＞＜

はじめに

gitで、リモートをローカルにpullしたらコンフリクトした。
でもローカルのソースは保存する必要はなくて、とにかくリモートがローカルに来ればいいんだ！！強制的にpullしたい！！

ってことがままあります。
いっつもコマンド忘れちゃってググる行為から始まるのでここにメモします。

コマンド

リモートの「develop」のソースをローカルの「mylocal」にpullしたいとき

$ git fetch origin develop
$ git reset --hard origin/mylocal

これでいけました〜。
gitのコマンドとかそもそものところが、未だに理解で来ていない部分もあり
やりながら勉強中です・・・・。なかなか難しい・・・・。

オレオレzshエイリアスを晒す【効率化の第一歩】

以前、村上さん(@ryuta69 )の以下記事を読んで、速攻で導入したエイリアス一覧を晒します。
【私的最強alias32選】忘れやすいコマンドは、『辞書化＆ショートカット化』しちゃえばいい

zshエイリアスについて

zshはgitなどのエイリアスがデフォルトで登録されています。
とはいえ、一連のコマンドを組み合わせた関数も欲しい。

なので~/.zshrcをいじってオレオレエイリアスを設定しました。

zshエイリアス設定方法

bashとは文法がちょっと異なります。
例えば、エイリアス名とコマンドをつなぐイコールの間に、半角スペースが入ってはいけない、とか。

単純なエイリアスの設定例は以下。

~/.zshrc

alias gitls="alias | grep git"

詳細は時間があるときに追記しようと思います。

オレオレzshエイリアス公開

以下、オレオレエイリアスです。
メインは現在業務でよく使う以下の3種類
- Firebase
- npm
- git

~/.zshrc

# zsh aliases
alias vz="vim ~/.zshrc"
alias sz="source ~/.zshrc"
alias rmf="rm -rf"

# Firebase aliases
alias fl="firebase login"
alias fi="firebase init"
alias fs="sudo firebase serve"
alias fd="firebase deploy"
alias fdf="firebase deploy --only functions"

# npm commands
alias nig="npm install -g"
alias nis="npm install --save"
alias nui="npm uninstall"
alias nuis="npm uninstall --save"
alias nls="npm ls"
alias niy="npm init -y"
alias nid="npm install --save-dev"
nvv() { npm view $1 version }

# Show all git alias commands
alias gitls="alias | grep git"
alias gc="git checkout"
alias gcd="git checkout develop"
alias gpd="git push origin develop"
alias gpm="git push origin master"
alias grm="git rm --cached"
alias gdn="git diff --name-only"
alias grh="git reset --hard HEAD^"

gmpd () {
    git pull origin develop
    echo "Type branche name to merge : " && read branch;
    git merge ${branch};
    git status;
    echo "Is it okay to continue?" && read;
    git push origin develop
}

# Push all changes to current branch
gcom () {
    git add . && git status
    echo "Type commit comment" && read comment;
    git commit -m ${comment} && git push origin HEAD
}

mygcre () {
    git init && git add . && git status && git commit -m "First commit"
    echo "Type repository name: " && read name;
    echo "Type repository description: " && read description;
    curl -u YOURID:YOURPASSWORD https://api.github.com/user/repos -d '{"name":"'"${name}"'","description":"'"${description}"'","private":true}'
    git remote add origin https://github.com/deatiger/${name}.git
    git checkout -b develop;
    git push -u origin develop;
}

容量が大きいリポジトリをサブモジュールに登録していると、サブモジュールの更新には結構な時間が掛かります。

なぜ時間がかかるかと言うと git submodule update --remote をすると新しい内容のダウンロードが発生するためです。小さいリポジトリであれば何も問題ありませんが、巨大なリポジトリになると無視できない時間が掛かりますし、ディスク容量も消費します。（私の見たことあるプロジェクトでは一回の更新に10分以上かかってました?）

このダウンロードを避け、手早くサブモジュールのバージョンだけを更新したいという話です。

尚、今回の方法は事前に更新後の Commit ID (ハッシュ値) を知っている必要があります。（事前に更新後の Commit ID が分かっている状況であればダウンロードを省略して更新できるよ！という趣旨です。）

サブモジュールのダウンロードを省略した更新コマンド

先に結論を書くと、git submodule update の代わりに git update-index コマンドを使うと参照するコミットを強制的に書き換えられます。このコマンドは一瞬で終わります。（ここで指定する Commit ID は外部リポジトリのものです。）

$ git update-index --cacheinfo "160000" "更新後のCommitID" "サブディレクトリのパス"

実際にプッシュまで行うときの流れは以下のようになるでしょう。

$ git update-index --cacheinfo "160000" "d732318e5286f6e06beb5d1c958a9ecaee4fe1b5" "vendor/laradock"
$ git commit -m "Update submodule"
$ git push origin

これでなぜ更新できるのか、仕組みを知りたい人は以下も読んでみてください。

そもそも Git submodule とはどんな仕組み？

git submodule は、他のリポジトリの内容を、自分のリポジトリにサブモジュール（サブディレクトリ）として登録し、参照するための仕組みです。基本的な仕組みについては Git submodule の基礎 などが参考になると思います。

今回の話で重要になるのが、サブモジュールを登録する側の参照元リポジトリでは、外部リポジトリの特定コミットへの参照だけを登録する という点です。参照先にあるファイルの実体については登録しません。

たとえ巨大なリポジトリをサブモジュールとして登録したとしても Git のデータベース容量はほとんど増えません。参照先の実体の内容を git submodule update --init などでダウンロードするときに初めてローカルのディスク容量を消費します。

Git のデータベースにはどのように登録される？

Git のデータベースに参照だけが登録されることを実際に確認してみます。

# テスト用の参照元リポジトリを適当に作る
$ mkdir parent-repo
$ cd parent-repo
$ git init

# 外部リポジトリをサブモジュールとして追加する
$ git submodule add https://github.com/laradock/laradock vendor/laradock
Cloning into '/tmp/parent-repo/vendor/laradock'...
Resolving deltas: 100% (5379/5379), done.

# 追加後に Git にステージされているファイルの一覧を出力する
$ git ls-files --stage
100644 c0d8e4208598468cf860099446f32ba7127b6759 0 .gitmodules
160000 8203e5da2992db2e242a6dd9733f12f5c664842e 0 vendor/laradock

上記の結果から git submodule add により2つのファイルが Git に追加されたことが分かります。サブモジュールの一覧を持つメタファイル .gitmodules と、サブモジュールの vendor/laradock です。

ここで注目すべきは出力された1列目の数列です。この数字はモードビットと呼ばれ、ビット列の前半部分がファイル種別を、後半部分がパーミッションを表します。

主なモードビットの一覧:

• 100644 (1000000110100100): 実行不可能な通常ファイル
• 100755 (1000000111101101): 実行可能な通常ファイル
• 040000 (0100000000000000): ディレクトリ
• 120000 (1010000000000000): Symbolic link
• 160000 (1110000000000000): Gitlink (Submodule)

これと照らし合わせると、先ほどの .gitmodules の 100644 は「実行不可能な通常ファイル」として登録されていることが分かります。一方で vendor/laradock は「Gitlink」として、つまり 外部リポジトリの特定コミットへの参照として登録されています。

実際に参照している外部リポジトリの Commit ID は以下のコマンドで確認できます。

$ git submodule status
8203e5da2992db2e242a6dd9733f12f5c664842e vendor/laradock (v9.3-22-g8203e5d)

Git submodule の参照先を更新するには？

サブモジュールのリモート上の変更を取り込みたい場合は通常 git submodule update --remote のコマンドを実行します。このコマンドはサブモジュールのサブディレクトリ上で git fetch してから git merge origin/master を行うのと同じことです。このときの git fetch で実体のダウンロードが発生するということです。

このダウンロードを回避し Git データベース上の参照ポインターだけを書き換えるコマンドが、冒頭に書いた git update-index になります。

$ git update-index --cacheinfo "160000" "d732318e5286f6e06beb5d1c958a9ecaee4fe1b5" "vendor/laradock"

ここで引数に 160000 という見覚えのある数字が出てきました。これは先ほどのモードビットの Gitlink を意味します。そして次の引数で Gitlink の参照先の Commit ID を指定します。

Commit ID には実際に存在しないものも指定できてしまうので、間違えないように注意が必要です。

参考

• Git - git-submodule Documentation
• Git - git-update-index Documentation
• git - How can I set a submodule to point to a specific commit without fetching it? - Stack Overflow