Gitで特定のbranchのみcommit/push出来ないようにする

小ネタです. Gitで開発をしていて, 特定のbranchのみcommit/pushしたくない, という場合があるかと思います. 例えばmainブランチにはcommit/pushしたくない, など.

これを実現するには様々な方法がありそうですが, 自分はGitのhookの機能を使って実現しています. 今回の場合, ｢commitしたくない｣を実現するためにcommit前に発火するpre-commitのhookを, ｢pushしたくない｣を実現するためにpush前に発火するpre-pushのhookを使えば良さそうです. 例として, mainブランチについてcommit/pushをしたくないという場合には, 次のようなスクリプトを設置するとうまくいきます(commit/pushしようとすると, メッセージを出力した上で強制的に中止してくれます).

.git/hooks/pre-commit

#!/bin/sh
# mainブランチにはcommitできない
if test "`git symbolic-ref HEAD | sed -e 's:^refs/heads/::'`" = 'main'; then
    echo "cannot commit on main branch."
    exit 1
fi

.git/hooks/pre-push

#!/bin/sh
# mainブランチにはpushできない
if test "`git symbolic-ref HEAD | sed -e 's:^refs/heads/::'`" = 'main'; then
    echo "cannot push on main branch."
    exit 1
fi

あわせてよみたい

papix.hatenablog.com

ISUCON11 ｢天下n品｣で予選参加して敗退しました

同僚の id:stefafafan と id:masawada と共に｢天下n品｣で参加して, 予選敗退しました. 最終スコアは 33,586点とのこと.

自分がやったこととしては｢Redisの活用を試みた(なお, スコアの上昇には寄与しなかった模様)｣の一言に尽きます. その他やったことは, チームメンバーがエントリに詳しく書いてくれたのでそちらをご覧いただければと思います.

stefafafan.hatenablog.com

masawada.hatenablog.jp

感想

• 事前に準備できるところを準備しておくことができてよかった
  • ISUCON, 予め準備できる部分(初動やツールの用意)とそうでない部分(問題を見て, 臨機応変に対応していく部分)がある... と思っていて, 前者についてはある程度事前に準備と練習ができたし, まだまだ改良の余地はあるものの素早く完了して, 後者の問題に取り掛かることができた
  • チームメンバーが事前にいいツールをガンガン用意してくれたので, とても助かった. ここまで快適にISUCONに取り組めたのは初の体験で, すごいと思った
• 途中でスコアが下がってきた時に, 一歩立ち止まれなかったのは良くなかった
  • 個人的にはそこで焦ってしまった気がする. コードを少し戻して, どこでスコアが下がったのか? というところ調べた方が良かったのかも, と思っている
  • 焦っていろいろ手を打つ → 上がらなかったり, むしろ下がったりする, という悪循環に陥って精神的にもちょっと大変だった
• 問題の分析と解決策の筋が悪かったので, スコアが伸び切らなかった... というのが今回のISUCONの総括になりそう
  • この辺りはいろいろな問題を見て, 試して, 場数(?)を踏むのが近道なのかな? と思っている
  • 過去問を解いたり分析したりして, 使える手を増やせるとISUCONでも業務でも活きそうと思った
• Redisの活用, うまくいかなかったけど, 最後まで完了できたのは良かった(良かったこと探し)
  • しかも一番得意なPerlではなく, Go言語で最後までやりきれたのは自分でも驚いている
  • 過去, こういう大技系は試みようと思って諦めたりうまくいかないことが多かったので, (スコアには寄与できなかったけど!!!!)ベンチ通るレベルで完了できた, ということは手応えを感じた
    • 将来, もしISUCONや業務でRedisがうまくハマるパターンが出てきた時に｢やれるぞ!｣と言えるため
• 一方で, このままだと何でもかんでもRedis化! と言いそう(とにかくRedisというハンマーを振り回したい状態)なので, 他の大技候補はもちろん, 小技候補もブラッシュアップしておきたい
  • 事前に過去問でRedis化の練習をしたおかげで, 高速に使えたのはよかった
  • なので, ISUCONを題材に, いろいろな技術要素の練習をできると良さそう
    • 最近自分にとって良い, 好き勝手できる｢庭｣的なコードがなかったので, それをISUCONの練習と組み合わせる(?)といいのかも, と思ったりした
• あとは大技着手のタイミングも再考の余地がありそう
  • 今回は一通りの準備と調査が終わった段階で実装に着手したけど, もう少し小技というか手堅い改善を入れた後の段階でボトルネックを探して大技に着手した方が良さそうと思った
  • ちゃんと練習しておけば, 大技の完成にかかる時間はもう少し短くできると思うので, やっぱりいろいろ手を動かして, 使い慣れた道具にしておくのが大事そう

良いメンバーに恵まれて, ｢次があったら勿論またやるぞ!!!｣という勢いになっているので, 次こそは予選突破してみんなで天下一品飲みで祝賀会をしたいですね. やっていくぞ!!!!

Kichijoji.pm #27で｢(今更)Amplifyさっくり体験｣というLTをしました

久々にKichijoji.pmに登壇して, AWS Amplifyについて話しました. 前回の登壇が1月の｢CI/CD活用事例＆TIPS発表会｣だったはずなので, 半年ぶりの登壇となりました. ...サボりすぎ!!! なにもかもが久々すぎて, LTなのに事前準備に一苦労したりしていました(いろいろ忘れていた...).

