【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
Gitのブランチの役割を考える | フューチャー技術ブログ
Gitのブランチ戦略にはいくつかあります。 Gitフロー GitHubフロー GitLabフロー チームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね？ 社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか？ というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名＝役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証の
ChatGPTにgitのリポジトリ渡すと全ソースコード.txtをダウンロードさせてくれるやつ〜〜〜〜（AIに食わせるコード一覧が欲しい時用）
クレデンシャル含むソースコードをChatGPT等のクラウドLLMサービスにアップロードしないでください。 今回のプロンプトはオープンなリポジトリのみを対象としており、シェルスクリプトが実行される環境もChatGPT側のクラウド上のサンドボックス内のみを想定しています。 ローカル環境では以下のシェルスクリプトをそのまま実行せずに、ご自身が作成したシェルスクリプトを利用してください。 以下はソースコードのプロジェクトルートで実行することで、ソースコードのダンプを.txt形式でダンプするシェルスクリプトです。 \`\`\` #!/bin/bash # バイナリファイルかどうかを判定する関数 is_binary_file() { local file="$1" local file_output file_output=$(file "$file") if [[ "$file_output" ==
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣ - Qiita
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣Git 画像略 TL;DR(Too Long; Didn't Read) ~nは単純なコミットの親をたどる(ブランチの分岐がある場合は現在のブランチのみで辿れるコミット) ^nはマージコミット向けで^2は｢そのコミットの2番目の親(取り込んだブランチの前回のコミット)｣ だからHEAD^n(n > 2)は存在しない 2024/06/04追記： OctopusなMergeだと３つ以上のブランチからマージできるので^nも存在する......があまり見かけることはない HEAD^^は｢HEAD^の親｣､HEAD^2は｢HEADのもう一人の親｣みたいな......｡タラちゃんがHEADだと波平がHEAD^^でマスオがHEAD^2です(
Git の一般的な落とし穴を回避します: ベスト プラクティスと回復手順。 | DevelopersIO
Gitは、バージョン管理に強力なツールで、開発者がコード変更を追跡し、プロジェクトで協力し、作業履歴を維持することを可能にします。Gitは複雑なプロジェクトを管理するための堅牢なフレームワークを提供しますが、同時にプラットフォームの初心者にとっては習得の曲線があり、一般的なミスにつながる可能性があります。これらのエラーは、些細な面倒から、プロジェクトのワークフローに重大な混乱をもたらすまでさまざまです。 これらの落とし穴を理解し、回避することは、プロジェクトの整合性と安定性を維持するだけでなく、チームメンバー間の効果的な協力関係を育むためにも不可欠です。このブログでは、Gitを使用する際にユーザーが直面する最も一般的な課題について掘り下げます。メインブランチへの直接コミット、ブランチの非効率的な使用、不適切なコミットの処理、マージコンフリクトの解決など、さまざまな問題を探ります。 一般的な
Git不慣れ勢を束ねて安全なチーム開発をするメモ - Qiita
本稿は当初チーム開発時のメンバー向けにまとめたものです。 ある程度、端折っていた背景などを記載しました。 git初心者同士でのチーム開発において、git操作を詳しく知らないメンバーも含め安全に行う必要がありました。しかし、開発期間はごくわずか...この状況を回避するために、下記の対応をとりました。 Gitコマンドの基礎的な内容を理解する（私） 各種操作をGUI上で完結させる拡張機能を色々と導入する シンプルな開発フロー(Github flow)を採用し、コマンド実行に相当する操作を限定する 各操作をGUI上での操作に置き換え、チームメンバーに教える 本稿はその際の、コマンドやGUI操作に関するメモをまとめたものになります。 こういった取り組みのおかげか、チームの開発をすんなりフローに乗せることができました。 ■ 前提条件 対象とする動き Github flowを回すうえで、 cloneする
中級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
rebase 教から脱退します - Qiita
rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中にブランチ元の変更があったので、 git rebase からの git push -f origin [ブランチ名] やったらレビュアーのコメントが吹き飛びました。 いやー、めっちゃ怒られたよね💦 原因 「レビュー中」という状況がまずかった。 コードを共有し
2024年Gitワークフロー再考 | フューチャー技術ブログ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
Popular git config options
Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options to set? Right now
VS Code + GitHub Copilot 環境でも git commit しちゃうんだな、これが
VS Code でコミットするときに GitHub Copilot を使っていると コミットメッセージを生成してくれたりします。 図 1 コミットメッセージを Copilot で生成 英語苦手な自分からすると「マジうれしいんですけど」という感じなのですが、コミットメッセージはできればエディターで記述したいと考えてしまいます。 そこで今回は「コミットメッセージをエディターで編集する利便性」を維持しつつ、「GitHub Copilot による生成機能もできるだけ利用しよう」という内容のメモになります。 VS Code のエディターでコミットメッセージを記述するとは VS Code でコミットメッセージを記述する方法としてはソース管理タブの利用が一般的かと思われます。 図 1-1 ソース管理タブのフィールドから普通に入力 一方で上記とは別に、コミット用のコマンドを実行しエディターの中で記述する方
Inside .git
Hello! I posted a comic on Mastodon this week about what’s in the .git directory and someone requested a text version, so here it is. I added some extra notes too. First, here’s the image. It’s a ~15 word explanation of each part of your .git directory. You can git clone https://github.com/jvns/inside-git if you want to run all these examples yourself. Here’s a table of contents: HEAD: .git/head b
Merge vs. Rebase vs. Squash
merge_vs_rebase_vs_squash.md I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again. I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who sa
混乱を引き起こしがちなGitの用語まとめ
分散型バージョン管理システムのGitは2005年の登場以降シェアを伸ばし続け、2022年の調査では約94％のユーザーに利用されるほど一般的なツールとなっています。Gitにはさまざまな機能が搭載されていますが、その中で特に混乱を引き起こしがちな用語について、Gitを15年近く使用してきたというジュリア・エヴァンスさんが解説しています。 Confusing git terminology https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ ◆HEADと「heads」 HEADは現在チェックアウト中のブランチやコミットを指しており、「.git/HEAD」に保存されています。一方「.git/refs/heads」に保存されているのはブランチで、「heads」は「branches」と読み替えればOKとのこと。 ◆detached HE
『GitUI』を使ってターミナルからでも直感的なGit操作を｜NAVITIME_Tech
こんにちは、みみぞうです。 ナビタイムジャパンで『システムや開発環境、チームの改善』を担当しています。 今回はターミナルで動くGitクライアントツール『GitUI』を紹介します。 本稿は以下のいずれかに当てはまるような方をターゲットにしています。 ターミナルで動くGitクライアントツールを探している方 NeovimからシームレスにGitの操作をしたい方 Windowsで使えるGitクライアントツール探しに困っている方 ℹ️ Neovimは、Vimをベース拡張性を考慮してモダンな技術で作られたプロダクトです。 GitUIとは『GitUI』はターミナル上でもGUIのように快適なGit体験を提供するOSSのツールです。 GitUI provides you with the comfort of a git GUI but right in your terminal extrawurst/gi
Gitのコミットメッセージは適当に書いてる - Mitsuyuki.Shiiba
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitでstashが面倒なあなたにautostash
なぜファイルの末尾に改行を入れたほうが良いのか - Qiita
Git入門
