はじめに Snowflake でアドホックな集計やクエリ調査、リカバリ作業をしたときのワークシートを、チーム内で共有することがよくあります。そう、よくあるんです。結構頻繁に発生するのです。 そんなとき、ワークシートでの操作1つで共有できるのはとても便利ですよね。 しかしながら、アカウントを超えてワークシートを共有したいときって、あるじゃないですか？ そんなときに便利そうなパッケージがこちら。 Snowflake ワークシートを Git でバージョン管理するためのパッケージです。このパッケージをちょっと使ってみたので、ご紹介します。
濁点文字をソースコードに入れてしまって不具合を起こしてしまうということがありました。 自分の書いたカタカナの濁点が合成文字になってて(バ= ハ+゛みたいなやつ)そのバグに気づかなくて30分ぐらい無駄にしたアカウントです — hoshinotsuyoshi🥴 (@hoppiestar) July 23, 2018 なんという不覚。。 githubで見ても手元のvimで見ても見た目上は全く違いがわからんという状態。 いや、見た目でわかると思ったんですけどね� ちょっと以下3つの「バ」を見てください。 濁点アリの1文字「バ」 U+30D0 KATAKANA LETTER BA バ これが普通のバ。 2文字「ハ」+「゛」 U+30CF KATAKANA LETTER HA U+309B KATAKANA-HIRAGANA VOICED SOUND MARK ハ゛ 👆くっつきかたが、ちょっと不自
こうしてます。 git for-each-ref --merged HEAD --no-contains HEAD 'refs/heads/**' --format '%(refname)' \ | while read s; do echo "$s $(git rev-parse "$s")"; git update-ref -d "$s"; done git branch を使ったやり方が一般的なようだが（Google調べ）、配管（Plumbing）コマンドを使って厳密にやるならこうでしょう。 git for-each-ref はリポジトリのrefを一覧するコマンド。refs/heads/** はいわゆるローカルブランチにマッチするパターン。--merged HEAD で現在のブランチであるHEADにマージ済みのブランチを、--no-contains HEAD でそのうちHEADを除い
はじめに こんにちは、minne事業部でwebアプリケーションエンジニアをしているkazuです。今回の記事は、コミットメッセージを書く時に、自分がこれまで愛用してきたgitmojiをやめた話をします。 そもそもminneの開発チームにおけるコミットメッセージのルール minneの開発チームでは、コミットメッセージのルールは特にありません。 私がペパボに入社した当初、「逆か」というコミットメッセージもあったりなどして、意外とみんなカジュアルにコミットメッセージを書いているなと思っていました。なるべく実際に開発をする中でのプロセスをありのままに残していきたいという思いがあるのかなと思っています。 gitmojiとは 特にコミットメッセージのルールがないということで、これまで自分が個人開発などでは使ってきたgitmojiをminneの開発チーム内でも使っていました。 gitmojiとは、gitの
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
ビルドに時間がかかる（数十分～数時間以上）プロジェクトを扱うときに役立つかもしれない、Gitの小ネタです。 Gitには git help しても出てこない（ git help -a すれば出る）便利なコマンドがたくさんあり（※）、そのうちの1つ update-ref のご紹介です。 ※他には例えば update-index --assume-unchanged なども有名ですね。 どんなときに欲しくなるか こんな感じの、あるヘッダファイルに多数のソースファイルが依存するプロジェクトがあったとします。 repos |- common.hpp |- source1.cpp |- source2.cpp |- source3.cpp |- source4.cpp |- source5.cpp |- ... まずは master ブランチにいます。 $ git status On branch m
vim 内蔵の diff を使う internal 指定は diffexpr がセットされていると無視されてしまうので注意してください。また、 algorithm:アルゴリズム名 に加えて、差分の位置を最適化する indent-heuristic も指定しておくのがおすすめです。 もし diffchar.vim をお使いの場合、 diffexpr がセットされないように let g:DiffExpr = 0 も書いておく必要があります（diffchar.vim については別途記事を書いています）。 <<<<<<< 2019.01.05 追記ここまで vimdiff使ってますか？差分を取る際には非常に便利ですよね。git difftoolに設定して使っている人も多いと思います。しかしgit diffは差分計算のアルゴリズムを選択できますが、vimdiffはデフォルトでは差分計算のアルゴリズム
See how a minor change to your commit message style can make you a better programmer. I use a rigid commit message format, and it makes me a better programmer. feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Exampleschore: add Oyster build script docs: explain hat wobble feat: add beta sequence fi
Shallow cloneとは Gitには、shallow cloneという便利な機能があります。Shallow cloneを行うことで、最新のコミット履歴のみを取得する代わりに高速にcloneを行うことができます。 古いコミット履歴を取得しないという特性から、これは長い歴史をもつGitリポジトリに対して特に効果があります。 例: ruby/rubyをcloneする例 $ git clone --depth 1 https://github.com/ruby/ruby Cloning into 'ruby'... remote: Enumerating objects: 9894, done. remote: Counting objects: 100% (9894/9894), done. remote: Compressing objects: 100% (8679/8679), do
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
git hyper-blame is like git blame but it can ignore or "look through" a given set of commits, to find the real culprit. This is useful if you have a commit that makes sweeping changes that are unlikely to be what you are looking for in a blame, such as mass reformatting or renaming. By adding these commits to the hyper-blame ignore list, git hyper-blame will look past these commits to find the pre
米Microsoftは2月3日、Gitリポジトリのファイルシステムを仮想化する「Git Virtual File System（GVFS）」を公開した。リポジトリのファイルシステムを仮想化することで、チェックアウトなどの操作を軽快に行うことができるという。 Git Virtual File System（GVFS）はリポジトリのファイルシステムを仮想化し、必要に応じてオブジェクトをダウンロードすることで、リポジトリ内の全コンテンツをダウンロードすることなしにGitを利用できるというもの。すべてのファイルはローカルにあるように操作でき、大容量のリポジトリでもclone、checkout、statusなどの操作を数秒から数十秒で行えると報告している。 Microsoftによると、社内でGitを利用する開発者は多いが、コード行の多いリポジトリを持つチームがいくつかあり、Gitクライアントの使い勝
この記事は feedforce advent calendar 2016 18日目の記事です。 昨日は tsub の ぼくの情報収集方法 でした！この記事を読んで私も早速 のぼりーさんのクラウドインフラPodcast を購読しました！ こんにちは、未だに洗濯機を買ってないことを社内の人達に心配されている mizukmb です。私もコインランドリー生活には限界を感じているので、そろそろ買おうと思います。 さて、今回は私流の Git/GitHub 活用術についてお話しようと思います。 HHKB にテプラを貼った話はまた今度にしようと思います。 自己紹介 @mizukmb 2016年 新卒入社 Webエンジニア ボドゲ部 音ゲー部（自称） 1. Git: masterブランチは削除する Git, GitHub を使い始めてよくあるのが 誤って master ブランチで作業して push してしま
Gitでブランチ(コミット)間の違いを表示するgit diffコマンドに存在するダブルドット(..)記法とトリプルドット(...)記法の違いについて、Stackoverflowの分かりやすい回答。 「git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは？」という質問へのMark Longair氏の回答 git diffコマンドは通常(「通常」というのは、例えばマージコンフリクトを解消する際などには3ウェイマージを表示することがあるため)、コミットグラフにおける完全な2つのポイント間のツリーの状態の違いを表示します。git diffでの..と...の表記は、以下の意味になります。 言い換えると、git diff foo..barはgit diff foo barと完全に同じです。どちらも2つのブランチfooとbarの最新の変更同士の違いを表示します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
