atton.blog: git

ラベル git の投稿を表示しています。すべての投稿を表示

2020/07/19

GitHub へ push した際に Docker Hub で docker image を自動 build する

過去に「GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した」という記事を書きました。

前回は image の build を GitHub で行なっていましたが、今回は Docker Hub で build するように変更したお話です。

Docker Hub で docker image を build する

GitHub と連携した automated build という機能を利用しました(設定方法はドキュメント参照)。

前回同様、GitHub に push すると自動的に Docker Hub に image が更新されます。

これまた前回同様、以降は作業ログ等です。

何故構成を変更したのか

image を更新する為に Docker Hub を触っていた時、 GitHub 連携の存在に気付いた為です。

ちなみに、更新していた image は latex-make というもので、MacTeX をインストールせずに LaTeX を実行できる image です。

更新内容は TeX Live 2019 から TeX Live 2020 へのアップデートでした。

GitHub Actions 作成時に気にしていた3つの条件のゆくえ

過去の記事では以下の3つの条件を気にしていました。

Dockerfile が増えた場合も自動で対応する
Dockerfile や関連ファイルに更新が無い Image は Push しない
GitHub Actions だけでなく、ローカルの環境でも build できる

第1条件と第2条件は、 Repository を分割して解決としました(latex-make, webpage-title)。

第3条件はビルドスクリプトをローカルマシンに残す事で解決としました。

構成を変更して良かった点

他の image の README を参考にした結果、 README が整備された

latex-make には使用例が無かったので追記した
shields.io を利用して image のサイズ等のバッジを追加
GitHub/Docker Hub の README を(手動で)統一

Docker Hub に automated build のログが残るようになった

前回は「push したユーザは atton, push 時刻」程度の情報しか無かった

ログイン情報を書くが必要無い

連携時に Docker Hub から GitHub へ権限を要求しているので docker login を実行する必要は無い
具体的に言うと GitHub Actions ではログインパスワードを Secrets に書いていた

なので、Docker Hub のログインパスワードを変更後、Secrets を更新しないと docker login に失敗する

構成を変更して良くなかった点

移行作業が手作業だった

対象となる docker image が2つのみだったので、手作業で移行を行なった
仮に docker image が多かった場合、移行スクリプト等を書く必要があったかもしれない

第2条件が若干緩くなった

master が更新された際に build が行なわれるので、 README だけの変更 commit でも build が発生する
git の tag をトリガーにして build する、等の設定で修正可能
しかし現状の image の tag は latest しか無いので放置中

2020/06/09

GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した

私は作成した Dockerfile を GitHub で公開しています(前回の記事の atton/webpage-title も含む)。
Docker Image を手動で管理するのは面倒なので、何らかの形で自動化する事にしました。
最終的に、 Dockerfile が更新された際に build して DockerHub に push する GitHub Actions を作成しました。

GitHub Actions を作成する際に考慮した条件

Dockerfile が増えた場合も自動で対応する(現時点では2つ)
Dockerfile や関連ファイルに更新が無い Image は Push しない
GitHub Actions だけでなく、ローカルの環境でも build できる

具体的な GitHub Actions の内容

作成した .github/workflows/build-and-push.yml とbuild.sh は以下です(commit: 427f143)。

自動化できたので手動 push の必要は無くなりました。べんり。

これ以降は作業ログなどを書いておきますが、かなり長いです。

第一条件: Dockerfile が増えた場合も自動で対応する

この条件については、特定の構成をしているディレクトリを build 対象にする事で対応しました。具体的には

ディレクトリ名は任意

ls と [ -d ] で確認

ディレクトリの直下に Dockerfile が存在する

ls と [ -f ] で確認

といったディレクトリです。なお、ディレクトリ名は Docker Image の tag を決める際に使っています。

第二条件: Dockerfile や関連ファイルに更新が無い Image は Push しない

Docker Image を自動 build する際、最初は elgohr/Publish-Docker-Github-Action@master を使っていました。

