Git 20

2024/02/15(木) 09:50:09.07

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/
Git 19
https://mevius.5ch.net/test/read.cgi/tech/1667720427/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2025/05/16(金) 23:33:35.97

>>446
でどう訳したの？

2025/05/17(土) 08:56:34.42

方向の違いとかコピーとムーブの違いが「同じ」と「だいたい同じ」の違いというわけか。

2025/05/17(土) 09:18:39.88

間違いを絶対認めたくないマン
公式まで否定

2025/05/17(土) 17:33:51.01

>>449
あー、どう訳したか説明しないとこ見るとエスパーが図星なのか
公式が初心者向けに「ほぼ同じです、でもこういう点が違います。詳しい説明はこちらって」って書いてるのの最初のとこだけ見て「ほぼ」も見ないで、後に続く説明もリンク先の詳細も無視して同じって言い張ってただけか
それはお前の読解力が足りてないだけ、公式のせいじゃないぞ

2025/05/17(土) 17:48:34.70

>>450
訳というかそもそもそのドキュメントは色んな言語版が用意されてて日本語のものもあるよ
訳が気になるなら読んでみよう

2025/05/17(土) 18:11:19.00

>>451
誤魔化してないで「お前が」同じだと主張する部分を説明してみろ
少なくともリンク先の英語の初心者向けの紹介には書いてないぞ
本当に同じならお前が cherry-pick で rebase 実装してみろ、そうすればみんな納得するだろう、技術者なら実際にやれば同じか別物か分かるだろう
git のソースコード読んだことないやつには想像もつかんだろうが rebase はかなり複雑なことをやってる、初心者向けのページすらまともに読み解けないお前には最初の1歩目の分岐点を探し出す作業ですら絶対に無理と予言しよう

2025/05/17(土) 20:46:35.58

そこで何か違うか端的に説明できたらよかったねおじいちゃん
何がmoveしてんですかぁ？
commitじゃなくてbranchのことですかぁ？
じゃcopyってどうゆうことですかぁ？

2025/05/17(土) 23:11:17.26

>>453
話逸らさずに同じとういうことを証明してみろ
細かい事いえば山程違いがあるけど、違うというのは 432 で素人にも一目瞭然なのに覆せるわけないだろう
間違えた恥ずかしい事実はごまかせないぞ

2025/05/17(土) 23:17:53.88

違いがあるというなら、あなたがコミットのコピー/ムーブと呼ぶものはどちらも実際には全く異なるコミットを作り出すでしょう
そういうのをダブスタという

2025/05/18(日) 00:30:50.11

>>455
読解力ないの日本語のなんだな

2025/05/18(日) 03:09:09.55

なんて？

2025/05/19(月) 09:09:53.56

>>432
XY両方ではなく、XやYのみを取り込むのがcherry-pickというイメージだが

2025/05/19(月) 21:35:49.68

>>458
普通の範囲指定が効くので
その図なら git cherry-pick ..Y みたいに指定すれば X と Y の両方 cherry-pick できるよ

2025/05/20(火) 08:32:54.32

会話が噛み合わないコントみたいなスレで草
みんな文意文脈にももっと気を配ろうぜ

2025/05/20(火) 15:48:18.98

「エクスプローラー」の「Git」統合などが実現へ～Microsoftが開発者向け新機能
ps://forest.watch.impress.co.jp/docs/news/2015419.html

2025/05/20(火) 16:58:09.70

亀の出番がなくなるのか？

2025/05/21(水) 08:05:21.38

エクスプローラーなんて、Windows7のときに使わなくなったな

2025/05/21(水) 10:18:53.96

MSアカウントにログインしないとExoplorer使えないとか
もうWindows要らんな

2025/05/25(日) 03:59:20.13

わざわざExplorerからコミットとかプッシュする奴おるんかw

2025/05/25(日) 07:06:19.26

OSのSystem領域も含めて全部がリモートリポジトリの運用かな。

2025/05/25(日) 08:49:46.44

>>465
申し訳ありません、今でもTortoiseGitでやってます

2025/05/25(日) 09:13:50.01

