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

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

[zentarou]

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

[sds-page]

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

[igni3]

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

[rarirurero9999]

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

[sevenspice]

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

[mska]

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

[glass-_-onion]

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

[Lian]

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

[otihateten3510]

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

[iww]

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

[Shinoryo11]

Git pullはfetchとmerge。merge commitで履歴が乱れる。rebaseで履歴を整理しよう。

[twotiger]

その会社にはその会社のルールがあって、この人の会社ではそうなっているというだけ

[JULY]

普段、git を触らず、たまに必要に迫られて、ぐらいな自分にとって助かる記事。ブコメを見ながら、結局、リポジトリを「どう運用するか」は結構、千差万別で、それ故の複雑さ、難しさだよなぁ。

[jintrick]

copilotに聞きながらやっとわかった。featureで`git pull`したってupstreamは？？？ってなってたけど、自分の開発ブランチで`git pull origin main`するなって話だった。なんだよpullするなって。紛らわしいよ時間返してくれ

[vanbraam]

mainが綺麗であればやり方は自由. 但しmainに(pull request 経由で)取り込まれるブランチも綺麗でなければならない; Commit log を綺麗にするのは人間が(後から見て)理解するため. AIに全部任せても責任取るのは人間

[work996]

ちなみにfeatureにmainを取り込むのをback mergeと言う。基本的にはアンチパターン。

[yarumato]

“先輩「git pull は使うな。git fetch して git rebase しろ」今ならよくわかります。あくまで「自分のfeatureブランチにmainの変更を取り込むとき、git pullではなくgit fetch + git rebaseを使う」という話”

[etah]

これだけ gitなんてまともな機能として使われていないのに、いまだにgit以外使えるものがないの不思議、CVSよりマシとはいえ、git使うようになってから随分と経った気がするんだよな。CVSはすぐSVNとかに進化したのに

[teasilvousplait]

やべ、普通にpullしてmergeしてた ノイズ発生機してた いい先輩がいたもんだ

[rryu]

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

[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してそこからマージしてる。

[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]

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