GitHub Actions のベストプラクティス
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする
yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい…という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。
set -eのもとで特定のコマンドの終了ステータスを変数に入れるシェルスクリプトのスニペット - Islands in the byte stream
課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 set -e # グローバルな状態を変える操作を行う git merge --no-ff --no-commit $main_branch || true # 結果をチェックしてexit codeを変数に入れる git diff --cached --exit-code --quiet ; code=$? # グローバルな状態をもとに戻す git merge --abort # 上位プロセスに結果を渡す exit $code スクリプト全体には set -e （コマンドが失敗するとシェルスクリプトが即座に終了する）を効
GitHub Issuesを個人用のTodo管理アプリとして使っている
個人的なタスク管理ツールとしてGitHub Issueを使うようにしてその仕組みを色々と作っているので、そのアーキテクチャについてのメモ書きです。 後述しますが、GitHubをベースとすることでプログラムでの拡張性が高いというのが特徴です。 セットアップが色々と必要になるためぱっと再現しやすい感じではなかったり一部未公開になってます。 需要があったらオープンソースとして公開できるように整えます。 GitHub Issuesとタスク管理ツールでの課題 自分の中で、タスク管理ツールとGitHub Issuesを両方使う場合に次の課題がありました。 自分のタスクの半分以上はGitHubに何かしら紐づく情報(オープンソース、ブログ、仕事)であったため、GitHub Issueとの二重管理感がある GitHub上で複数のリポジトリのタスクを管理するのが難しい 1つ目は、タスク管理ツールを使っても結局
めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
GitHubで自動生成コードをDiffに表示しない方法 - Qiita
結論 ここに書いてある 注意事項 だいぶ懐かしい記事ですが…突然、「Diffに表示しないなんてGitHubの価値を損なうものだから記事を非公開にするべきだ」というご指摘をいただいたので、念のため追記。 Diffに表示しない、ってことは当然PRにも見えません。 レビューされない怪しいコードが紛れ込むリスクを抱えることになります。 せいぜい自動生成分だけを非表示にして、CIの中で再生成、差分が出ないチェックを入れるなど、ガードの手は考えておいたほうが良いでしょうね。はい。ご利用は計画的に。 背景 mockeryだったり、swagger-codegenだったり、go-bindataだったり… GitHub上に自動生成されたコードを載せている場合、PRやcommitの詳細画面でDiffが邪魔になることがあります。 .gitignoreでそもそも自動生成コードをリポジトリに載せない generate
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
GitベースのコードリーディングTips - クックパッド開発者ブログ
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
地震や火事など緊急時に使うgit-fireのススメ - Qiita
$ git-fire "やばい" Switched to a new branch 'fire-master-[メールアドレス]-1444060029' [fire-master-[メールアドレス]-1444060029 bc88227] @a 1 file changed, 13 insertions(+) create mode 100644 index.html Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 384 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gith
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
インデントコミットで真犯人がわからなくなった場合の git blame
config_param :queued_chunk_flush_interval, :time, :default => 1 を追加したコミットがどれかを探したいとします。 しかし、git blame を見るとこんなかんじに、インデントコミットによってほぼ全ての履歴が上塗りされていてどれだかわからない、みたいな状況にどうやって真犯人を探そうかという話です。 1. git blame -w を使う インデントコミットを無視したいだけであれば git blame の -w オプションが使える。-w は比較の際に whitespace を無視してくれるオプション。git diff にもあるよね。 $ git blame -w lib/fluent/output.rb ... (省略) 14d01c71 (Masahiro Nakagawa 2013-03-27 03:56:51 +0900 1
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git diffを見やすくする git diff --color-words で差分を小さく表示する 通常のgit diffは行単位なので、例えば変数名を一括変更した場合見づらいです。 --color-wordsを指定すると記号やスペースで区切られた単語単位でのdiffを表示できます。gitの設定は不要です。 より細かな表示のカスタマイズも可能です。man git-diffで--word-diffを検索してみてください。 ※ただし、変更が複雑な場合は、通常のgit diffのほうが見やすいこともあります。 .gitattributesを設置してもっと小さく表示する .gitattributesファイルを設置することで、言語文法に基づいて変数名、関数名といった単位でdiffを表示できます ファイル設置後にgit diff --color-wordsとすると、下記のようにさらに小さく表示できま
Xcodeのプロジェクトファイル（pbxproj）がコンフリクトしまくるのをなんとかしたい！ | TOKOROM BLOG
2014/02/09 追記 コメントのところでやり取りしているようにmergepbxの作者さんから連絡があって、この記事で書いた問題が修正されました！ 今現在は merge=mergepbx がいい感じになってきているのでそっちがオススメです。 複数人でプログラミングしているとpbxprojがやたらとコンフリクトする 例えば、 Aさんが AALabel.m をプロジェクトに追加して Bさんが BBLabel.m をプロジェクトに追加して とただそれだけなのにマージのときにコンフリクトするpbxprojさん。。。 ただそれぞれファイルを追加だけのことでコンフリクトするなんて… どうにかならんもんかいとTwitterでつぶやいたところ、 @azu_re さんから有り難い教えが！ @tokorom gitはファイル別にマージ方法を指定できるので、mergepbxみたいなのをpbxprojのマージ
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入門書には載ってない Git & GitHub Tips