Windowsだと、手取り足取り指示してあげないと自分で何もできない「開発者」をExcel方眼紙の手順書で「プログラミング」してあげるような仕事も多いから、
そういう場合に「開発者」の手元にいちいちGitクライアントを導入させるという頭悪い手順を記載する必要がなくなるなら便利かもしれない

2025/05/29(木) 02:32:23.75

Git v2.50.0-rc0

2025/06/04(水) 13:13:31.34

Git v2.50.0-rc1

2025/06/06(金) 01:08:14.98

gitもはや20年か

2025/06/07(土) 08:05:32.65

gitアレルギー

2025/06/10(火) 09:49:47.00

Git v2.50.0-rc2

2025/06/17(火) 08:04:33.42

Git v2.50.0

2025/06/18(水) 00:48:41.95

オススメのgitクライアント教えて
source treeはなんかuiの一つ一つがデカくて肌に合わなかった

2025/06/18(水) 02:39:03.14

自分はlazygitとVSCodeだな

2025/06/18(水) 08:16:55.75

うちではSourceTreeというやつを使ってるよ

2025/06/18(水) 09:02:23.67

使いにくいやつね

2025/06/18(水) 18:04:24.45

lazygitかSourcetreeだな。

2025/06/19(木) 20:10:05.29

わかばちゃんの中の人
ps://x.com/llminatoll/status/1935310637196095988?t=KJizsM3DHuYlJSyTCzcZcg&s=19

2025/06/21(土) 23:55:27.59

VSCodeの拡張機能で提供されてる Git Graphが使いやすいね

2025/06/22(日) 00:39:02.97

あれいいよね、見やすい
ハッシュ手打ちの人がんばってw

2025/06/22(日) 06:56:54.23

CUI でもハッシュを手打ちすることなんてほぼないだろ
ブランチもタグも検索も使ってないんだろうか？

2025/06/22(日) 18:51:38.68

>>481
んー

でも、他のGitクライアントも似たもんじゃないの？

2025/06/23(月) 11:27:58.47

似たような、がどの辺を指してるかにもよる。
rebaseかstash簡単にしたい、tag打ちたい、ブランチ作りたいならだいたいどれでも出来る。
　ただ現場で初心者多くて教育面倒だし日本語じゃなきゃだめとかいうなら、SourceTreeか
非公式多言語版GitHub Desktopしかないと思う。

2025/06/23(月) 12:06:20.95

>>485
で、ベストは？
英語でも有料でも、なんでもいいので

2025/06/23(月) 12:11:55.90

interactiveなrebaseをサポートできてないやつ多いでしょ

2025/06/23(月) 17:00:15.66

基本は好きなの使えばいいよ。
対面レビューで追加コミット後に「レビューOKだからコミットひとつにまとめといて」って言われたり
「ウチは協力会社に外資いるから日本語コメントだめなんだ、英語にしといて」って言われない限り
rebase(やsquash)やamend使うこともないだろうし。

2025/06/23(月) 18:37:21.89

いや rebase -i も --amend も使いまくりだろ
何なら一番多く使うコマンドまでありえる
一発で完璧な記録できて後は触らないみたいな超人じゃなきゃ、普通に多用するだろ

2025/06/23(月) 19:49:45.04

といっても元のコミットがある程度ちゃんと作られてることが前提じゃない？
単に作業のチェックポイントとして気軽にコミットしてると、いざコードレビュー前に整理しようとしたときには元のコミットを無理に再利用するより
resetして作り直した方が早いことが個人的には多い
書いてて思ったけど、元のコミットがすでに整理されている上で修正を入れる状況としては、コードレビューの中での修正があるね
もしチームのポリシーとして瑣末な指摘反映をログに残さないことにしているなら、レビュー後マージ前にrebase -iするのは便利かもしれない

2025/06/23(月) 21:20:02.74

そっちじゃなくて手元で色々作り散らかしたコミット履歴を綺麗に読み易く整理してから、レビューに出す。
順番入れ替えたり、コミットメッセージを分かり易くしたり、不要な履歴を消したり、コミットを意味に合わせて分割したり、統合したり
その整理に活躍するコマンドが rebase -i、慣れると手放せない