papix.hatenablog.com

AWS Amplifyですが, 先日会社で開発合宿という催しがありまして, そこでのプロトタイプ開発活用したのでした. つい先日, ｢React.js & Next.js 超入門第2版｣を読んでいるというエントリを書きましたが, これは事前に｢今回はAWS AmplifyとNext.jsでやるぞ!｣という会話をしていたので, 事前に予習をしていたという文脈があります.

papix.hatenablog.com

React.js, 何度か習得を試みて中途半端な理解で終わる... みたいなのを繰り返していたのですが, 今回1冊ちゃんと(手を動かしつつ)本を読むことで(Next.jsとあわせて)だいぶ理解が深まった気がします. AWS Amplifyの力も活かしつつ, 限られた時間でいい感じに動くものを作り上げられたのは良い体験でしたし, 自信にもなりました.

一方でAWS Amplifyですが, 3日だと表面的な(?)部分しか触れなくて, 高速にプロトタイピングをするには最適でしたが, 実サービスとして運用するにはもう少し理解を深める必要がありそうだな〜, と思いました. 例えば今回はAppSyncでGraphQLを運用していたのですが, シュッとGraphQLのスキーマを変更すると, 一時的にAppSyncが反応しなくなるっぽい(?)出来事があって, その辺りどう運用/解決するかなど考える必要がありそうだな〜, などなど考えていました.

とはいえ総じてAWS Amplify, 大変に良い体験でした. スライドにも書きましたが, 今後何か動くものをシュッと作りたい時に使える良い武器が得られた, という印象です.

小ネタ: TerraformでS3にファイルを設置する

小ネタです. TerraformでS3のbucketを作るとき, ついでに何かしらのファイルを設置したいというシーンがあるでしょう. そういうときは...

resource "aws_s3_bucket" "sample" {
    bucket = "sample-bucket"
    acl = "private"
}

resource "aws_s3_bucket_object" "for_monitoring" {
    bucket = "sample-bucket"
    key = "file"
    source = "/path/to/file"
}

こういう感じで, aws_s3_bucket でbucketを作った後, そのbucketに aws_s3_bucket_object をしてあげると良いです. この場合, /path/to/file に設置されたファイルが, bucket(sample-bucket)にfileという名前で設置されます.

また, source ではいわば｢ファイルのアップロード｣的な挙動になりますが, ｢ファイルを用意したくない(ファイルの中身を.tfの中で設定したい)｣という場合は, 次のように content を使うと良いです.

resource "aws_s3_bucket_object" "for_monitoring" {
    bucket = "sample-bucket"
    key = "file"
    content = "hello, s3!"
}

こうすれば, bucket(sample-bucket)に, fileという名前で, 中身がhello, s3!となったファイルが設置されます.

毎日ちょっとずつコードを書く, という行い

なんと気がついたら5月でした. ここ最近は, ｢せめて月1でこのブログを更新しよう...｣と思っていたので, 不覚!!! という気持ちです(?). 4月のことを振り返ってみると, 特段忙しかった訳でも, 体調崩した訳でもないので(3月末にちょっと熱を出した事はあった), 恐らくネタの枯渇などが原因だったのではないか...? と思います. 他の理由を強いて挙げるとするならば, 4月を通して花粉か何かが激しくて, 常時だるい感じの日々が続いていた... というのがあるかもしれません.

｢これではいかんよな...｣というのと, あといろいろなことを考えた結果, いい加減(もう31歳だが!?), フロントエンドの技術を真剣に学んでいく必要がある(このワード, もう3〜4回くらいこのブログで書いている気がしており, つまりは何度も試みて何度も諦めている...)と思ったので, 最近はReactやNext.jsについての本を読んでいます.

React.js&Next.js超入門 第2版

...ところでここ最近, Twitterなどで, ｢1日何かしらのコードを必ず書いて, GitHubに草を生やし続ける｣という行いをしている方を見かけます.

感動の瞬間はもうすぐそこ pic.twitter.com/ar8NLaBAw2

— Yutaro Muta (@yutailang0119) 2021年4月10日

自分は熱しやすく冷めやすい性格もあるので, ｢いやー, いい取り組みと思うが, しかしやっても1週間くらいで終わるのでは...?｣と思っていたのですが, 先の本を読んでいくと結構サンプルコードが多く, かつ(少なくとも序盤は)割と量も少ないので, ｢まあ, 1日1写経くらいでやってみようか...｣と思ってやってみたところ, 案外続いています.

序盤は別のことをしていたので隠しています(?)

1週間で終わるのでは... と思っていたところ, 現時点では2週間ほど続いています. 良い題材を見つけることができた, というのもそうですが, ｢1日1写経｣という形でハードルを下げ, 小さくスタートできたのも良かったのではないかと思います(この辺りはまさしく｢小さな習慣｣で書かれていたことだなあ, と思いました).

papix.hatenablog.com

今後のことを考えると, 体調不良や忙しさなど, うまくバランス取りながら継続していくのと同時に, さらなる題材を探していくのも課題と言えそうです. 1日ちょっとの写経, 1日ちょっとの学習ではありますが, しかし何もしないよりは遥かにマシ. ということで, 可能な範囲で継続していきたいものです.