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 commit --fixupを使いましょう - Don't Repeat Yourself
発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ
Git ブランチの表現も Mermaid がよい感じに表示してくれました
Zenn や GitHub の Markdown から利用できる Mermaid には「Git ブランチを表現する」機能があります。 その機能を利用してみたところよい感じだったので、記述方法やカスタマイズについてなどを記事にしてみます。 Git ブランチを表現するとは？ ドキュメントでブランチの説明などを読んでいると下記のような図(グラフ)を見かけるかと思います。 図 1-1 AA によるブランチのグラフ A---B---C---D develop \ E---F---G topicA \ H---I---J topicB Mermaid の Gitgraph Diagrams を利用することにより、このような感じで表示できるようになります。 図 1-2 Mermaid によるブランチのグラフ 基本的な使い方 Mermaid 用コードブロックの先頭で gitGraph を記述し、Git の
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
今日Gitにコミットしたコードの行数を数えるエイリアス
今日1日、自分がGitにコミットしたコードの行数を数えるaliasを紹介します。 ~/.gitconfigを開き、以下のエイリアスを追加します。 エイリアス [alias] today-numstat = !"f(){ \ git log \ --numstat \ --branches \ --no-merges \ --since=midnight \ --author=\"$(git config user.name)\" \ | awk 'NF==3 {a+=$1; d+=$2} END { \ printf(\"%d (\\x1b[32m+%d\\033[m, \\x1b[31m-%d\\033[m)\\n\", a+d, a, d)\ }'; \ };f" 見やすさのために複数行に分けていますが、1行にしたり適当なサイズでオプションを連結しても問題ありません。 今日1日の作業を
【zsh】絶対やるべき！ターミナルでgitのブランチ名を表示&補完【git-prompt / git-completion】 - Qiita
【zsh】絶対やるべき！ターミナルでgitのブランチ名を表示&補完【git-prompt / git-completion】ZshGitTerminal この記事でできること ターミナルのプロンプトにgitのブランチ名を常に表示させる（git-prompt） gitコマンドをTab補完できるようにする（git-completion） はじめに もともとbashを使っていた時は次の記事を参考に同様の設定をしていました 「Git補完をしらない」「git statusを1日100回は使う」そんなあなたに朗報【git-completionとgit-prompt】 しかし、macOSがCatalinaにアップデートされてからはzshがターミナルのデフォルトとなり、zshへと移行が進んでいると思います 自分も新しいPCでいいかげんzshを使い始めた&意外と情報がまとまっていなくて手間取ったため、今更感
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
Git - 歴史の書き換え
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Git 業務で役に立ったコマンド達 - stone's throw
業務でGitを使うようになって完全に理解した*1ので、役に立ったコマンド達をここに記しておく。 Git編 その前に Gitコマンドは割と雰囲気で使っていたが、特に$ git checkout --helpと$ git reset --helpを見たら思ってたのと違う概念だったので先におさらいしておく。 checkout $ git checkout branchで特定のブランチに移動する、あるいは特定のブランチの状態をワーキングツリーに再現する。 前者の概念はみんな知っているけど、後者の概念は最初触った時にはあまり意識できていなかった。 特定のブランチの状態をワーキングツリーに再現するので、現在のブランチで何らかの変更をしてしまっても$ git checkout branchnameあるいは$ git checkout .でそのブランチの最新の状態（つまり、変更を行う前）に戻すことができる
GitHubの使い方を学ぶ「GitHub Skills」が無料公開。GitHubを実際に操作してMarkdown、Pages、Pull Requests、マージのコンフリクト解消などを体験
GitHubの使い方を学ぶ「GitHub Skills」が無料公開。GitHubを実際に操作してMarkdown、Pages、Pull Requests、マージのコンフリクト解消などを体験 GitHubは、実際にGitHubを操作しながらGitHubの使い方を学べる無料の教材「GitHub Skills」を公開しました。 Expand all you know about the GitHub platform. We're introducing GitHub Skills, a new learning experience integrated into the GitHub UI, backed by GitHub Actions. Try it out today! https://t.co/XnqCYdVqBL — GitHub (@github) June 6, 2022 G
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 から入って
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）について調査を実施し、対応
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitでstashが面倒なあなたにautostash
Gitでコミット数、変更行数、ファイル数を取得する色々
Git の最新アップデートから考える開発手法の潮流
GitHub - The-Japan-DataScientist-Society/100knocks-preprocess: データサイエンス100本ノック（構造化データ加工編）
git worktreeを使ってみる - Qiita
GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技
