「複数人で同じブランチ使って開発するな」が正しい
pullの正体がfetch+mergeって意外と意識しないよね。rebase派の気持ちも分かる
初心者は、どちらかといえばコンフリクト時の対処が分からないと思うやつ。
git log --no-mergesじゃダメ?Linux Kernelもgitも マージコミットを明示的に残すmerge派だった記憶が
同じファイルや処理を弄ってる時に困る
mergeではなくrebaseする意味。ローカルで作ったmerge commitが最終的にmainに取り込まれて残るのが邪魔なので
生成AIでる前からGitわからない人沢山いた。それが理由でチームの足引っ張り現場から離れた人もそれなりに見てきた…
最近はClaude Codeに「最新の取り込んで」と指示するだけで久しくgit操作してない
歴史修正主義者との戦いだ
feature branch で git pull origin main した場合の話をしている？？
あぁなんだ。featureブランチからgit pull mainするなってことね。そりゃそう。通常の使い方ではないから。 複数人で同じブランチ使わないのが一番で、できなきゃrebase --ontoだけど、これもブランチ複雑だと地獄が待ってたり
「瑣末」なこととしか思わん。rebase派もmerge派も等しくsquashされればよろしい
Gitなんて使いにくいモンが業界標準面してまかり通ってるのがそもそもの問題
わい、全部 AI まかせ。ベストプラクティスっぽいものが得られたときは、メモリに書いてもらってる
記事を読んだ時の違和感が、ブコメを読んでスッキリした。
mainの変更を取り込みたい時はmainでpullしてその上にrebaseしてるな。
誰もがコミットグラフを綺麗にしようという道を通るが、適当にやって必要になってからAIにログ調べてもらった方が早い
ブランチに取り込むなんてしないよね。。
もう少ししたらもっとエージェントフレンドリーな管理システムが生えてくる気がする
新しい宗教が誕生している。ならば戦争だ。
C言語的というか、簡単に自分の足を撃てる作りだよな。標準的なルールを強要する軽い枠組みがあるべきなのかもしれない。
gitについて
local に差分ある状態で pull はしないよ。
featureブランチを複数人で使わない。featureブランチのマージはPull Request経由。PRのマージはスカッシュマージ。これだけでrebaseを使う場面なくなる。履歴はPR単位で見れる。rebaseを使わないとダメな時点で開発体制がおかしい
GitHub Flow(PR以外でmainマージ無し運用)ならsquash merge すればいいんじゃないの。PR 用ブランチはごちゃって良い(fix: lintとかね)。squash なら、main は基本的に CI が通ったコミットが並ぶから、ロールバックの目安にしやすい。
pullの挙動は好きじゃないので使ってない
コミットログ綺麗にするのは費用対効果が悪いし自己満足だと思う。それこそAIの使い所かと。
『rebase の本質：「履歴を書き換える」』 いまだにrebaseを嫌いな理由
かつてはコミットログ整理派とコミット積む派がいたけど、今って過去の履歴もAI聴けば差分わかるし、どのコミットでどの状態だったか即座にわかるよ。かなり良いAIの得意技と使い方。人間が管理しなくていい
mainブランチみたいな共有ブランチの場合はrebaseもしない。git reset --hard origin/main のみ。自分だけしか更新しないブランチならrebaseもするけれど、レビュー後ならforce push したくないから、git merge origin/main しかしない
rebaseに時間かけてfeatureブランチ綺麗にするのあんま意味ない気がする。どうせfeatureブランチsquashすればきれいになるし。→ローカルのmainにpullしてそこからマージしてる。
プロジェクトの規模や業界によってベストな運用が違うのでSNSだとあまり話が噛み合わんやつ／個人的にgit関連はClaude Codeに丸投げしてる。あいつは俺の知らんgitコマンドを駆使して万事スマートに解決してくれる良い奴だ
個別のブランチで開発してPRのマージはスカッシュマージがよい
rebaseは極力rebase前のメタデータを残すオプションがあるので積極的に使うことで、履歴の改ざんを減らそう！
チーム開発だけど、pullとmergeでほとんど終わるので、rebaseするような開発ってどんな状況なのかが理解できない。(ほぼ使ったことない)ブランチ作業してて、main更新されたら、branchにmergeで取り込むんじゃないの？
数年単位で同じ話題を繰り返すけどAI以後で変わっていくのかな。
“「merge を理解せず pull すること」”
10年以上git pullしていた困ったことは一度もない。編集履歴ある時pullせんやろ・・
今ってpullをrebaseに設定できなかったっけ、初回pullで聞かれるよね。／あとrebaseはコンフリクトした時地獄だから基本的にやりたくない／マージコミットがノイズって初めて聞いた
git pull --rebase --autostashが標準のpullの動作になって欲しい。が失敗すると何してるかわからなくなるだろうな
git fetchを使うことはほぼ無いな
mainにおいていかれたときに追いつくのにマージするんじゃなくてrebaseしろということか。まあそれはそう。
やべ、普通にpullしてmergeしてた ノイズ発生機してた いい先輩がいたもんだ
これだけ gitなんてまともな機能として使われていないのに、いまだにgit以外使えるものがないの不思議、CVSよりマシとはいえ、git使うようになってから随分と経った気がするんだよな。CVSはすぐSVNとかに進化したのに
“先輩「git pull は使うな。git fetch して git rebase しろ」今ならよくわかります。あくまで「自分のfeatureブランチにmainの変更を取り込むとき、git pullではなくgit fetch + git rebaseを使う」という話”
ちなみにfeatureにmainを取り込むのをback mergeと言う。基本的にはアンチパターン。
mainが綺麗であればやり方は自由. 但しmainに(pull request 経由で)取り込まれるブランチも綺麗でなければならない; Commit log を綺麗にするのは人間が(後から見て)理解するため. AIに全部任せても責任取るのは人間
copilotに聞きながらやっとわかった。featureで`git pull`したってupstreamは？？？ってなってたけど、自分の開発ブランチで`git pull origin main`するなって話だった。なんだよpullするなって。紛らわしいよ時間返してくれ
普段、git を触らず、たまに必要に迫られて、ぐらいな自分にとって助かる記事。ブコメを見ながら、結局、リポジトリを「どう運用するか」は結構、千差万別で、それ故の複雑さ、難しさだよなぁ。
その会社にはその会社のルールがあって、この人の会社ではそうなっているというだけ
Git初心者の頃わからなかった「pullするな」の意味 - Qiita
「複数人で同じブランチ使って開発するな」が正しい
pullの正体がfetch+mergeって意外と意識しないよね。rebase派の気持ちも分かる
初心者は、どちらかといえばコンフリクト時の対処が分からないと思うやつ。
git log --no-mergesじゃダメ?Linux Kernelもgitも マージコミットを明示的に残すmerge派だった記憶が
同じファイルや処理を弄ってる時に困る
mergeではなくrebaseする意味。ローカルで作ったmerge commitが最終的にmainに取り込まれて残るのが邪魔なので
生成AIでる前からGitわからない人沢山いた。それが理由でチームの足引っ張り現場から離れた人もそれなりに見てきた…
最近はClaude Codeに「最新の取り込んで」と指示するだけで久しくgit操作してない
歴史修正主義者との戦いだ
feature branch で git pull origin main した場合の話をしている？？
あぁなんだ。featureブランチからgit pull mainするなってことね。そりゃそう。通常の使い方ではないから。 複数人で同じブランチ使わないのが一番で、できなきゃrebase --ontoだけど、これもブランチ複雑だと地獄が待ってたり
「瑣末」なこととしか思わん。rebase派もmerge派も等しくsquashされればよろしい
Gitなんて使いにくいモンが業界標準面してまかり通ってるのがそもそもの問題
わい、全部 AI まかせ。ベストプラクティスっぽいものが得られたときは、メモリに書いてもらってる
記事を読んだ時の違和感が、ブコメを読んでスッキリした。
mainの変更を取り込みたい時はmainでpullしてその上にrebaseしてるな。
誰もがコミットグラフを綺麗にしようという道を通るが、適当にやって必要になってからAIにログ調べてもらった方が早い
ブランチに取り込むなんてしないよね。。
もう少ししたらもっとエージェントフレンドリーな管理システムが生えてくる気がする
新しい宗教が誕生している。ならば戦争だ。
C言語的というか、簡単に自分の足を撃てる作りだよな。標準的なルールを強要する軽い枠組みがあるべきなのかもしれない。
gitについて
local に差分ある状態で pull はしないよ。
featureブランチを複数人で使わない。featureブランチのマージはPull Request経由。PRのマージはスカッシュマージ。これだけでrebaseを使う場面なくなる。履歴はPR単位で見れる。rebaseを使わないとダメな時点で開発体制がおかしい
GitHub Flow(PR以外でmainマージ無し運用)ならsquash merge すればいいんじゃないの。PR 用ブランチはごちゃって良い(fix: lintとかね)。squash なら、main は基本的に CI が通ったコミットが並ぶから、ロールバックの目安にしやすい。
pullの挙動は好きじゃないので使ってない
コミットログ綺麗にするのは費用対効果が悪いし自己満足だと思う。それこそAIの使い所かと。
『rebase の本質：「履歴を書き換える」』 いまだにrebaseを嫌いな理由
かつてはコミットログ整理派とコミット積む派がいたけど、今って過去の履歴もAI聴けば差分わかるし、どのコミットでどの状態だったか即座にわかるよ。かなり良いAIの得意技と使い方。人間が管理しなくていい
mainブランチみたいな共有ブランチの場合はrebaseもしない。git reset --hard origin/main のみ。自分だけしか更新しないブランチならrebaseもするけれど、レビュー後ならforce push したくないから、git merge origin/main しかしない
rebaseに時間かけてfeatureブランチ綺麗にするのあんま意味ない気がする。どうせfeatureブランチsquashすればきれいになるし。→ローカルのmainにpullしてそこからマージしてる。
プロジェクトの規模や業界によってベストな運用が違うのでSNSだとあまり話が噛み合わんやつ／個人的にgit関連はClaude Codeに丸投げしてる。あいつは俺の知らんgitコマンドを駆使して万事スマートに解決してくれる良い奴だ
個別のブランチで開発してPRのマージはスカッシュマージがよい
rebaseは極力rebase前のメタデータを残すオプションがあるので積極的に使うことで、履歴の改ざんを減らそう！
チーム開発だけど、pullとmergeでほとんど終わるので、rebaseするような開発ってどんな状況なのかが理解できない。(ほぼ使ったことない)ブランチ作業してて、main更新されたら、branchにmergeで取り込むんじゃないの？
数年単位で同じ話題を繰り返すけどAI以後で変わっていくのかな。
“「merge を理解せず pull すること」”
10年以上git pullしていた困ったことは一度もない。編集履歴ある時pullせんやろ・・
今ってpullをrebaseに設定できなかったっけ、初回pullで聞かれるよね。／あとrebaseはコンフリクトした時地獄だから基本的にやりたくない／マージコミットがノイズって初めて聞いた
git pull --rebase --autostashが標準のpullの動作になって欲しい。が失敗すると何してるかわからなくなるだろうな
git fetchを使うことはほぼ無いな
mainにおいていかれたときに追いつくのにマージするんじゃなくてrebaseしろということか。まあそれはそう。
やべ、普通にpullしてmergeしてた ノイズ発生機してた いい先輩がいたもんだ
これだけ gitなんてまともな機能として使われていないのに、いまだにgit以外使えるものがないの不思議、CVSよりマシとはいえ、git使うようになってから随分と経った気がするんだよな。CVSはすぐSVNとかに進化したのに
“先輩「git pull は使うな。git fetch して git rebase しろ」今ならよくわかります。あくまで「自分のfeatureブランチにmainの変更を取り込むとき、git pullではなくgit fetch + git rebaseを使う」という話”
ちなみにfeatureにmainを取り込むのをback mergeと言う。基本的にはアンチパターン。
mainが綺麗であればやり方は自由. 但しmainに(pull request 経由で)取り込まれるブランチも綺麗でなければならない; Commit log を綺麗にするのは人間が(後から見て)理解するため. AIに全部任せても責任取るのは人間
copilotに聞きながらやっとわかった。featureで`git pull`したってupstreamは？？？ってなってたけど、自分の開発ブランチで`git pull origin main`するなって話だった。なんだよpullするなって。紛らわしいよ時間返してくれ
普段、git を触らず、たまに必要に迫られて、ぐらいな自分にとって助かる記事。ブコメを見ながら、結局、リポジトリを「どう運用するか」は結構、千差万別で、それ故の複雑さ、難しさだよなぁ。
その会社にはその会社のルールがあって、この人の会社ではそうなっているというだけ