20191130のGitに関する記事は6件です。

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 のようなツールもありますので、より高度なことを行いたい場合には検討してみても良いでしょう。

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

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

https://blog.csdn.net/du_chao_qun/article/details/53464454

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

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

https://blog.csdn.net/du_chao_qun/article/details/53464454

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

Githubでプルリク出すまでの流れ

はじめに

Github等のバージョン管理を利用して開発を行う際に、コードを修正して、プルリクを投げて・・・みたいな一連の流れがあると思いますが、一般的な流れと、それに用いるコマンド等を備忘録的にあげておきます。

開発の流れ

僕が関わってきた開発だと以下のような流れが多かったです。もちろん、現場やプロダクトのやり方によって色々あるので、一つの例として見ていただければと思います。

  • issueの作成
  • issueへのアサイン
  • ブランチの作成
  • ブランチのpush
  • プリルクの作成

issueの作成

プロダクトオーナーなどが、新しい機能やバグ等々についてissueを作成します。

スクリーンショット 2019-11-28 16.14.47.png

issueへのアサイン

プロダクトオーナーなどが、実装を担当するエンジニアをアサインします。

スクリーンショット 2019-11-28 16.14.56.png

ブランチの作成

エンジニアが自分の開発ブランチを作成します。例えば、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の画面からプルリクを作成します。

スクリーンショット 2019-11-30 15.33.13.png

この時に 関連issue #123 のように#+issue_idを記述してあげると、プルリクとissueの関連がわかるので、レビュワーも見やすくなり、おすすめです。

以上で1つの開発が完了する感じです。

最後に

今回紹介したのはあくまでの一つの例なので、実際にはコミットのルールやメッセージの書き方など、プロジェクトで決まっていることが多いです。後は、もっとお作法がいいgitのコマンドとかを利用した方がいいこともあるので、それに関しても時と場合によって合わせるのがいいです。

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

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

再び、こちらを実行し、ファイルが表示されないことを確認って感じ。

こういうコマンドをすらすら思いつけるようになりたい。

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

Gitで過去から現在までのAuthorをすべて変更する

状況

Githubにリポジトリを公開するにあたって、これまで~/.git.configで指定していたuser.nameuser.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の作業を適用(コミット)した人

とのことです。

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