Git

@kyanny さんの記事を自分なりに整理してみる。 ずっと「マージした後にメインブランチを production デプロイする」というワークフローだと勘違いしていた。 昔は「マージ後にデプロイ」だったが、いつの頃からか「マージ前にデプロイ」に変わったらしい。 どこかでそんな話は聞いていたけど、実際のところはどうなんだろう？と以前から疑問だった。やっぱりそうだったか。 現在の GitHub flow というか、GiHub の公式ガイドにそのものズバリ書いてあったのね。灯台下暗し…。 Understanding the GitHub flow · GitHub Guides “>” を数回クリックし、“Deploy” に進むと書いてある。 With GitHub, you can deploy from a branch for final testing in production before merging to main. main ブランチにマージする前に、最後の確認をするために本番環境にデプロイする。 If your branch causes issues, you can roll it back by deploying the existing main branch into production. もし問題が発生したら、main ブランチを本番環境にデプロイすることでロールバック出来る。 main ブランチの protection rule は “Require branches to be up to date before merging” を有効にしているのかな。いずれにせよ、main ブランチの commit 全部入りのブランチをデプロイしているはず。...

任意のコミットを無視して git blame してくれるやつ。いわゆるメガコ ミットを無視した blame をしたいときに使える。 なぜかセットアップにひどくハマったのでメモ。 セットアップ方法 git clone してくる $ git clone https://github.com/google/proto-quic.git 以下のように、パスの通ったディレクトリに git-hyper-blame という 名前のシンボリックリンクを作る。git のサブコマンド hyper-blame が 利用可能になる $ ln -s ~/src/github.com/google/proto-quic/depot_tools/git_hyper_blame.py ~/bin/git-hyper-blame ※ Python は macOS Sierra 付属の /usr/bin/python (Python 2.7.10) で 動きます。pip install とかも不要です。 使い方 普通の blame はこちら。 $ git blame Gemfile 99d5ce00 (Takashi Masuda 2016-08-26 23:06:50 +0900 1) # frozen_string_literal: true 99d5ce00 (Takashi Masuda 2016-08-26 23:06:50 +0900 2) ^1039771 (Takashi Masuda 2016-07-16 13:28:00 +0900 3) source 'https://rubygems....

Chef-solo(Knife-solo)とBerkshelfの話。 Berksfileに例えばこうやって書けば使えた。これは有能！ relってサブディレクトリのことだったのか。Gemfileで使ったことなかった。 cookbook ’nginx’, git: ‘git@github.com :masutaka/cookbooks.git’, rel: ’nginx’ $ bundle exec berks vendor vendor/cookbooksを実行すると、 vendor/cookbooks/nginxにインストールされる。 .chef/knife.rbを以下のように変更すると、インストールしたnginxレシ ピをnodeやroleから参照できる。ちなみにcookbook_pathは後ろから先に 参照される。$PATHの逆。 cookbook_path [“cookbooks”, “site-cookbooks”] ↓ cookbook_path [“cookbooks”, “site-cookbooks”, “vendor/cookbooks”] ※ .gitignoreに/vendor/cookbooksの追加も忘れずに。 private repositoryの時はこの書式は使えなかった。やり方はあるかもし れない。 cookbook ’nginx’, github: ‘masutaka/cookbooks’, rel: ’nginx’ 今までは https://github.com/masutaka/cookbooks とかをGitのsub moduleとしてガッツリ指定していたため、追随するのが大変だった。 cookbooksを変更する人も気を使ったし。 この辺の話に関連する。 JenkinsでサーバのCIを始めました｜feedforce Engineers’ blog Berksfileの書き方は公式ドキュメントに書いてある。 http://berkshelf.com/ 追記: 依存関係(metadata.rbのdepends)は見てくれなかった。そりゃそうか。 継続調査。