読み易く整理されてれば他人の時間の節約になる、試行錯誤とかタイポ修正とかの痕跡を他人に見せて時間を奪わなくてすむ

2025/06/23(月) 22:25:23.37

そんなの方法を議論する以前にもうAIにやらせたらいいんじゃないかという気もするが、
AIにやらせるならやっぱり一連のgitコマンドを直接生成させるのがいいのかなあ
コマンドだと人間が実行前にレビューするのは辛いものがあるから、diff入りのコミットログみたいな形式で生成させて、resetした上でそれを反映するのがいいと思うんだけど

2025/06/24(火) 07:59:57.08

>>492
AI に期待し杉
今のAIはしょせん賢い検索エンジンに過ぎない
学習したことの最も多数派の意見をそれらしく繋ぎ合わせてるに過ぎない
素人が玄人の作業を真似るのには使えるけど、玄人の創造的作業の代替は無理

2025/06/24(火) 08:31:50.93

>>491
プロトタイプであれやこれやするなら、さらにブランチ作って動くようになったら新しいブランチに
Squash and Mergeして、そっちのブランチをレビュー対象にした方が楽なんじゃ？

2025/06/24(火) 10:30:20.42

>>494
いやだから、色々なブランチに順不同で入ってるやつの共通部分を括りだして独立したコミットにしたり、一つのコミットを内容に合わせて複数に分割したり、ばらばらのを分かり易く統合したり
やるべきこっとはいっぱいあるだろ
merge も squash も amend も全部 rebase -i を使ってやる、rebase -i を何だと思ってるんだ？

2025/06/26(木) 10:59:58.77

amendやsquashを一般人が簡単にやりたいならGitHub Desktopの履歴のとこから出来るけど
使用説明が一切ないんだよなあ。圧倒的なドキュメント不足。

2025/06/26(木) 12:02:10.03

>>495
アトミックに細かくコミットする人ならrebase -iでの整理は容易だろうけど、分割が多い場合は面倒臭すぎるでしょ
resetしてやり直した方が早いわ

2025/06/26(木) 14:45:21.20

>>497
意味分からん
「細かくコミット」と「分割が多い」は同じじゃないの？お前の用語での違いは何？

コミットを統合したり分割したりするのも rebase -i から始めるのに？
いくらでも変えられるのに何が問題なの？

2025/06/26(木) 17:51:44.27

「細かくコミット」がバックアップ保証のつもり(で修正が動くかどうかも分からん)なら、
都度commitだけしといてpushは待っとけばいいんじゃないかなと思ったり。

2025/06/27(金) 10:30:24.43

当たり前だろ
動作確認できてないものpushすんなよ

2025/06/27(金) 10:39:46.35

>>500
どこに push するか次第だよな

共有リポジトリや公開リポジトリに push しちゃ駄目だろうけど個人のバックアップ・リポジトリとかに push しとくのは自由
リポジトリやブランチを好きなだけ作れて高速に同期できるのが git の利点なんで限られた少数のリポジトリしか使わないのはもったいない

2025/06/27(金) 10:46:55.51

GitHubでのチーム開発だと普通に共有リポジトリにpushするけどな。
ただしpush先はいわゆるfeatureブランチなど、そのタスク専用のブランチ。
draft pull requestを作っておいて他人から容易に目に見えるようにするとなお良い。
むしろ手元で長いこと留めてあいつ何やってんだろと思ったら突然クソデカpull request投げてくるような奴は嫌われるよ。まあ開発に限った話ではないが。

2025/06/27(金) 14:47:42.22

>>502
その辺はチームの方針次第だね
リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか
マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う（個人の意見

2025/06/27(金) 15:24:34.92

>>503
本題からは逸れるんだが、企業での開発で個人リポジトリにforkする運用ってなんかメリットあるのかな？
自分はこれまで共有リポジトリ運用しか見たことがない
なお、新卒がいきなりforkして怒られてるのは何度か見た
forkして複数の共有リポジトリを使うのは複数の会社がいてそれぞれガバナンスが違うケースなんかで珍しくないけど

