- 投稿日:2019-11-30T16:29:40+09:00
gitのカスタムコマンドで自動バージョン更新&タグ付けする
開発しているコードをリリースするときにバージョンを更新するのは地味に面倒です。
- semver に則って新バージョンを決める or カスタムで決める
- package.json 等の管理情報のバージョンを書き換えて commit する
- 最終的に
git tag
でバージョンのタグ付けを行うリリースのたびにこのような定型的な作業を行うのは大変なのと、人力でやることでミスを誘発する可能性も高くなるので、これらの一連の作業を自動で行うカスタムコマンド
git-release
を作って安全・安心なタグ付けをしましょう。できること
Usage: git release [-p] [<newversion> | major | minor | patch]
git release NEWVERSION
で、指定したバージョンのタグを付与します。
package.json or build.sbt がある場合には、ファイル内のバージョン情報を上書きして commit します。package.json or build.sbt で semver を利用している場合、以下のような自動 semver 更新が利用可能です。
git release patch
で 1.1.1 -> 1.1.2 のように patch 部分がインクリメントされます。
git release minor
で 1.1.1 -> 1.2.0 のように minor 部分がインクリメントされます。
git release major
で 1.1.1 -> 2.0.0 のように major 部分がインクリメントされます。
git release -p patch
のように-p
をつけると、origin に自動で push されます。動作条件
- git-flow(gitflow-avh 等)を導入済みであること
- Mac であれば
brew install git-flow-avh
で OK- git リポジトリが
git flow init
されていることリリース時のタグ付けを
git flow release
で行っているだけなので、その他のブランチ運用を行っている場合は適宜個々人で改修してください。設置方法
以下の bash script を
chmod 755
した上でパスの通っているところに設置するだけです。
/usr/local/bin
等に設置しても良いですが、~/bin
等 $HOME 以下に閉じたほうが良さげ。git-release#!/bin/bash set -e usage() { echo "Usage: git release [-p] [<newversion> | major | minor | patch]" >&2 exit 1 } getVersion() { local file=$1 case $file in package.json) echo $(grep '"version":' $file | cut -d'"' -f4) ;; build.sbt) echo $(grep 'version\s*:=' $file | cut -d'"' -f2) ;; esac } setVersion() { local file=$1 local version=$2 case $file in package.json) sed -i '' -e '/"version"/s/"[^"]*",$/"'$version'",/' $file ;; build.sbt) sed -i '' -e '/^version :=/s/"[^"]*"$/"'$version'"/' $file ;; esac } incSemver() { local version=$1 local type=$2 local semver=($(echo $version | tr '.' ' ')) if [ ${#semver[@]} -ne 3 ]; then echo "$version is not semver." >&2 exit fi case $type in major) semver[0]=$(expr ${semver[0]} + 1) semver[1]=0 semver[2]=0 ;; minor) semver[1]=$(expr ${semver[1]} + 1) semver[2]=0 ;; patch) semver[2]=$(expr ${semver[2]} + 1) ;; esac echo $(echo ${semver[@]} | tr ' ' '.') } while getopts hp OPT do case $OPT in p) USEPUSH=1 ;; h) usage ;; *) usage ;; esac done shift $((OPTIND - 1)) if [ $# -eq 0 ]; then echo "VERSION required." >&2 usage fi VERSION=$1 for VERFILE in package.json build.sbt ""; do [ -f $VERFILE ] && break done case $VERSION in major|minor|patch) if [ -z $VERFILE ]; then echo "package.json or build.sbt not found." >&2 exit 1 fi VERSION=$(incSemver $(getVersion $VERFILE) $VERSION) ;; esac git flow release start $VERSION > /dev/null if [ -n "$VERFILE" ]; then setVersion $VERFILE $VERSION git add $VERFILE git ci -m "bump version to $VERSION" > /dev/null fi GIT_MERGE_AUTOEDIT=no git flow release finish -m release $VERSION > /dev/null if [ -n "$USEPUSH" ]; then git push origin $VERSION git push origin master git push origin develop fi echo "$VERSION released!"最後に
類似のものは他にもありますが、こういった類のものは行いたい処理が環境によって異なるのと、1スクリプト=導入がシンプル&カスタマイズ性が高いので、この程度であれば自作のほうが使い勝手が良いと思います。
github 上には git-semver のようなツールもありますので、より高度なことを行いたい場合には検討してみても良いでしょう。
- 投稿日:2019-11-30T15:45:52+09:00
Docker - How to Get Private Git Repository Inner Golang Container?
This method didn't need to generate ssh key.
FROM golang:1.13.4-alpine ... ... ... ARG GIT_URL ARG GIT_GROUP ARG GIT_ACCOUNT ARG GIT_PASSWORD RUN apk update -qq && apk --no-cache add git RUN printf "machine ${GIT_URL}\n\ login ${GIT_ACCOUNT}\n\ password ${GIT_PASSWORD}\n"\ >> /root/.netrc RUN chmod 600 /root/.netrc RUN go env -w GOPRIVATE=${GIT_URL}/${GIT_GROUP} ... ... ...https://medium.com/@jwenz723/fetching-private-go-modules-during-docker-build-5b76aa690280
- 投稿日:2019-11-30T15:45:52+09:00
Docker - How to Get Private Git Repository Inner Golang Container via HTTP?
You may be put your golang modules in a self-hosting git repository which likes gitlab. The most ways to tell us using ssh method and it is not easy enough (need to generate ssh key). I am just want to use https to get golang modules.
FROM golang:1.13.4-alpine ... ... ... ARG GIT_URL ARG GIT_GROUP ARG GIT_ACCOUNT ARG GIT_PASSWORD RUN apk update -qq && apk --no-cache add git RUN printf "machine ${GIT_URL}\n\ login ${GIT_ACCOUNT}\n\ password ${GIT_PASSWORD}\n"\ >> /root/.netrc RUN chmod 600 /root/.netrc RUN go env -w GOPRIVATE=${GIT_URL}/${GIT_GROUP} ... ... ...https://medium.com/@jwenz723/fetching-private-go-modules-during-docker-build-5b76aa690280
- 投稿日:2019-11-30T15:35:05+09:00
Githubでプルリク出すまでの流れ
はじめに
Github等のバージョン管理を利用して開発を行う際に、コードを修正して、プルリクを投げて・・・みたいな一連の流れがあると思いますが、一般的な流れと、それに用いるコマンド等を備忘録的にあげておきます。
開発の流れ
僕が関わってきた開発だと以下のような流れが多かったです。もちろん、現場やプロダクトのやり方によって色々あるので、一つの例として見ていただければと思います。
- issueの作成
- issueへのアサイン
- ブランチの作成
- ブランチのpush
- プリルクの作成
issueの作成
プロダクトオーナーなどが、新しい機能やバグ等々についてissueを作成します。
issueへのアサイン
プロダクトオーナーなどが、実装を担当するエンジニアをアサインします。
ブランチの作成
エンジニアが自分の開発ブランチを作成します。例えば、developブランチから作成する場合
git checkout develop git pull origin develop git branch feature/image-crawler git checkout feature/image-crawler修正のコミット
大きな修正であれば毎日、キリのいい部分まで開発が終わったら都度など、よきタイミングでコミットを行います。
git add xxxxxx.js git commit -m "crawlerベース処理の作成"コミットをまとめる
実装が完了したら、今までのコミットをまとめます。たくさんのコミットがあるとレビュワーが見辛くなる可能性があるからです。
まずは、
git log
してまとめるコミットを確認します。git log commit 07a7c37f5b961275241d5e172f5e54af5a67155a Author: xxxxxxxxxxxxxxx <xxxxxxxxxxxxxxx> Date: Wed Nov 27 20:54:52 2019 +0900 〇〇機能の修正 commit 6435a8ac27c90b7689483b625388adf952b60276 Author: xxxxxxxxxxxxxxx <xxxxxxxxxxxxxxx> Date: Wed Nov 27 17:39:50 2019 +0900 〇〇機能の修正 commit 8b75ffa1b1a458d73168bbeb664139042f799102 Author: xxxxxxxxxxxxxxx <xxxxxxxxxxxxxxx> Date: Tue Nov 26 18:38:39 2019 +0900 〇〇機能のバグフィックス commit c204d9006a14b58e44a119ddeadd7a97704405c1 (HEAD -> develop, origin/develop, origin/HEAD) Author: xxxxxxxxxxxxxxx <xxxxxxxxxxxxxxx> Date: Tue Nov 26 17:34:23 2019 +0900 〇〇機能の修正この場合は、
c204d9006a14b58e44a119ddeadd7a97704405c1
以降のコミットをまとめたいので、以下のような感じでまとめます。git rebase -i c204d9006a14b58e44a119ddeadd7a97704405c1
rebaseすると、以下のような感じでコミットをどうするか表示されます。
pick a1095a7 リファクタ pick c5f8c89 テスト追加 pick 8b75ffa リファクタ pick 6435a8a 取得画像の処理実装 pick 07a7c37 crawlerベース処理の作成 ・・・なので、だいたい、一番上のコミット以外を
s
に変更してまとめます。pick a1095a7 リファクタ s c5f8c89 テスト追加 s 8b75ffa リファクタ s 6435a8a 取得画像の処理実装 s 07a7c37 crawlerベース処理の作成 ・・・で、保存する。
次にコミットメッセージを編集する画面になるので、そこでコミットメッセージをまとめます。
これで準備完了です。大元のブランチに更新があった場合
develop
からブランチを切って開発をしていると、自分が開発しているうちに、develop
が更新されているなんてことはよくあると思います。その場合は、大元のブランチを
rebase
すると最新のコミットを反映させることができます。git checkout feature/image-crawler git rebase developもちろん、コンフリクトがでること必須なので、そこは修正してマージしましょう。
ブランチのpush
origin上にブランチをpushします。
git push origin feature/image-crawlerプルリクの作成
最後にGithubの画面からプルリクを作成します。
この時に
関連issue #123
のように#+issue_id
を記述してあげると、プルリクとissueの関連がわかるので、レビュワーも見やすくなり、おすすめです。以上で1つの開発が完了する感じです。
最後に
今回紹介したのはあくまでの一つの例なので、実際にはコミットのルールやメッセージの書き方など、プロジェクトで決まっていることが多いです。後は、もっとお作法がいいgitのコマンドとかを利用した方がいいこともあるので、それに関しても時と場合によって合わせるのがいいです。
- 投稿日:2019-11-30T11:44:50+09:00
git pull したら permission deniedになったから、その解決法をメモ
開発環境用のサーバーで、git pull したら、
permission denied でエラーになった。まさしくこのような感じのエラー
$ git pull error: cannot open ファイル名: Permission deniedエラーの原因としては、自分が使用しているユーザーはそのディレクトリを変更する権限を持っていないからが理由のよう。
試しにファイルの権限を確認
$ ll -rw-r--r-- 1 hoge hoge 5742 10 26 2018 test1.php -rw-r--r--@ 1 fuga hoge 6807 10 12 2018 test2.php -rw-r--r-- 1 hoge hoge 65 10 11 2018 a1.php -rw-r--r-- 1 fuga hoge 65 10 11 2018 a2.php本来であれば、hogeユーザーで作業する決まりだが、
fugaユーザーで作業した人がいたみたい。。なら、ファイルの権限を変更すればOKと思いきや、
修正するファイルは、プロジェクトのいたるところにあり、
おまけに.git配下も修正しなくてはいけず、いちいち該当するファイルのパスを指定して権限を変更していたら日が暮れるという感じ。。まとめてファイルの権限を変更
ということで、便利なlinuxコマンドもメモしておく
ルートディレクトリで作業
//ファイル find ./ -user fuga -type f -print | sudo xargs chown hoge:hoge // ディレクトリ find ./ -user fuga -type d -print | sudo xargs chown hoge:hoge //シンボリックリンク find ./ -user fuga -type l -print | sudo xargs chown hoge:hoge
これでまとめて権限を変更することが可能。
実行する流れとしては、
find ./ -user fuga -type f -printで該当するファイル一覧を確認し
find ./ -user fuga -type f -print | sudo xargs chown hoge:hogeで権限をまとめて変更
find ./ -user fuga -type f -print再び、こちらを実行し、ファイルが表示されないことを確認って感じ。
こういうコマンドをすらすら思いつけるようになりたい。
- 投稿日:2019-11-30T10:58:13+09:00
Gitで過去から現在までのAuthorをすべて変更する
状況
Githubにリポジトリを公開するにあたって、これまで
~/.git.config
で指定していたuser.name
とuser.email
が使えなくなりました。
今後はプロジェクト内に.git.config
を作成することで対応できますが、これまでのコミットのAuthorとCommitterをすべて書き換える必要が出てきました。
filger-branch
コマンドで一括変更する以下のコマンドで過去のコミットのAuthorとCommiter情報を書き換えます。
注意:
filter-branch
は過去のコミットを書き換えてしまうので、作業前にリポジトリのバックアップをとっておくことを推奨します!$ git filter-branch --env-filter "GIT_AUTHOR_NAME='NewAuthor';GIT_COMMITTER_NAME='NewCommitter';GIT_AUTHOR_EMAIL='newauthor@example.com';GIT_COMMITTER_EMAIL='newcommitter@example.com'" -- --all
git log --pretty=fuller
で確認します。$ git log --pretty=fuller commit e8c720d29450ba08fe686220dbcee09363911e5f (HEAD -> master) Author: NewAuthor <newauthor28@example.com> AuthorDate: Wed Nov 13 10:49:13 2019 +0900 Commit: NewCommitter <newcommitter@example.com> CommitDate: Fri Nov 29 10:43:04 2019 +0900 (省略)これで完了です。お疲れ様でした。
補足: AuthorとCommitterの違いについて
今回
git filter-branch
コマンドについて調べているときに気になったのが、AuthorとComitterの違いです。
stackoverflowの回答によると
- Author: オリジナルのコードを書いた人
- Committer: Authorの作業を適用(コミット)した人
とのことです。