【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
【Git助っ人】.gitignoreに追加したのに、いつまで経っても出てくるアイツをgitの世から消し去る方法 - Qiita
【Git助っ人】.gitignoreに追加したのに、いつまで経っても出てくるアイツをgitの世から消し去る方法Git.gitignore gitってたまに難しい。毎日使っていればpullだのpushは既に親友同然、statusあたりは頼れる兄貴感覚。しかしちょっとイレギュラーなことを行おうとした場合、急にやつはつっかかってきたりする。やめて欲しい。 今回はタイトルにもある通り、一度インデックスにあげてしまったファイルを、.gitignoreに後から追加した場合に、なんか思った通りにいかない時の話。 事象 一度インデックスに挙げたり(要はgit add済)、コミットしたファイル(git commit済み)を、あとから.gitignoreに追加した時に、なかなか追跡対象から外れないことがある。 パスも間違っていないのになぜだーと叫ぶ私。 相も変わらずしれっと追跡対象にファイルを提示し続けるgi
【Git】「.git」の中をGitに管理させてみた - Qiita
はじめに Git Advent Calendar 2023 3日目の投稿です。よろしくおねがいします。 前々回、前回を通じて以下のコマンドが使えるようになったと思います。 git init git add git commit git branch git checkout git merge 内部でどんな動きがされてるか気になったので、今回は↑のコマンドを実行した時に.gitフォルダの中がどのように変化するか観察したいと思います。 やること 下の感じで進めていきます。 リポジトリ(A)を作成 ⬇ リポジトリ(A)の.git内でgit initして.gitを管理するリポジトリ(B)を作成 ⬇ リポジトリ(A)の方でGitのコマンドをいろいろ打ってリポジトリ(B)で差分を観察 Gitリポジトリを2つ使っているので、切り替えがわかりにくい箇所があると思いますがご容赦ください 準備 「git/s
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
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 statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38 Git 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 Y
個人的「便利だな」と思ったGitコマンド4選 - Qiita
存在を知った時や使ってみた時に「これけっこう便利だな」と思ったGitコマンド4つをまとめました。 git fetch -p -pを付けることで、削除されたリモートブランチのリモート追跡参照が削除されるようになります。 例えばリモートリポジトリでbranchAが削除されると、git fetch -pによりローカルリポジトリ上のorigin/branchAが削除されます。 ※ git fetch --pruneも同様です ※ git pull -p/--pruneでプルする際に行われるフェッチにも適用できます git log --oneline コミットハッシュが短縮され、コミットログが1行で表示されるようになります。 ※ git log --abbrev-commit --pretty=onelineも同様です 表示例: git logの場合 commit cmhash2commithash
GitLabの「1年放置された無料アカウントのプロジェクトを削除する計画」がすっぱ抜かれて炎上し即中止へ
2022年8月4日に、「GitリポジトリホスティングサービスのGitLabが、無料メンバーシップのユーザーが所有する1年間アクティブでないプロジェクトを自動的に削除することを計画している」と報じられ、インターネット上で反対する声が相次ぎました。これを受けて、GitLabは翌5日に長期的にアクティブではないプロジェクトを保存する方針を発表しました。 GitLab plans to delete dormant projects from free accounts • The Register https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/ GitLab U-turns on deleting dormant projects after backlash • The Register https://
本の原稿のバージョン管理を始めて20年たちました - golden-luckyの日記
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ
git add の対話モード
すると、対話モードが開始されます。対話モードでは、git statusと似た「どのファイルがステージに追加されているか・されていないか」といった情報と、この対話モードで実行できるコマンドの一覧が表示されています。 ❯ git add -i staged unstaged path 1: unchanged +4/-0 Cargo.lock 2: +1/-0 nothing Cargo.toml *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> status は git status とほぼ同等の目的を達成できますが、ステージした変更が左側、ステージしていない変更が右側に表示されます。直感的ですね。 update は、実行後ファイ
Gitのおすすめエイリアス5選 - 詩と創作・思索のひろば
緊急新人エンジニア応援企画！ ということで自分が 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
GitHubがgit://を無効にした件
TL;DRGitHubからgitプロトコル(git://github.comで始まるURL)でgit cloneする設定になっている人が居たらSSHプロトコル(git@github.comで始まるURL)を使うように設定変更しましょう wez/weztermという端末エミュレータを知って、使ってみようかと思い、ドキュメントに従ってbrew tapしたときのことでした。次の様なエラーが発生して、tapできません。 $ brew tap wez/wezterm ==> Tapping wez/wezterm Cloning into '/opt/homebrew/Library/Taps/wez/homebrew-wezterm'... fatal: remote error: The unauthenticated git protocol on port 9418 is no longer
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）について調査を実施し、対応
コンフリクトの解決を記録して再適用する git rerere - Qiita
はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所
いいコミットメッセージの共通点と書き方〜便利なテンプレートやチーム開発時のお作法まで詳しく解説〜 | PrAhaENGINEERLAB
Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...
Gitのコミット日時を修正する方法 - zzzmisa's blog
忘れがちなのでメモです。 直前のコミット日時を修正現状のコミット日時を確認します。 $ git log --pretty=fuller commit 62c6282c9b6a3f20659559a5d975dc16a33cb7cd (HEAD -> master) Author: zzzmisa <__@mail.com> AuthorDate: Sat Sep 21 14:04:18 2019 Commit: zzzmisa <__@mail.com> CommitDate: Sat Sep 21 14:04:18 2019 ... コミット時間を 15:00 へ修正することにします。 まずは、AuthorDate を修正します。 $ git commit --amend --date="Sat Sep 21 15:00:00 2019 +0900" エディタが立ち上がるので保存して終了
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Git for Windows」のシェルが「bash 4.4」から「bash 5.1」へ ～Vista対応も終了／シェルスクリプトの互換性問題に注意
GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技