2025/06/27(金) 17:03:03.14

>>504
github みたいに fork って呼ぶから混乱するんじゃないかな？オープンソースじゃないから単なる clone だろ
開発用の clone はいくつあっても良い、個人用でもデスクトップとノートPCとサーバと複数の場所にリポジトリもってて定期的に同期させたりしながら、移動中とか自宅とか会議中(笑)に開発したりできる
もちろん会社の情報統制や社外秘情報の漏出防止のためにコピー禁止とか部屋外に持ち出し禁止とか決まりあれば従わないと駄目だが

2025/06/28(土) 00:10:08.26

Gitむずかしい…
Pythonよりむずかしい…

2025/06/28(土) 11:34:58.63

雑にpushするブランチを作ってあるので
ホイホイプッシュしてる

2025/06/28(土) 14:23:18.12

いやPythonの方が難しいでしょ

2025/06/28(土) 15:15:53.19

初心者なんですが、
branch1とbranch2があって、
branch1にcheckout後に、>git merge branch2　と、
branch2にcheckout後に、>git merge branch1　って、
結果は同じ？

2025/06/28(土) 15:31:34.65

>>509
ソースコードの内容は同じになる
ログは違う形になる
ログはどのようにソースを扱ってきたかの履歴書や歴史書のようなものなので複雑で大規模なプロジェクトほど価値が出る

2025/06/28(土) 15:47:58.18

>>510
あ、
今やってみましたが、
mergeコマンド実行するときの自分がいるブランチのほうが、引き続き残るって感じですかね？

2025/06/28(土) 16:06:18.63

>>511
ブランチ自体はどちらも残る
自分がいる方のブランチはマージ結果を指す形で歴史が一方進む
そうじゃない方のブランチはありのまま残る

2025/06/28(土) 17:09:16.02

「自分が今いるブランチに指定したブランチの「内容」を混ぜ（merge）する」というのがコマンドの意味

当然
・今いるブランチは書き換わってコミットが進む
・指定したブランチには変化なし

2025/06/28(土) 18:17:50.37

>>512
あ、
自分がいたほうじゃない方のブランチは、
branch3とかにつなげられますね…

2025/06/28(土) 18:19:22.53

>>513
ですね

わからない理由は、日本語のまともな解説が無いからですね…
海外の解説で、ようやく理解できました…

2025/07/01(火) 20:11:53.56

混じるからマージる

2025/07/01(火) 22:46:34.19

去年のリリースの記憶をタグる

2025/07/02(水) 21:57:57.01

頭悪い人って自分が理解できないのを説明する人のせいにしがちだよね
説明が悪いならなんでお前以外の人は理解できてるのかと

2025/07/03(木) 03:33:50.65

能力不足故に検索の仕方や聞き方が下手で自らが望む解説に効率的にアクセスできない
ダニングクルーガー効果のような認知バイアス
元から他責的、依存的なせいで残り少しの努力を怠り多方面で理解不足に陥りがち
この中のどれかか、複合要因ではないかな

2025/07/05(土) 16:41:53.58

>>518
それは、
運良くいい説明を見れたからでしょ

お前には無理そうだが

2025/07/05(土) 17:28:57.77

大丈夫だよ
プログラム書いたらビッとコミットしてギュッとプッシュしてギャンよ

2025/07/06(日) 09:39:11.50

コミッとコミットする

2025/07/09(水) 16:29:53.53

Git v2.50.1

2025/07/09(水) 20:54:58.43

初心者の質問ですが、
Linux（サーバー的なもの）に、GitHubのレポジトリをクローンして来て、
それをWindowsパソコンからSSH接続して、
Gitの履歴の図（Gitグラフ？）って見る方法ありますか？

2025/07/09(水) 22:47:25.77

ありますね

2025/07/10(木) 12:47:26.79

>>525
会話を広げる癖をつけろ童貞

2025/07/10(木) 20:49:27.62

>>526
なら会話広げればいいじゃん。

2025/07/13(日) 17:29:18.40