ここで問題が発生。README.md を変更しただけの commit でも Docker Image の更新が行なわれました。

幸い、GitHub Actions の step では if が使えるようなので試してみましたが改善せず。

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

なので elgohr/Publish-Docker-Github-Action@master は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると

$ git diff-tree --no-commit-id --name-only -r ${{ github.sha }}

で確認できるとの事。ではこれを grep して exit code で判定すれば解決、しませんでした。

更新の有無に関わらず、全ての grep の exit code が 1 になっていました。
加えて、ローカル環境では想定通りの exit code が得られるので、どうやら原因は実行環境固有のようです。

「ローカルでは動くが、別環境では動かない」という悲しい事態なので、 printf debug で少しずつ状態を確認していきます。

git は存在するか
git の version は何か
git は実行できるか
remote origin は存在するか
commit log は辿る事ができるか
grep の version は何か
...

結果、「actions/checkout@master を使うと repository の情報が消える(?)」事が判明しました。具体的には

git コマンドは実行できる
git show を行なうと、全ファイルが新規作成扱いになっている
origin を fetch しても commit が取得できない

という謎の状態でした。その為、 actions/checkout@master は利用せずに直接 git clone を実行。
clone した repository では diff-tree が実行可能で、更新の有無が判定可能になりました。

余談: 第二条件の部分を書いている時に思った事

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

Pull Request を作成して提案する手がある

「ローカルでは動くが、別環境では動かない」

GitHub で動作 Image を提供している可能性がある

「actions/checkout@master を使うと repository の情報が消える(?)」

今は git clone で対応できるが、 branch の指定といったオプションに対応できない

第三条件: GitHub Actions だけでなく、ローカルの環境でも build できる

この条件は「ローカル環境でも Docker Image を作成可能」にする為につけました。メリットとしては

問題発生時の再現に使用できる
commit 前の Dockerfile も試しに build できる
新しい Image 作成時の build が楽

等があります。なお、この条件は build.sh に与える引数の有無で解決しました。

まとめ

結構な文量になりました。debug の説明を含めると長くなりますね。

結果的に「uses を排除して自前の run で記述する」というオレオレ GtiHub Actions で解決。

前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」

参考文献や関連した文献など

2019/09/21

git clean を使って untracked なファイルを削除する

Mercurial には hg purge というコマンドがあって、 hg で control していないファイルを一括削除できます。
具体的には add してないファイルとか、.c から作った .o とか、間違って作った Rails の migration とか。
それを Git でもできないかなー、と調べたメモ。

環境

OS: macOS Mojave 10.14.6
Git: 2.23.0

git clean

hg purge のようなコマンドは Git にも default でも存在していて、git clean だそうです。

untracked なファイルを消す際は

$ git clean -fd

とかすると add してないファイルが消えます。

あとは、すぐに消すのではなく、消す対象が何かを教えてくれる -n (--dry-run) option が便利です。

$ git clean -fdn

で削除対象一覧を出してくれます。ちなみに

git clean -f -d -n

と書いても良いみたいです。

他には

-X option: .gitignore で指定されたファイルのみを消す

.o とかが消えてくれる。
あと untracked なファイルは消えない
新規にファイルを作った上で rebuild したい時に便利だよ、とのこと

上で書いた 3つは全部 man git-clean の受け売り。

-x option: .gitignore で指定されたファイルも削除対象 + untracked のファイルも削除対象

かなり危険なので事前に dry-run を付けた方が良いです
git clean -fdx とかすると clone 直後くらい綺麗な状態になります

とかですかね。
さらに詳細を知りたい場合は man git-clean を読んで頂ければ。

参考

2019/08/20

hub コマンドの user 設定を変更する

hub というコマンドがあります。
GitHub に関連したコマンドが追加された git の wrapper です。
例えば

$ hub clone neovim/neovim

とすると

$ git clone git@github.com:neovim/neovim.git

