【Git】新規ローカルブランチ作成時に自動でFirst Commitを行う for Four Keys
この記事は GMOアドマーケティング Advent Calendar 2023 5日目の記事です。 皆さん、お久しぶりです。GMOアドマーケティングのGood!Apps開発担当のharuです。 最近、弊社の開発部ではFour Keysを導入し、開発者体験や生産性の向上に注力しています。今回は、Four Keysの計測に必要な処理の一部を自動化しましたので、その詳細についてお話しできればと思います。 Four Keysとは まず、Four Keysについて簡単に説明します。 Four Keysは、GoogleのDevOps Research and Assessmentチームが提唱した、ソフトウェア開発チームのパフォーマンスを評価するためのフレームワークです。このフレームワークは以下の4つの指標で構成されています。 デプロイの頻度: 本番環境へのリリースの頻度を示します。頻繁なリリースは、ア
fzfを使ってgit stashを便利に扱えるように - $shibayu36->blog;
git stashをもっと便利に扱いたいと思い、fzfを使って使いやすくしてみた。以下のURLに載っているものを参考にして自分にとって使いやすいように改変した。 fzfでGUI選択したファイルをgit stashするシェルスクリプト git-stash-explore できたこと 今の変更ファイルをfzfを使って選択して、選択したものだけをstash (git-stash-select) stash一覧の中から中身をpreviewしながら選び、apply or deleteする (git-stashes) 現在の変更ファイルから一部を選んでgit stashするコマンド fzfでGUI選択したファイルをgit stashするシェルスクリプト を参考に、git-stash-selectというコマンドを作った。 #!/usr/bin/env bash # Get the root direct
git statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main You
git-pr-releaseとGitHub Actionsでワンクリックデプロイを実現する | おそらくはそれさえも平凡な日々
突然ですが、git-pr-releaseのなんちゃってコラボレーターである私が僭越ながら、その王道の使い方を皆様に伝授していきます。何番煎じかの記事ではありますが、現代の、特にGitHub Actions出現以降の使い方をまとめたいというのが動機です。 https://github.com/x-motemen/git-pr-release https://rubygems.org/gems/git-pr-release git-pr-releaseはGitHubを業務開発で利用している場合に便利なツールで、デフォルトブランチにマージされたpull requestをリリース項目として一覧し、それをpull request化してくれるものです。これにより以下のことが実現できます。 リリース項目が一覧されることによるリリース内容の明確化 マージボタンによる明快なワンクリックデプロイの実現 pul
git commit --fixup が便利 - Qiita
始めに 私は最近エンジニアに復帰し、現場で便利に思ったことを今後記事にできたらと思っています。 そして1発目は、gitのオプションについて記事を書いてみようと思います。 --fixup はどんな時に使えるの？ Pull Requestなどで、軽微な指摘や後から気付いた修正など、本来の機能のコミットとは別に修正コミットを残すのは少し嫌な時がありますよね。 コミットが一つ手前であれば、直前のコミットを修正してくれる git commit --amendなどで対応できますが、3つ前のコミットに修正を混ぜ込みたい時などは、少し大変。 そんな時に便利なのが、この git commit --fixupです。 使い方 例えば、下記のコミットの状況で、Fix article pageのコミットに対して、追加の修正をしたいとする。 ❯ git log --oneline 1131338365 (HEAD -
Git-flow とデプロイ - Mitsuyuki.Shiiba
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
[Git] マージ済みのブランチを一括で削除する | DevelopersIO
マージ済みのブランチを一括で削除 gitで管理しているとローカルにブランチがどんどん残っていくものです。毎回消していくのも大変なのでサクッと一括で削除できるコマンドを備忘録的に載せておきます。 $ git checkout master && git branch --merged | grep -v '*' | xargs -I % git branch -d % コマンドを見ての通りなのですが masterブランチに移動する すでにマージされてるブランチだけを抽出して一括で削除する の流れになります。 ですので、マージされていない作業中のブランチが削除されることはないです。 主流のブランチがmasterでなく、developだったりすることもあると思うので、適宜書き換えてください。もし必要そうならmasterブランチに移動後にpullをするコマンドを入れてもいいかもしれません。
![[Git] マージ済みのブランチを一括で削除する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/716851b9cc37f22510ed1b017fc9e8ef3378a43f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F08%2Feyecatch_git.png)
JetBrains系IDEと各種ITSとGitを連携してスマートに作業する - mike-neckのブログ
JetBrainsユーザーグループにて「IntelliJとYouTrack」というタイトルにて発表してきましたが、グダグダな発表をしたのでちゃんとまとめた記事を書きます。 jbugj.connpass.com 要点 JetBrains系IDEでは、標準に付属しているツールを用いることで、スマートに作業ができます。(なお、一部のIDEについてはリポジトリーからインストールしないといけなさそうです(GoglandにはTaskManagementプラグインが付属していないようだった)) Task Management プラグイン ITS(イシュー管理システム)とIDEを連携させてTask と Context を管理できるプラグイン Task - イシュー管理システムのチケットに該当する、作業の単位をあらわす Context - 開いているファイルのカーソルの位置や、プロジェクトツリーの開いている
Vimと日本語編集（2）: 修正前後の原稿の差分を一瞬でチェックする - the code to rock
Vimと日本語編集シリーズ第2回。 前回はこちら。 note103.hateblo.jp けっこうニッチな内容だったと思うが、今回はもう少し使用頻度＆汎用性が高いかもしれない。 前提・状況設定 よくある解決策・その何が問題か 解決策 別解 fugitive.vim / Gdiff diffsplit, VDSplit まとめ 前提・状況設定 複数人で利用・共有するドキュメントがあるとして、それをまず自分が書いたとしよう。 大体内容がまとまったのでデータを他のメンバーに渡し、「気になるところがあったら適当に手を入れといて」なんて言っておいたら、しばらくして修正版が届いたとしよう。 でもパッと見たところ、どこが修正されたのかわからない。 たとえば、これが修正前。*1 そして修正後。 そのようなときに、どうするか。 よくある解決策・その何が問題か 一番容易な選択肢としては、「じっくり見る」。 ま
Gitはじめの一歩
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください！（時々アプデしてます）↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-buRead less
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コミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hello Serverless, Goodbye Git Flow
GitHub CLIで始める快適GitHub生活 - Qiita
便利なGit Tools
make git branch show branches inline (version 2.17.1) - Stack Overflow
Google、「Cloud Source Repositories」正式公開。Gitベースのソースコード管理ツール、5ユーザー、50GBまで無料
部屋とYシャツと私とGitBucketとプラグイン
