BeejのGitガイド

 (beej.us)
1 ポイント 投稿者 GN⁺ 2025-02-06 | 1件のコメント | WhatsAppで共有
  • Gitを学びたい、または参照したい読者向けに、HTML・PDF配布版を複数の形式で提供しているガイドページ
  • ガイド自体は誤りの可能性を前提としており、Gitに関する誤った内容についてはメールで修正提案を受け付けている
  • HTML配布版は、分割版、単一ページ、ワイドスクリーン、ZIPなど、読む環境に合わせて選べる
  • PDFはUS Letter・A4、片面・両面、シンタックスハイライト版・白黒版の組み合わせでダウンロードできる
  • 翻訳者と執筆者は、資料一式をGitHubからクローンしたうえでREADMEに従って作業すればよい

閲覧用の配布形式

修正提案と元の作業資料

  • ガイドは誤りがある可能性を考慮しており、修正提案はメールで受け付けている
  • 翻訳者と執筆者はGitHubリポジトリをクローンし、READMEに従えばよい

関連記事

1件のコメント

 
GN⁺ 2025-02-06
Hacker News のコメント

  • 間違いを見つけたら投稿してほしい。自分で整理して直します — Beej

    • 間違いではないけれど、Git の文脈で vim を扱うなら :cq も入れてよさそう。非ゼロの終了ステータスで抜けられるので、Git がコミットや作業を完了できないようにできる
    • 本当に素晴らしい仕事で、これほど包括的な資料を作ってくれてありがとう。全部は読めていないが、5.1 節の表現が目に留まった
      https://beej.us/guide/bggit/html/split/branches-and-fast-for... では「デフォルトブランチは main」で、「以前は master で、古いリポジトリにはまだ master がある」としているが、これは正しくない。Git は今でも master をデフォルトとして使っており、将来的に git init について git config --global init.defaultBranch で変更できるようにしているだけ
      根拠: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
      また、「古いリポジトリ」という表現は誤ったメッセージを与える。GitHub がこの変更を決め、ほかが追随し、Git 本体も前述の設定を許可するようになったということであって、新しいリポジトリ／古いリポジトリの問題ではなく、好みの問題に近い
    • Lambda School で学んだ大勢の学生の一人で、そのときの授業は最も印象に残っている瞬間の一つだった
    • 10代のころに C プログラミングガイドを読み、今はファームウェア開発者として、今でも大きな恩があると感じている
    • 間違いではないけれど、git worktree も言及する価値がある。自分のワークフローでは中核だったし、その存在自体を知らない人も多かった
      stash を扱う面倒なしに、ブランチ同士が絡まないよう保つ良い方法だ

  • 10代のころに読んだ Beej's Guide to Network Programming と Beej's Guide to Unix IPC は、取っつきやすい一方で深みもあり、その後自分がどんなプログラマーになったかに大きな影響を与えた
    [0] https://beej.us/guide/bgnet/
    [1] https://beej.us/guide/bggit/

    • [1] は https://beej.us/guide/bgipc/ だ
    • 自分も似たようなもの。90年代半ばに10代で、IRCd サーバーコードとボットに驚かされた
      中古で CD-ROM 付きの Slackware Linux unleashed を買ったら C のネットワーキング例が入っていて、そのコードが分からず Beej のネットワーキングサイトに行き着いた。そこからさらにのめり込み、深いウサギ穴に入って、いくつもの書店を回ってプログラミング本を探すようになった
      Richard Stevens の素晴らしいリファレンス本を買ってからは後戻りせず、その情熱を可能にしてくれた Beej には今でも感謝している
    • select の使い方を学んでいたころ、あるポートスキャナー（たぶん “grabb” ？）をもっと速くしたくて、Beej のネットワークガイドをイタリア語に翻訳したのを覚えている。楽しい時代だった
    • 同じ人か確認しに来たが、ページごとに個性のあった昔の Web デザインを見て、ほぼ確信した
      父に電話料金で怒られないよう、オフラインで読むためにページを保存していた時代で、コードが動くと、人生でそれまで味わった失敗や拒絶を乗り越える承認のように感じられた。一台のコンピューターから別のコンピューターへメッセージを送る喜びは大きかった

  • 「古いコマンド: git checkout」を見て、git switch があることも知らなかったし、git checkout が古い代替手段と見なされていることも知らなかった。年を取った気分だ
    ほぼ10年前に Git を学び始めたのだから仕方ないとしても、今 Git を学ぶ人が、自分がなぜ git checkout を使うのか戸惑うかもしれないというのは妙な感じがする。古めかしい表現を使っている気分だ
    本文に戻ると、自分が学んでいたときにこのガイドがあれば本当に役立ったと思う。追いやすく、よくある疑問をうまく扱っている
    初めてのマージコンフリクトに怖じ気づいて中断し、その後コンフリクトを避けるために回り道した記憶も良い思い出として残っている

    • git switch はかなり新しいコマンドで、2019年に初めてリリースされた
      2021年の議論と数週間前の議論がそれぞれあり、後者ではドキュメント上 git switch がまだ 実験的機能 と見なされていることにも触れられている
      https://news.ycombinator.com/item?id=28024972
      https://news.ycombinator.com/item?id=42649858
    • git checkout がまだ「古い代替手段」と見なされているとは思わない。最後に確認したとき switch はまだ実験的だったし、約15年前に Git を学んだときに身につけたワークフローやコマンドから離れようとも思わなかった
      やりたいことは今でもすべて同じように動くし、git checkout も以前と同じことをしてくれる。他の人たちと Git で共同作業するのにも問題がないのに、あえてワークフローを変える理由はない

  • Git の使い方を説明する30を超えるパートからなるガイドが必要だということ自体、Git が大局を見失っているように感じる

    • 複雑なデータ構造に対して複雑なことをする複雑なツールに、ある程度の複雑さがあるという事実に、プログラマーたちがなぜそこまで激しく怒るのか分からない
    • 人々が Git に不満を言う努力の半分でも Git を学ぶことに使っていたら、マニュアルページで見つかる内容を説明するために30を超えるパートのガイドを作る必要もなかったと思う
      コミットはツリーのスナップショットで、祖先リストを持つ。通常は1つだが、常にそうとは限らない。タグは変わらないコミットの名札で、ブランチは変わるコミットの名札だ。インデックスは、コミットする前に add で詰めていく小さな作業中のプロトコミットだ
      これが Git だ。もっと知りたいなら、ガイドを読むのではなく、「ツリーに影響を与えずに特定の Git コミットへ切り替える方法」「変更したファイルの一部だけをコミットする方法」「別の場所のコミットを現在のツリーへコピーする方法」のように検索すればいい
      基本的な抽象化はミニマルで簡単だ。その抽象化でやりたいことのほうが精巧で複雑なのだ。前者を学び、後者は検索すればよく、ガイドを読む必要はない
    • Git の使い方は HN のコメント5行でも説明できる: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
    • それでも自分の足を撃つことはできる
    • そうでもあり、そうでもない。Git のユーザー向けコマンドは、おそらくユーザーの95%には十分によくできている
      rebase -i にはどのコマンドが何をするのかの案内が付いているし、git log の出力を好みや妥協点に合わせて整形する方法は数段落で足りる。通常、ユーザー向けコマンドには git gc, git fsck, git rev-parse のようなかなり雑多なものも含まれると考える
      低レベルコマンドは確かにより難解で、一般的なユースケースに最適化されたユーザー向けコマンドでは必ずしも簡単にできないことも、それ自体で多く行う
      要約すると、Git は大きく、巨大ですらあるが、ほとんどの開発者にとっては、提供機能のかなりの部分が主流の経路から遠く離れている

  • 恐ろしいのは、ガイドがこれほど長いという点だ
    Beej のガイドが概して網羅的なのは知っているが、Git の膨大な微妙さは、これを見るまで正しく実感できていなかった
    Jujutsu なら、ずっと薄いガイドになるか、少なくとも人がより発見しやすく学べるガイドになると思う

    • 私のガイドはたいてい、十分読んだと感じたらそこで読むのをやめられるように作ろうとしている。全部読む必要はない
      このガイドは Git の10%程度しか扱っていないと感じているが、一般的な利用の90%は扱えていることを望んでいる
    • このガイドは網羅的な側で、反対の極端としては、今後必要になる Git コマンドの90%を収めた1枚ものの資料がある: https://wizardzines.com/git-cheat-sheet.pdf
    • Git は大多数に合ったツールではないが、たまたま標準のように固まってしまったという兆候に見える

  • 職場で年に1、2回、2時間の Git データモデル入門コースを実施している
    実際に .git ディレクトリの中に入り、ファイルを展開して、すべてが基本データ構造の平文表現にすぎないことを見せる。人々の頭の中でピンと理解がつながる瞬間を見るのは本当に素晴らしい
    新入社員がコードをコミットし始められるように基本的な Git レシピ文書を共有しているが、ほとんどの人は何が起きているのか理解しないまま、その通りにやるだけだ
    一方で授業を受けた人は、コマンドをすべてよく知っているわけではなくても、Git で実際に何が起きているのかについて、かなり合理的な作業上の理解を持つようになる。コマンドは簡単に検索できるので、メンタルモデルさえ合っていればコマンド自体は大きな問題ではない。それなのに HN のほぼすべての Git 記事の議論はコマンドラインの話に流れていく
    興味深いことに、この授業は https://xkcd.com/1597/ の代替テキストに似て聞こえる。違いは、技術系の読者にとっては、それが実際に Git を教える正しい方法であり、一度理解すれば忘れない基礎的理解を得られるという点だ
    正直、この程度なら時間対効果が高すぎて、やらないほうがおかしいと思う

    • 私も一度やってみたが本当に良く、その後の議論も非常に素晴らしかった
      発表の最後のスライドに、Git データモデルをもとに同僚たちが答える質問を入れた。例えば「コミットを別のブランチに移せるか？」「コミットグラフに循環がないことは何によって保証されるのか？」といった質問だ
      人々が単に Git を使うだけで終わらず、Git について考えるようになったのが本当に満足だった
    • 「メンタルモデルさえ合っていればコマンドは大きな問題ではない」という言葉は、最初は90年代によく見た「Linux のすべての階層とすべての部分を理解すれば Linux の使用は簡単だ」というような論理に聞こえたと思う。理論上は正しいが、ほとんどの人には現実的に不可能な話のように
      幸い、初期に Git の内部モデルの一部を説明する動画を見て、実際には内部知識がそれほど多くも深くもなくても大きな違いを生むことが分かった。Git の動作方式の5%ほどを知るだけでも、コマンドが何をしているのか、どう使うべきかをずっとよく理解できるようになった
    • その2時間のコース資料や録画に、公開を妨げる独自情報や制約がないなら共有できるのか気になる
      公開されていて2時間に収まるほど簡潔な資料をもとにしているなら、このスレッドや HN の記事として共有してくれるとうれしい。同じテーマでも、前提、比喩、焦点が異なる学習資料は多ければ多いほどよいと信じている
    • 発表のコピーや動画があるのか、あるいはおすすめできる似た資料があるのか気になる
    • 動画を共有してほしい

  • Git の一般的な流れ、マージ、リベースなどはある程度できるが、Git をもっと上達しようとするより jujutsu に移ろうか真剣に悩んでいる。jj は Git と互換性があり、同僚たちが普通に Git を使っている間、自分だけ使っていてもいい

  • 多くのガイドや大半の Git GUI が見落としているコツが一つあると感じます。例外的に magit はうまく扱っています。
    アップストリームブランチを feature/foo の origin/feature/foo ではなく、マージ先、つまり統合ブランチである master や origin/master に設定することです。
    こうすると多くのことが単純になります。git status を実行したときに統合ブランチからどれだけ分岐しているかを教えてくれるので便利ですし、引数なしで git rebase を実行すれば、そのままアップストリーム上にリベースされます。
    origin/feature/foo をアップストリームにしておくのはあまり有用ではありません。開発者はリモート上の自分のブランチもたいてい「所有」しているので、そこからどれだけ分岐しているかには大した意味がなく、そこへリベースしたい場面もありません。
    push.default を "current" に設定すれば、git push も期待どおり feature/foo を origin/feature/foo にプッシュします。
    なぜこの設定がもっと一般的でないのか不思議です。

  • 協業セクションでは フィーチャーブランチ がまったく扱われていません。かなり一般的な作業方式ではないかと思います。
    ガイドの「全員が自分のブランチを使う方式」と対比すると有益そうです。また第17節では、GitHub のプルリクエストでブランチを再利用する方式と、PR ごとに新しいブランチを作る方式を扱ってみてもよさそうです。

  • この記事はまだ確認していませんが、良さそうです。もう一つのおすすめとして、Primeagen が教える boot.dev の Git コースがあります。
    インタラクティブで、.git ディレクトリ内のファイルを直接操作するレベルまで深く踏み込みます。そのコースを受けた後、Git がどう動作するのかについて まったく新しいメンタルモデル ができました。