相当の事をしてくれます。

git の wrapper になってるので、 hub だけで全てを済ませる派の人がいるかもしれません。

環境

OS: macOS Mojave 10.14.6
Homebrew: 2.1.10
Homebrew/homebrew-core: (git revision ea34; last commit 2019-08-20)
hub: version 2.12.3
git: version 2.23.0

設定を変更するきっかけ

$ hub browse tmux/tmux

とすると tmux/tmux をブラウザで開いてくれます。

$ hub browse hoge

とすると atton-/hoge が開かれました。
私の GitHub Account は 'atton-' で取得して 'atton' に変更した経緯があります。
なのでどこかに古い設定が残っている筈。

$ git config --list

で git の設定を確認しても 'atton-' は存在しない。
むしろ github.user=atton になってるくらい。
hub が git の wrapper になってる事のデメリットがちょっとあって

$ hub config --list

としても git config --list の時と同じ内容が出てくる。
つまり hub 経由で config を update しても git の config が変更されそう。

ということで 'atton-' を設定している部分を探してみる。

設定箇所探し + 設定

$ hub --help

hub と git の help が出る
hub 部分に config とか setting とかの項目は無い

$ man hub

config で search するとありました。
どうやら $HOME/.config/hub に書かれているようです。
編集すると 'user: atton-' になっていたので 'user: atton' に修正。

$ hub browse dot_files

とかすると私の dot_files が開かれるようになりました。良し良し。

おまけ

ちなみに私が良く使うコマンドは

$ hub browse

です。

current directory の repository の github ページがブラウザで開きます。

あとは hub clone くらい……?

実際 hub をあまり使わないのは

hub が無い環境で作業することもある
wrapper が隠してくれているオプションとかに「気付かずに助けられている」のは勘弁

とかの理由があります。

なので、個人的にはなるべく git を使うようにしています。

もちろん hub の方が便利な時は hub を使います。

2017/11/26

Git の hook を使って merge line がある時には commit できないようにする

Git で merge した時に conflict すると
みたいな形で表示されます。これを解決して commit すれば問題解決。
しかし、複数部分が conflict していると、たまにこの線を commit することがあります。つらい。
それを阻止したいのですが、人の手でやることでは無いので自動化します。

man githooks

$ man git

とりあえず man を読む。
/hook とかすると githooks というものがあると。

$ man githooks

