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コミットを元コ
Oh Shit, Git!?!
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
Git Undo
Tell me if you recognize this scenario: you’re in the middle of rewriting your local commits when you suddenly realize that you have gone too far and, after one too many rebases, you are left with a history that looks nothing like the way you wanted. No? Well, I certainly do. And when that happens, I wish I could just CTRL+Z my way back to where I started. Of course, it’s never that simple — not e
複数のgitリポジトリを履歴を残したまま統合する - kitak blog
引き継いだプロジェクトが、foo_pc, foo_sp, foo_commonみたいなかんじでリポジトリが分かれていて、同じ機能の開発やっているのにそれぞれにPullReqだしたり、リリースノートを書いたりするのがしんどいので、統合した。以下に統合した時の手順をまとめておく。 まず、新しくリポジトリを用意して、以下のように統合したいリポジトリ毎にディレクトリを作成して(.gitkeepとか用意して)、コミットする。 foo ├── foo_common ├── foo_pc └── foo_sp 次のようなスクリプトを実行する。git 2.9 から無関係なヒストリもってるブランチ同士をマージするときは --allow-unrelated-histories つけないとエラーになるのがハマりどころ。 for repo in foo_pc foo_sp foo_common; do git r
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
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でよくある、やってしまった！を取り消す方法を紹介します。 gitを使っていると、「ヤバイ・・間違えてcommitしてしまった」「消しちゃいけないものをgit reset --hardしちゃった」とか色々なやばいがあります。 そのヤバイを取り消す便利な方法を備忘録として記録しておきます。 【case1】 commit内容が間違っていた。取り消して再度commitしたい 直前のcommitだけであれば、git commit --amendを使えば解決出来ます。 ファイルに修正を加えて、commit 間違っていた事に気づいたので、更に修正を加えた git addしてgit commit --amend これでOKです。 【case2】過去のcommitが誤っていた。commit自体を取り消したい よくあるようなパターン(私はやってしましますｗ)として、ローカルで作業してる時、 何か修正を加
How to undo (almost) anything with Git
Open SourceProductHow to undo (almost) anything with GitOne of the most useful features of any version control system is the ability to "undo" your mistakes. In Git, "undo" can mean many slightly different things. One of the most useful features of any version control system is the ability to “undo” your mistakes. In Git, “undo” can mean many slightly different things. When you make a new commit,
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
Gitでブランチを統合する方法 — 裏紙
#!/bin/sh rm -fr .git *.txt .gitignore git init echo init.sh>.gitignore && git add .gitignore && git commit -m "Initial Commit" echo b>b.txt && git add b.txt && git commit -m "master 1" git branch other echo c>c.txt && git add c.txt && git commit -m "master 2" echo d>d.txt && git add d.txt && git commit -m "master 3" git checkout other echo e>e.txt && git add e.txt && git commit -m "other 1" echo
gitでありがちな問題の解決方法まとめ - Qiita
Git Advent Calendar / Jun. 最終日(30日目)の記事です．29日目は「いざという時のためのgit reflog」でした． Git Advent Calendar最後なので，git操作でやりがちなミスからどう回復するかをまとめます．他にもあればコメントもらえるとマージしていきます． ブランチを切り忘れてmasterでコミットしてしまった その時点でブランチを切る&reset --hardで間違ったコミットたちをmasterから消す $ git checkout -b new-branch # masterの最新コミットを消す $ git checkout master && git reset --hard HEAD~
gitでマージ作業を中止して元の状態に戻す | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 例えば新機能Xを実装する場合、 X用のトピックブランチを作成し、実装を進めて、完成したら統合ブランチへマージする というのが普通です。 具体的にコマンド例を挙げると以下のようなものになります: $ git checkout -b topic-x master Switched to a new branch 'topic-x' $ $EDITOR $ git add foo.x bar.x baz.x $ git commit -m 'Implement X' [topic-x 0000001] Implement X 3 files changed, 8 insertions(+), 5 deletions(-) $ $EDITOR $ git add qux.x $ git commit -m 'Fix
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【git revert】複数コミットをまとめてrevertする【使い方】
GitHub - RomuloOliveira/commit-messages-guide: A guide to understand the importance of commit messages and how to write them well
git rebase --onto を使って、まずは自分だけ幸せになる - Qiita
gitリポジトリの複製 - Qiita
Gitでやらかした時に使える19個の奥義 - Qiita
submoduleの削除 - Qiita