７月に東京に引っ越してきて、早３回目の勉強会。 そろそろ何もない週末が欲しい…w さて、そうは言っても東京で何年ぶりかに開催されたEmacsのイベント。 @mori_dev さんはじめ、お初にお目にかかれた方が何人もいて、楽しい時 間を過ごせました。 最近は勉強会ではなるべくメモを取らずに、イベントを楽しむようにして いるので、思い出したまま書いていきます。 個人的に一番面白かったのは、@inoue_ariel さんの「Emacsのバッファの 内部実装について 」。Emacsと言えばギャップバッファ、ギャップバッファ と言えばEmacsというのはもちろん、ギャップバッファという名前自体初め て聞きました。しかし、memcopy()のコストがあれほど低いのにはビックリ です。最近のCPUはキャッシュの容量が増えてるのが要因なんでしょうか。 でもギャップバッファって昔から使っているのですよねえ。。 Emacsのソースコードは [2010-06-19-2] で、その変態性を認識したことが ありますが、この時の記事も井上さんじゃないですか！(やべっ！深夜に鳥 肌立った！)2010年当時は組み込み業界で働いていたこともあり、アリエル も、アリエルの井上さんも存じ上げなかったのですが、自分の中で今繋が りました。 (衝撃的すぎて、何も思い出せなくなってしまった。。) さて、私もLTやりました。 内容はegg.elとgit-dwin.elの紹介です。自分のまわりで、コマンドライン からgitを使っている人が意外に多いので、発表することになりました。 頑張ってEmacsで全部やる必要はないけど、結構簡単に楽できるから、まあ ゆるく使おうよ。そんな内容です。 当日の夕方近くに急にやることが決まったので資料をちゃちゃっと作り、 まあ5分なんて余裕でしょ。なんて思っていたら大失敗w 発表用の画面操作 に手間取るわ、実演用のEmacsはミニバッファが見えないわ、時間は足りな いわでさんざんでした。さらには腹が減りすぎて、手がぷるぷる震える始 末。よく考えたらLTやるのは初めてでした。次回に生かしたいと思います。。。

git stash は便利なんですけど、stash したのを忘れたり、egg 使ってい ると pop しても消えなかったりするので、もう使わないことにしました。 gitで現在の作業内容をクイックセーブする - アジャイルSEを目指すブログ この記事からヒントを得て、最近はオレオレ git qsave を使ってます。 見てのとおり、変更点を全部 commit しているだけです。 git reset –soft ‘HEAD^1’ とかすれば commit 前の状態、つまり Staging の状態に戻ります。 リセットしないであとで圧縮 commit しても良いですね。 git-qsave という名前で(git-qsave**.sh** じゃないですよ！)パスの通ったディ レクトリに置けば、git qsave で実行できます。

git push したら、すぐにテストを実行して欲しいだけなんです。 もう、ポーリング [2011-12-30-5] で新しい commit があるかチェック するのは嫌なんです。 いや〜、Jenkins-CLI でやろうとしてかなりハマりました。 loading... loading... loading... 初心に返ってJenkins実践入門 読みましたが、Git には特に触れられておらず…。 どうせこれも Jenkins-CLI のススメだろうと WEB+DB PRESS Vol.67 の 17 ページ目のコラムの URL を読んでみた。 「あれ？ Git プラグインだけでできるの？」 試しに git push の後に Web ブラウザで http://example.com:8080/git/notifyCommit?url=/home/foo/hoge.git にアクセスしたら、ビルドが始まったじゃありませんか！ あとは /home/foo/hoge.git/hooks/post-receive に以下を追加して終了。 curl 'http://example.com:8080/git/notifyCommit?url=/home/foo/hoge.git' なんか矛盾しますが、「SCMをポーリング」にはチェックを入れる必要があ ります。スケジュールは空っぽで OK です。 あと、今回のもうひとつの素晴らしい点は、認証が必要なシステムでも使 えることにあります。 長年のつっかえがやっと取れました！ Jenkins さん、dis ってすみませんでした。 Subversion はこの方法で出来るみたいです。

