緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb

個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-

一度プッシュしたtagは、名前変更・削除してはならない プッシュしたtag名を削除・変更してはいけない理由は、git tagのmanコマンドの中で説明されている。 manコマンドの内容は、コマンドの使い方を淡々と説明している印象があり、今まであまり読んでこなかった。 しかしgit tagのmanコマンドではとても人間味のある文章が書かれていた。 感情部分だけ要約すると、 「tag名を変更するのは馬鹿げている！！絶対にするなよ！！ それでもやりたいって？じゃあこうやれ！馬鹿げたやり方だけどな！！ それは面倒だって？やるならこれしかないんだよ！（怒）」 という筆者の熱い思いが文章で綴られている。 それでは見ていこう。 manコマンドをみてみる 下記コマンドで該当の記述を読むことが出来る web上で見たい場合はこちらでも。 原文 該当の記述はこちら On Re-tagging What shou

本題のチートシートはこちら PNG SVG https://d.kuku.lu/6b5cc7b0a9 から DL できます 作った理由 git って他人に概念を説明するのって難しいし、自身も何度も反復させないと定着しなかったなあという感覚を持っていたので作ってみました 所感 こちらの Git チートシートですが、この中に盛り込めなかった内容で 第2段 を作成しようか考え中です 皆さまのオススメの便利コマンドとか、この内容は必須だろ！的なものがあればをご教示いただければ幸いです もし誤りがあれば、作者の心が折れない程度にご指摘いただければ幸いです あとがき ここまで反響を頂けるとは思っておらず、嬉しい限りです・・・本当にありがとうございます・・・！！ また、図は全て自作です。図における言語は英語、説明は日本語、と言う形に統一しました。（吹き出し部分だけ日本語になっていたのでこちらは修正しまし

コミットの連なりと.gitの中身について ＠miyaoka 社内勉強会向けに作った資料

2018年3月27日にSupporterZ CoLabで行われたgit勉強会の資料です。

2019年7月にGitHubにマージしたブランチが自動削除される機能が入ったためこの記事は内容の非推奨です。 Automatically delete head branches of pull requests - GitHub Changelog ブランチの自動的削除を管理する - GitHub Docs 以下は古い記述 前置き マージ済のブランチは基本的に消しても問題ないので、GitHub上には進行中のブランチだけがあるきれいな状態に保ちたいところ。 PRをマージした後にブランチを消すボタンが出るんですが、チームで開発してるとどうしても消し忘れる人が1人はいるので 1CircleCIで定期的に消すようにしました 前提 GitHub CircleCI 2.0 準備 GitHubにpushするための権限が必要なので「Settings -> Checkout SSH keys」でuser

なぜ作ったか ターミナルでの git 操作に tig を愛用してます。素晴らしいツールなんですが、マージが入り組んでくるとコミットグラフの線が途切れてしまったり、結構見るのがしんどくなります。tig と併用する目的で、入り組んだマージ履歴を見やすく表示可能な、テキストベースのコミットグラフ表示ツールを探していました。 そんな時、 Jan Engelhardt 氏が作った git-forest を見つけました。入り組んだマージ履歴も見やすく表示できるコミットグラフはいい感じなんですが、ハッシュ・日付・作成者・ブランチ名などの表示方式がイマイチに感じ、コードをいじっているうちに元とは結構違う見た目になりました。これを周囲の人にも使ってもらったところ「見やすい」と評判が良く、せっかくなので公開することにしました。 サンプル（スクリーンショット） というわけで、さっそくサンプルをご覧ください。まず

git commit --fixup が何かについてはgit commit --fixup とは何か - 詩と創作・思索のひろばを読んでもらうとして、 fixup を適用したいコミットをいちいち git log で調べるのが面倒なのでインタラクティブに選べるようにした。 以下のスクリプトをパスの通ったディレクトリに置くと git fixup が使えるようになる。適当な変更を git add して git fixup を実行すると、その変更を fixup として適用したいコミットを peco や fzf で選べる。 # !/bin/bash FILTER=${FILTER:-peco} MAX_LOG_COUNT=${MAX_LOG_COUNT:-30} if git diff --cached --quiet; then commits="No staged changes. Use gi

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩

断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま

前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある 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 する際には

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの？ と思ったことはありませんか？ 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

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 から入って

タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中に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を対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま

zshでGitのステータス情報をプロンプトに表示するにはvcs_infoを使う方法が一般的ですが、vcs_infoで得られる情報には限りがあります。そこで、git statusを使ってプロンプトを表示する方法を調べてみました。なお、OS XのGit 2.3.2で確認しています。 git statusで得られる情報 git status --porcelain --branch を実行するとブランチ、ワーキングツリー、インデックスの状態が得られます。--porcelainを付けることで機械処理に適したフォーマットが得られます。このコマンドの実行結果は下記の2つの部分で構成されます。 ローカルブランチの状態（1行目） ローカルブランチの状態 表示 リモートブランチと同期している ## master...origin/master リモートブランチより古い ## master...origin/

git config --add receive.denyCurrentBranch ignoreをやるとどう危険なのか。一言で言うと「ある人が行った実装を、別の人が無意識に削除してコミットする」という事態を引き起こす。これが危険じゃなくて何なんだ。 まずローカルで実験用のリポジトリを作ってみよう。fという名前のリポジトリを作って、READMEをおく。今は中身は空っぽだ。 $ git init f Initialized empty Git repository in /Users/nishio/tmp//f/.git/ $ cd f f$ touch README f$ git add README f$ git commit -m "initial" [master (root-commit) ce6d7d5] initial 0 files changed, 0 insertions