>>524
sshで git log --graph で履歴取ってきて、mermaid変換してmarkdown埋め込みにすればいいんじゃね？

2025/08/06(水) 12:13:19.02

>>526
あると信じて検索すれば報われますよというありがたい情報だぞ

2025/08/13(水) 06:18:19.45

やりますね

2025/10/22(水) 09:23:57.49

https://forest.watch.impress.co.jp/docs/news/2056148.html
次のバージョンからgit svnが廃止されると書いてあるけど、
これはSubversionからの変換もできなくなるということでしょうか

2025/10/22(水) 13:20:45.27

Git for Windowsの次回メジャーリリースでの話をしてるならそうだよ
旧バージョンや本家を使うとか、svn2gitだとか別VCS経由とか手作業での移行だとかは出来るでしょう

2025/10/22(水) 13:52:16.21

もうシンプルに使われてる機能だけをブラッシュアップすればいい思う。
互換性とか古いものをメンテし続けるのは大変だよ。

2025/10/24(金) 14:37:23.45

いまだに新規プロジェクトでSubversionからっていうのはもう洗脳されてるから放置で良いし
Subversionから変換する気があるならもうとっくにやってるだろうし

2025/10/24(金) 15:02:05.38

Windowsユーザーだと、業務でSVNを使わざるを得ないがGitコマンド経由で使うことで辛うじて自己の尊厳を保っていた人もいそうだな
電車止まりそう

2025/10/24(金) 18:33:25.65

>>535
そんなプロジェクトやだなぁ

2025/10/24(金) 20:17:02.32

令和なのにまだSVNで消耗してる人いるんだ
絶滅危惧種かな

2025/10/24(金) 23:30:36.26

>>535
Gitって、開発速度は遅くなるよね
コードレビューとか丁寧にやると遅くなるよね…

2025/10/25(土) 00:27:30.86

>>538
規模（参加人数、開発期間、コードサイズ）次第。大きくなれば git 使った方が早い

2025/10/25(土) 04:23:36.31

>>538
gitだからコードレビューが必要って認識？
アホじゃね？

**デフォルトの名無しさん** (JP 0Hee-i36n) · 2025/10/25(土) 08:42:34.81

SVNと比較しての話なら、Gitはコミットやブランチの操作が遥かに軽量だからこそ、
チームが必要以上に面倒なワークフローを作り込みがちな面があることは否定できないな
非機能要件でちゃんとバージョン管理しろと書かれているからという理由だけでVCS使ってるような典型的な業務系でSVN使い続けてるようなとこだと、
レビュー済みまたはリリース済みのコードをコミットするだけみたいな運用は珍しくないからな
そういった意味で、VCSの運用という点だけ見ればGitの方が複雑になる傾向があるとは思う

2025/10/25(土) 12:06:31.87

>>539
まあ、
大規模だと、ちゃんと管理が必要ですね…

2025/10/25(土) 14:26:57.22

>>538
御社はコードレビューまともにやらんのですか？

2025/10/28(火) 13:00:39.46

>>543
それGitに関係あるって話だと思う。
Pull requestのことを言ってるのならGithubとかの話だし。

2025/10/28(火) 15:19:39.06

>>544
その辺はまちまちだろう
コードレビューの仕組みに git を組み込んでる所もあれば別の方法を取っているところもある
コードレビューの結果を git に格納している所もあれば別の仕組みで管理してるとこもある
別の仕組みで管理していても git にコミットしたら自動的にレビューやテストに連携する仕掛けを作ってるところもある

作成したコードをいったん git に入れて git に差分を出力させて、それをメールで送ってレビューやってるOSのカーネルもある

2025/10/30(木) 02:49:22.78

これまで数社で目撃した光景だけどsvnからgitへの移行にはどこも苦労してた
当然gitなんて触ったことないメンバーが移行なんて上手くできないから、中途組やBPでやることになり負荷が集中
運用フローも現行の運用を把握したうえでの整備になり、ヒアリングも苦戦

何より、移行するメリットをみんなが納得してくれなくて進まないこともあった
最近だとgithub copilotのおかげで移行するメリットは説明しやすくなったと思うけど