個人的なメモ その３ その１と２は [2010-04-29-1] [2011-07-05-1] にあるよ。 (1) タグ一覧を表示する。 % git tag (2) タグ 1.0.50 を作成する。タグの種類は「注釈付きのタグ」 % git tag -a 1.0.50 (3) 後からタグ 1.0.50 を 9fceb02 に付ける。 % git tag -a 1.0.50 9fceb02 (4) タグ 1.0.50 の情報を表示する。 % git show 1.0.50 (5) リモートブランチ origin にタグ情報 1.0.50 を送信する。 % git push origin 1.0.50 (6) リモートブランチ origin にタグ情報全てを送信する。 % git push origin –tags 参考情報: Pro Git - Pro Git 2.11 Git の基本 タグ

個人的なメモ その２ その１は [2010-04-29-1] にあるよ。 Git では、たった一日の作業でもブランチを作ることが良くある。基本ブ ランチは修正が終わったら master に merge して削除、つまり使い捨て。 別な作業が入ったら、master から新たにブランチを作る。 cvs とか svn だと、作業単位毎にディレクトリを掘って cvs checkout と かしていたけど、Git はこれをブランチ操作のみでできる点が超便利。 ただ、他に違わず、ブランチ操作も複雑なのでメモメモ。 (1) ローカルブランチの確認 % git branch (2) リモートブランチの確認 % git branch -r (1) + (2) % git branch -a (3) ローカルブランチ bar の作成 % git branch bar (4) ローカルブランチ bar への切り替え % git checkout bar (3) と (4) を同時にやる。 % git checkout -b bar (5) 任意のタグやリビジョンを起点に、ブランチ bar を作る。...

個人的なメモ。ページ番号は「入門 Git」より。 P21 # グローバル変数の確認 % git config --global --list # グローバル変数に自分の名前とメールアドレスを追加 % git config --global user.name "Takashi Masuda" % git config --global user.email "masutaka.net@gmail.com" # 大半の出力に色づけ % git config --global color.ui true # グローバル変数とローカル変数の確認 % git config --list P42 # コミットのための対話的なステージング % git add -i % git pull % git pull git://github.com/hayamiz/twittering-mode.git master git pull と同じ意味 % git fetch % git merge origin/master % git push --dry-run git@github.com:masutaka/twittering-mode.git % git push git@github....

emacs - Git Repositories Emacs のソースコードは Git(ぎっと) でも公開されているので、 Git Repository から取得してみました。 まず、Git というのは分散型バージョン管理システムです。CVS や Subversion は集中型バージョン管理システムなので、操作や考え方が少し 違います。 分散型バージョン管理については、以下のページにわかりやすくまとめら れています。 Git/分散レポジトリって何が嬉しいの - かWiki 作業者が個別にリポジトリを持てるので、commit 権がないプロジェクトの 修正を管理できる点が良さそうですね。 以下のページも面白いです。アリスの遅れている作業を、ボブが手伝って います。 アリスとボブのコラボレーション、gitをちゃんと理解したい！ - ザリガニが見ていた…。 これで、Git の概要が分かりました。コマンド操作は後で述べるとして、 先に Emacs のソースコードを取得することにします。 Debian では git-core をインストールすると、Git が使えるようになります。 以下のコマンドで Emacs のソースコードを取得できます。カレントディレ クトリに emacs というディレクトリが作られます。 % git clone git://git.savannah.gnu.org/emacs.git Emacs のソースコードを取得できました。 cvs update や svn update に相当するコマンドは以下になります。 % git pull CVS や Subversion を使ったことがある人なら、以下のページが参考にな りそうです。 Git/CVSコマンド対応表 - かWiki Git/Subversionコマンド対応表 - かWiki Git のドキュメントは以下のページをどうぞ。...