$GIT_DIR/hooks か core.hooksPath/* のファイルを読み込むと書いてあります。
hooksPath を設定してみます。~/.gitconfig あたりに

を追記。
たぶん git confing --global とかでもできる。
実際やることは ~/.gitconfig への書き込みだから同じなのだけれど。
これで全リポジトリに対する設定終わり。

~/.config/git/hooks/pre-commit を書く

こんな感じかな。参考とか。

これで commit 前に <<<<<< などの線があったら警告してくれます。
実際は単なる shell script ですね。hook なので特定の action があった時に起動してれる感じ。
ちなみに git init したリポジトリの .git/hooks/* あたりを見ると sample があったりします。

動作サンプル

さて実際はどう動くかと言うと、こんな感じ。

commit したのに status が clean になってませんね。
これでミスって merge を解決し忘れたファイルを commit することも無いでしょう。めでたしめでたし。

おまけ

ソースにどうしても <<<<<< などの線を入れたい場合は

$ git commit --no-verify

とか使うと良いようです。

この hook を足す commit そのものが hook に引っかかったので使いました。

参考

man git
man githooks
Git - git-merge Documentation
Git pre-commit hook that checks ruby source files for Pry breakpoints
Add global git hook for pre-commit

2017/11/11

ドワンゴの Scala 研修用テキストに Pull Request を投げた

ドワンゴ在籍時代に新人向けの Scala 研修がありました。
研修テキストはGitHubで公開されていて、間違いや修正点があれば Pull Reqest を投げることができます。
テキストを読んでいると、文とサンプルコードの整合性が取れていないのに気付いたので、修正の PR を出しました。
そうしたらマージされた。やったね。

2017/10/30

Mercurial Repository を Git Repository に変換する

Findy という転職サイトが GitHub の public repository からスキル偏差値なるものを算出してくれます。
一度登録してみると、スキル偏差値はプレミアム本会員になるギリギリの60でした。
実際どのくらいなのだろう60。定量的な値になってると良いのだけれど。

さて、 GitHub には大学とは関係ない個人のプロダクトとかを載せていました。
大学での課題やプロダクトは大学の Mercurial Repository に残しています。
ですが、この際 GitHub にも載せることにしました。
単にスキル偏差値を上げたいだけとも言う。
単に bitbucket に上げても良いのだけれどそれだと Findy に拾って貰えないので。

環境構築

Mercurial から Git への変換は fast-export を使います。

$ git clone https://github.com/frej/fast-export

こいつは python を内部で使ってるのでその調整も必要です。

$ easy_install mercurial

とかかな。

私は python2 を brew で明示的に入れてるので

$ vim fast-export/hg-fast-export.sh

python -> python2

$ pip2 install mercurial

とか。実行時にエラーが出なければOKだと思います。

自分だけが Author の Mercurial Repository の変換

fast-export のセットアップが終わったら、変換します。

$ mkdir git_repo
$ cd git_repo
$ git init
$ ../fast-export/hg-fast-export.sh -r /path/to/hg_repo

これで Mercurial の Repository を元に git に commit しまくってくれます。

きちんと時刻とかも残るので便利。

Author Information が気に入らない場合

私は大学時代の時は大学のメールアドレスで commit していたので、GitHub にはアイコンが無い。

これはちょっ悲しいので Author の情報を変更する。

具体的には username と email ですね。変更するには

とかすると良い。長いけれど1コマンドです。

これは他人の commit も変更できちゃうので完全に悪用厳禁ですね。

他の人も commit している repository の変換

最初にやることは変わらずに変換。

$ ../fast-export/hg-fast-export.sh -r /path/to/hg_repo

んで、 Author を変更する時に発行するコマンドを変えます。

if 文で自分の変えたい username+email を指定してあげています。

これで指定したものだけが変更されます。便利。

こっちも長いけれど1コマンドですね。

これで他人の成果をきちんと残したまま、自分の気に入らないメールアドレスを書き換えられます。

やっぱり悪用厳禁なコマンドなので注意。

fast-export で変換した Repository List

どうせなので公開できる成果物のリストを残しておきます。

思ってたよりありますね。仕事してたなー。

この成果物が誰かの参考になれば幸いです。

オチ

この後 Findy で GitHub 再連携をしたところ、算出方法が変わったようで51に下がりました。かなしい。

環境

OS: macOS 10.12.6
fast-export (cc8fefe0083bc38c781341a86a1779dc5941f6e2)
python: 2.7.10

pip: 9.0.1
mercurial: 4.3.3

Mercurial: 4.3.3
Git: 2.14.3

参考

2017/10/07

Akatsuki を OSS 化した

Akatsuki を OSS 化して GitHub で公開しました。

Akatsuki とは琉球大学情報工学科のシステムです。具体的には

学生のIP申請

対応するドメインを内向き DNS へと登録
その IP を DHCP で配れるように

学生のVM新規作成/起動
学生のパスワード変更

unix login
802.11X で無線に繋ぐ際の RADIUS を提供

といったことができます。

つまり今まで記事で部分部分を解説していたものの本体です。

公開にあたって

もちろん大学の内部情報をそのまま GitHub に投げるわけにはいきません。

なので、こいつは OSS 化用にいじってあります。

具体的には漏れたらまずい情報を消してあります。
あとライセンスは MIT だし気にせず自分でいじって公開していく。

その手順として

$ git rm very-important-information

で公開してはいけない情報を消して

$ git commit

コミットします。

$ git rebase -i --root

その後に rebase します。
全部 fixup して一つのコミットにまとめてしまいます
fixup しないと復元ができてしまうので、消しても意味がない。
ということで、逆に言えばこの手順を踏めばアカンやつを隠蔽できます。

まとめ

所謂実績の一つとして見てもらえると良いかなー、と思って OSS 化しました。

ということで、大学生/大学院生時代にしていた仕事の1つが OSS になりました。

2017/06/08

どのリポジトリでも .DS_Store や swp ファイルを git に commit しないようにする

git init する度に .gitignore を設定するようにしているのですが、迂闊に git add . とかをして .DS_Store などの入れたくないファイルを git に commit してしまうことが何度も発生。

何回も発生するのなら対策しておこう、ということで、どの git リポジトリでも特定のファイルを ignore するようにしました。

とはいっても ~/.config/git/ignore に ignore するファイルを指定するだけ。
これでどのリポジトリでも .DS_Store などの指定したファイルが ignore されます。便利。

にしても ~/.config で書く流儀だと ~/.gitconfig はどう書いたら良いのだろうか。

参考文献

グローバルで.gitignoreを適応する - Qiita

2014/12/27

私の git の参考文献とか使い方とかまとめ 2014

git どうやって勉強したのさー、って質問が。
参考になるかはともかく私の最近の git の使い方についてまとめてみます。
このコマンドはどういう挙動をします、って話ではなくて、どんな時に使う、くらいのまとめです。
調べるためのキーワード提供にでもなれば。

参考文献とか考えとか

staging とか workspace とか commit とか : どこだっけ。ちょっと覚えてない。
rebase とか –no-ff の知識 : こわくない git かな。基本的に git の話するときはこれを勧めてます。
tips とか : こことか。必要になったら調べる感じ。
branching model : 過去のログを見るとここを参考にしてたみたい
branching model : 複数人数で git を使う時の自分の中ルールだと
- master には直接 commit しない
- origin/master への push -f は最終手段
- merge は master に対して –no-ff
- conflict の解消は branch での rebase で解決する
- github を使ってるなら merge は pull request で、 conflict したら branch で rebase
commit message とかの話 : ChangeLog を支える英語

基本的に使うコマンド

git init
- リポジトリ作る。
git ( add | mv | rm )
- ファイルの追加とか移動とか削除とか。
git st
- status を見る。面倒なので alias かけてます。
git commit
- コミット。
git log
- ログを見る。2.0 くらいから特に設定しなくても色が付くようになってうれしい。
git diff (–cached)
- diff を見る。
- diff で commit と workspace 間の diff。 add してなかったらこっち。
- diff –cached で commit と staging 間の diff。 add した後に diff りたかったらこっち。
git fetch
- remote から変更を取ってくる。
- commit してない変更がある時とか、ローカルブランチで作業してる時に変更が欲しかったら fetch
git pull
- remote から変更を取ってくる + 変更を反映する
- master で変更を取ってきたいなら pull で良いかな、くらいの使い方
git clone
- リポジトリを clone する
- github は https:// を clone すると毎回 password 聞いてくるので git:// で clone すると楽
git merge (–no-ff)
- branch を merge する
- 私は master には直接 commit せずに –no-ff する主義。
git branch (-a | -d | -D )
- ブランチを見たり作ったり
- -a で remote も含め全部。
- -d で削除。 -D で強制削除。
git co ( -b | -f )
- checkout する。面倒なので alias かけてる
- 最近 branch するのが面倒なので -b を良く使う気がする
- 作業前の状態にしたいやー、って時は -f を使う。
- stash でも良いけれど本当にいらないと思うときはこっち。
git reset
- add したやつを戻す。
- soft reset, hard reset がある
git rebase -i
- rebase は -i を良く使うかも
- master から派生した branch にいる時は rebase -i master が楽
- conflict したら –abort 諦めるくらいの軽さで commit の入れ替えとかたまにやる。
- 最近は commit –amend するより commit して rebase -i で fixup とかする
- fixup と rewind で –amend みたいなことができるし良いかなーといった感じ
git remote ( add | rm )
- そんなに使わない
- clone すると origin があるので基本はそれを使ってる
- fork したリポジトリの upstream を設定する時くらい

あると便利

git grep
- リポジトリ内を grep する
git ls-files
- リポジトリに入ってるファイルの一覧
git remote prune origin
- remote に無い branch を local でも消してくれる
- branch -a がうるさく無くなるのでちょっと快適
git reset –hard
- 最終兵器。
- 間違って master に commit した時に checkout -b して reset –hard HEAD^ とか便利
git reflog
- rebase, merge にミスった時はコレ
- reflog 漁って git reset –hard で大体解決する
- ので gc は設定で切ってたりします。コマンド打つと勝手に gc して止まるのも何だし。
git stash ( pop | apply |save )
- workspace の変更を一時保存
- 軽量 commit みたいなものだけれど最近は commit + rebase してしまうかも
- この実装でいけるか怪しいけれど一応は保存しておきたい、くらいの時に save するかなー、くらい
git bisect
- エンバグした時に便利
- 動いてた時と動いて無い時を指定して、動かなくなった commit を特定するやつ
- これをまともに使うためにも master は必ず動く状態の commit のみで構成したい理由はコレ
- コンパイル通らない、とかだと bisect できない
git cherry-pick
- 特定の commit を拾ってくるやつ
- master に特定の commit があるなら rebase で拾うけれど
- 欲しい commit が他 branch でそれ以外の commit を拾いたく無い時とかに使う
git archive
- repository を zip とかにできる
- なんか提出する時とかに使ってた記憶。そんなに使わないけれど特定の人達には需要あるかも

2013/09/29

git勉強会 in Okinawa に行ってきた

2013/09/28 に git勉強会 in Okinawa があったので紛れ込んできました。
togetter はこんな感じ。

まずは git のハンズオン。資料はこんな感じでした。
ハンズオン形式は始めてでしたが、これは個人でやるタイプなのでひたすらもくもくでした。
割と見たことある内容なので資料を読んでました。
rebase で fixup にするとコメント無し squash にできそうなので便利そう。

次は @Tomohiro さんによる git を使った開発の話。

git は「複数人数で開発とかする上で使えそうなもの」であって、開発のスタイルとかに合わせて使っていこう、みたいな話とか。
例えば git-flow とか github-flow とかみたいに git を使うスタイルはいくつかあるらしくて、自分達に使えそうなものを取り入れていけば良いのでは的な話。
具体例として @Tomohiro さん達はスクラムしてたりします、とかとか言ってました。
github 使うなら huboard 使えばカンバン化できたりするよー、とかとか。
型に合わせるのも良いけれど必要なところだけ取ってけるともっと良いんだろーなー、とか思いましたまる。

あとは、環境な話とか。
vagrant を使えば環境構築のレシピをテキストベースで保存できる == git で管理可能ですよー、とか。
環境の依存とかも解決できるしロールバックもできるし良い感じそう。

packer を使って OS Install -> vagrant で上げて -> puppet でコマンドとかを入れる

とかしてるみたいです。
chef も良いけれど、 chef は割と厳密なファイル構成でファイルを書かないといけないらしくて、 puppet は単純な構成でも厳密な構成でもできるし良いよー、と。
とりあえずテキストベースで環境を構築できるしこうやって公開もできます、みたいな話。
便利そうなので次何か構築する時は使ってみたいなー、とか思ったり。

ハンズオンの二回目はコンフリクトの解消。
だけれど曰く「ちゃんとコミュニケーションできてたらコンフリクトなんて起きないよ」と。
ハンズオンでは積極的にコンフリクトして解消する作業。
「コンフリクトするのは怖くないよ」みたいな印象を持ってもらえば良いな、って形らしいです。

ちなみに、 rebase 派と merge 派は分かりあえないらしいです。
rebase は svn とかのユーザの感覚らしい。まっすぐなので。
merge はなんだろ。 mercurial かな。
ちなみに私は rebase からの merge --no-ff 派。
merge 時に conflict するのは面倒だけれど master に残すのは merge commit じゃないと面倒そうなので。
なので rebase -i で 1つにするほどでも無いけれど、master に直 merge も嫌かなー、くらいのスタンス。

おまけで勉強会の時に飛んできた URL 群たち。

Git を学ぶ - @Tomohiro さんによる gist。 git を学ぶ上で便利そうな tips とか command とかの紹介。
あと、git-バルスでは「どうやるとgitがぶっ壊れるか学べるから良いよね」とのこと。
ちなみに加えて「まぁやらないですけれど」とのこと。

ChangeLog を支える英語 - yamane さんが投げてたURL。
commit message の先頭は大文字にしましょうねー、とか comment を書く上での tips 集。

git commit時のコメントを英語で書くための最初の一歩 | hiro345 - kanpe さんが投げてました。
これも tips 集みたいな感じ。ざっとしか目を通してません。
commit する前に確認すべきこと、みたいなのは良い感じだったよーな。

ChefとPuppetの比較 - こちらも kanpe さん。git じゃないけれど。実を言うとまだ目を通してない。

感想。

全体的にもくもくな感じでした。
コンフリクトのハンズオンの時に知らない人とあたればまた違ったのかもしれませんが。
というか私が知らない人と話してないだけか。
git そのものは知ってる知ってるみたいな反応してしまったし。でもほぼ個人でしか使ってないオチ。
個人的には仮想環境な話が聞けて良かったかなー、と。次に git を使った開発の実例とか。
git user (というかバージョン管理する人)が増えると良いなー、とか思いながらかんそーおしまい。

2013/02/23

brew な git で zsh の補完が効かなくなった

brew で入れた git を使っていて

$ git add hoge<tab>

とかすると

(anon):6: command not found: __git_main

とかエラーが出て補完できないなど。

こちらを見るとどうやら補完用のスクリプトがちゃんとリンク貼られているかが問題な様子。

$ brew unlink git
$ brew link git

でリンクを貼りなおすと復活。
ログは残ってないけれど、 unlink が 214 で link が215 くらいなので一個消えてたっぽい。
brew cleanup で prune されたのが1つあったよーな気もしたので、それで消えたのかな。

2012/11/26

git archive で指定ファイルを除外する

git archive コマンドを使えばリポジトリをアーカイブできるみたいです。

けれど .gitignore とかはアーカイブにはいらないのでどーにかできないかな、と思っていると tar とかでフィルタする方法があるらしい。

けれど Mountain Lion にデフォルトで入っている tar には --delete オプションが無い様子。

で、もう少し調べると .gitattributes なるものがある様子。
これを書いているとファイルに対していろいろと設定できるらしく、 export-ignore と書いているとarchiveに含まれなくなるみたい。

.gitignore 除外のための .gitattributes の例はこんな感じ
.gitattributes を書いて実際にアーカイブを試してみるけれど
$ git archive HEAD -o archive.tgz
だと除外されずに変わらない。
$ git archive
を打つと --worktree-attributes なるオプションがあるらしいので、これを付けるとちゃんと除外された。
なので
$ git archive HEAD --worktree-attributes -o archive.tgz
とかするとOK。

それで、.gitattributes の試しに作ってみたのがこのリポジトリ。
.gitignore と include.txt と exclude.txt と archive.sh があって、.gitignore と exclude.txt は .gitattributes で export-ignore してる。

archive.sh を走らせると archive.tgz ができる。
解凍して中を見ると、include.txt と archive.sh しか入っていないはず。
実際にどのコマンドが走ってるのは archive.sh を見てみてください。

これで archive に必要無いファイルをgitできちんと管理しながら git archive から除外できそう。

登録: 投稿 (Atom)