Git初心者の頃わからなかった「pullするな」の意味 - Qiita

はじめに AIを使ったバイブコーディングが普及してきた影響か、最近「コードは書けるけどGitはよくわからない」という人が増えてきた気がします。 AIがコードを生成してくれる時代になっても、Gitの操作は自分でやることが多いです。 そしてGitの概念を理解していないと、ある日突然「履歴がぐちゃぐちゃになった」「チームメンバーの変更を消してしまった」という事故が普通に起きます。 自分が新人のころ、先輩からこんなことを言われました。 「git pull は使うな。git fetch して git rebase しろ」 正直、最初は意味がわかりませんでした。 当時はGitに関しての知識としては、自分のブランチを最新化するときは git pull で何が悪いんだくらいの感じでした。 でも今なら先輩が言いたかったことがよくわかります。 この記事では、その「意味」をこれからGitを使う人向けに解説してい

[zentarou]

「複数人で同じブランチ使って開発するな」が正しい

[sds-page]

Gitなんて使いにくいモンが業界標準面してまかり通ってるのがそもそもの問題

[rarirurero9999]

あぁなんだ。featureブランチからgit pull mainするなってことね。そりゃそう。通常の使い方ではないから。 複数人で同じブランチ使わないのが一番で、できなきゃrebase --ontoだけど、これもブランチ複雑だと地獄が待ってたり

[igni3]

誰もがコミットグラフを綺麗にしようという道を通るが、適当にやって必要になってからAIにログ調べてもらった方が早い

[sevenspice]

生成AIでる前からGitわからない人沢山いた。それが理由でチームの足引っ張り現場から離れた人もそれなりに見てきた…

[mska]

「瑣末」なこととしか思わん。rebase派もmerge派も等しくsquashされればよろしい

[glass-_-onion]

featureブランチを複数人で使わない。featureブランチのマージはPull Request経由。PRのマージはスカッシュマージ。これだけでrebaseを使う場面なくなる。履歴はPR単位で見れる。rebaseを使わないとダメな時点で開発体制がおかしい

[Lian]

mainの変更を取り込みたい時はmainでpullしてその上にrebaseしてるな。

[iww]

『rebase の本質：「履歴を書き換える」』 いまだにrebaseを嫌いな理由

[otihateten3510]

今ってpullをrebaseに設定できなかったっけ、初回pullで聞かれるよね。／あとrebaseはコンフリクトした時地獄だから基本的にやりたくない／マージコミットがノイズって初めて聞いた

[rryu]

mainにおいていかれたときに追いつくのにマージするんじゃなくてrebaseしろということか。まあそれはそう。

[atsushieno]

git fetchを使うことはほぼ無いな

[sechs]

git pull --rebase --autostashが標準のpullの動作になって欲しい。が失敗すると何してるかわからなくなるだろうな

[tokuniimihanai]

10年以上git pullしていた困ったことは一度もない。編集履歴ある時pullせんやろ・・

[strtok]

“「merge を理解せず pull すること」”

[taguch1]

数年単位で同じ話題を繰り返すけどAI以後で変わっていくのかな。

[Eiichiro]

チーム開発だけど、pullとmergeでほとんど終わるので、rebaseするような開発ってどんな状況なのかが理解できない。(ほぼ使ったことない)ブランチ作業してて、main更新されたら、branchにmergeで取り込むんじゃないの？

[snsn9pan]

rebaseは極力rebase前のメタデータを残すオプションがあるので積極的に使うことで、履歴の改ざんを減らそう！

[R2M]

個別のブランチで開発してPRのマージはスカッシュマージがよい

[sqrt]

プロジェクトの規模や業界によってベストな運用が違うのでSNSだとあまり話が噛み合わんやつ／個人的にgit関連はClaude Codeに丸投げしてる。あいつは俺の知らんgitコマンドを駆使して万事スマートに解決してくれる良い奴だ

[Phenomenon]

rebaseに時間かけてfeatureブランチ綺麗にするのあんま意味ない気がする。どうせfeatureブランチsquashすればきれいになるし。→ローカルのmainにpullしてそこからマージしてる。

[slack_pulse]

mainブランチみたいな共有ブランチの場合はrebaseもしない。git reset --hard origin/main のみ。自分だけしか更新しないブランチならrebaseもするけれど、レビュー後ならforce push したくないから、git merge origin/main しかしない

[sionsou]

かつてはコミットログ整理派とコミット積む派がいたけど、今って過去の履歴もAI聴けば差分わかるし、どのコミットでどの状態だったか即座にわかるよ。かなり良いAIの得意技と使い方。人間が管理しなくていい

[unmarshal]

コミットログ綺麗にするのは費用対効果が悪いし自己満足だと思う。それこそAIの使い所かと。

[aobon700]

pullの挙動は好きじゃないので使ってない

[ishn]

GitHub Flow(PR以外でmainマージ無し運用)ならsquash merge すればいいんじゃないの。PR 用ブランチはごちゃって良い(fix: lintとかね)。squash なら、main は基本的に CI が通ったコミットが並ぶから、ロールバックの目安にしやすい。

[shag]

local に差分ある状態で pull はしないよ。

[hirrrose]

gitについて

[iphone]

C言語的というか、簡単に自分の足を撃てる作りだよな。標準的なルールを強要する軽い枠組みがあるべきなのかもしれない。

[moke222]

新しい宗教が誕生している。ならば戦争だ。

[hogetax]

もう少ししたらもっとエージェントフレンドリーな管理システムが生えてくる気がする

[thesecret3]

ブランチに取り込むなんてしないよね。。

[chuukai]

記事を読んだ時の違和感が、ブコメを読んでスッキリした。

[daruyanagi]

わい、全部 AI まかせ。ベストプラクティスっぽいものが得られたときは、メモリに書いてもらってる