Git 20

2025/02/15(土) 00:32:15.20

>>327
このスレに多数の人が集まってるって言えるの？

2025/02/15(土) 01:49:01.01

>>329
俺とお前の二人きりでないのは確実だ

2025/02/15(土) 05:04:09.56

>>330
俺とお前と大五郎

2025/02/16(日) 12:05:30.15

点呼始めると急に人減るからな

2025/02/26(水) 19:03:01.07

GitはConflictの修正で強制的にVim使わせんのやめてほしいんだが
WindowsユーザーがVimなんて日常的に使ってるわけねーんだが想像力ねーのかよ馬鹿が
みんなしち面倒だから極力競合しないように気を使ってて競合修正すること自体も少ないから
たまに競合すると修正するのだけでも怠いのにそれに輪を加えてVim使わされるから調べ物が二倍になんだよハゲが
さっさと競合の修正をVSCodeのエディタでできるようにしろボケ

2025/02/26(水) 21:59:35.09

>>333
お前のって変更できないの？
何をつかってるんだろう

2025/02/26(水) 22:20:46.32

Vimの使い方を必死で調べる癖に、Gitの使い方は調べないのか
おかしいよな、やっぱり釣りかな

2025/02/26(水) 22:22:24.99

キレてんね～

https://docs.github.com/ja/get-started/getting-started-with-git/associating-text-editors-with-git

2025/02/26(水) 22:24:39.42

>>334
開発環境はVisual Studio 2022かVScodeなんだがGitはTerminalのPowerShellのCLIでコマンド入力して使ってんだわ
だからTerminalからbarnchをmergeしたときに競合が起きると強制的にVimになってただでさえ競合でマズっ！て動揺しとんのlにブチギレそうになるんよ
TerminalからGitを使って競合したときにVSCodeでDiffする機能がググってもみつからねーんだよ

2025/02/27(木) 06:49:34.86

まあ、ぐーぐるが蔓延ってからフリーソフトはダメになったよな

マイクロソフトを使ってるやつらが雪崩れ込んできてからさらに異質になってきた

2025/02/27(木) 07:25:35.18

どういう意味？

2025/02/27(木) 08:17:38.02

ドキュメント読まない、考えない奴が増えたということでは？

2025/02/27(木) 09:10:37.13

この流れでフリーソフトがダメになったとか言い出すの謎
初心者の不満に優しい回答者が解決してあげただけで、不満はお門違いなもので必要な機能は完全な形で提供されてた

2025/02/27(木) 09:36:53.23

git は機能が多過ぎてマニュアル読んでもどこに書いてあるんだか見つけれないというのはあるんだと思う
けなしたりせずに最初から丁寧に質問すれば良いのに、質問者が悪い

2025/02/27(木) 12:49:05.52

>>337
だっさ

2025/02/27(木) 13:38:03.41

個人的には
unix/linux屋の感性だとエディタとか特定のやつ強制されたら、もう宣戦布告扱いなんで絶対に変更できるようになってる
EDITOR環境変数とかに追従しないならチュートリアルの先頭あたりで説明がある
とういの感覚なんだけど Windows みたいにお仕着せに甘んじるのに慣れさせられた子羊ちゃんたちには厳しい世界に見えるんだろうか？

2025/02/27(木) 15:26:47.55

>>342
難しくてわからない質問されて見下された気がしてイラッとしたからとりあえず煽っとくまで読んだ

2025/02/27(木) 18:59:01.12

おかしな人を一人見ただけで最近の子は～とか言い出しちゃうのって老化現象なのでは

2025/02/28(金) 01:35:09.82

>>337
ターミナルも仕様がよくわからないのによく使うな
比較的、新しいものを使うなら古い方を知ったうえで使わないと

2025/02/28(金) 02:45:09.17

ここ老人ばかりだし老化現象ではと言われてもあんまり効かないよね

2025/02/28(金) 08:41:15.61

>>336 に礼くらいしろ。
感謝すらできないタダメシ寄生虫かよ。

2025/02/28(金) 09:19:01.12

礼を求めるのはムリだろー
素直に教えを請うのではなく怒り散らすことで回りが俺様を助けてくれることを期待する駄々っ子タイプなのは最初の発言からわかってる

2025/02/28(金) 09:30:18.88

今回の場合、Gitのダメなところをぶちまけて憂さ晴らししようとす来たら反論で恥かかされてさらに怒ってるまである

2025/03/01(土) 11:36:53.90

久々に落ちて来た餌に群がる深海魚のようでつね

2025/03/01(土) 12:39:20.26

よく言われる
顔が深海魚みたいだって

2025/03/05(水) 20:27:54.18

masterからbranch切ってコミットして、VSCodeにSyncronizeってボタンでたからそれ押したらmasterブランチで？に？pushされた
これってコマンドだとどういうコマンド使ったことになるの？

何か嫌だったからmasterブランチの方はpullしてrevertして、masterと新しく切ったbranchをpushしなおした

2025/03/05(水) 20:32:53.30

GitはCLIの方が圧倒的に使いやすいわ
GUIやとでけへんことが多すぎるし逆に面倒やからな
ニワカどもがSourcetreeとかGithub Desktopとかを初心者にすすめんのやめーや
最初が肝心なんやからどうせ教えるならしっかり手取り足取りCLIで教えたれ

2025/03/06(木) 02:17:50.54

コミット履歴見ながらあれこれやるときはcliはやってられんでしょ

2025/03/06(木) 08:13:14.54

サーバ側のログ見たけどエラーログしか吐いてなくて、アクセスログ的なログは無かった

2025/03/06(木) 08:37:02.92

>>356
why?
CLI しか使ったことないけど

2025/03/06(木) 13:33:57.70

>>355
コマンドはネット上に嘘が大量に書かれているからなあ

2025/03/06(木) 14:56:33.55

>>359
マジで？
困った時しか調べないので気付いてない。

2025/03/06(木) 15:07:24.98

>>358
マウスなら数手で済むところをハッシュ見て打ち込んでスクロールアウトしたから見直してとか非効率
何事も向き不向きがある

2025/03/06(木) 16:54:30.08

>>361
意味わからん
普通キーボードから手を離してマウスに手を持っていく暇があれば、その時間にコマンド打ち終わって実行結果の確認まで終わって次の作業始めれるけど？
CLI使うかエディタのショートカット使うかの2択だろ、マウスの出る幕はない

2025/03/06(木) 17:47:20.86

>>362
それいうならおれはトラックポイント使ってるから持ち替えるなんて無駄はとっくの昔に排除してるっての
おれはCLIでも使える
環境変えた時に困るからな
で比較した上で言ってる

2025/03/06(木) 18:43:44.49

>>363
何が言いたいか分からん、俺は無能なのでGUIで十分って言ってるの？
「CLIだとやってられない」の根拠をまるで示せてないけど？

command のオプションとか使いこなせてないだろうことは何となく察せられる。例えば履歴見る時に git log に -G とか --grep とか使ったことある？この違いって即答できる？

2025/03/06(木) 19:00:28.81

いやGitは明らかにGUIよりCLIの方が使いやすいんやがwww
いやちゃうなCLIが使いやすいんやなくてGUIがどれもクソすぎるんや
唯一マシなGitKrakenはクソ高いサブスクやしな

2025/03/06(木) 19:10:55.39

CLI派はステージする行を取捨選択したいときどうするの？
煽りたいわけじゃなくて興味がある
なお俺は普段VSCodeとlazygitを使っていて込み入った操作のときだけCLI使っている

2025/03/06(木) 20:03:56.86

>>366
git add -e でエディタで選択
git add -i でCLIメニューで選択
個人的には前者を多用してる

2025/03/06(木) 23:00:54.80

マウスに一切持ち替えないCLI過激派の人ってハッシュは目視確認して手で打ってるの？
HEAD~~とかHEAD~4とかでだいたい済むから手打ちするにしても稀な感じなのかな

2025/03/06(木) 23:23:19.37

過激派じゃないからやったことないけど、マウス使わずにCLI単体で目的のハッシュ検索→コピー→ペースト出来んじゃないの？

2025/03/07(金) 00:54:33.86

CLI で hash値を入れることなんてまずないだろ
直近のは HEAD やブランチ名からたどるし、古いのはタグ打ってたり、検索条件で特定する
どうしても hash値で特定したい時は先頭の4文字とか打つだけでいけるので全部入れる必要はないよ、そんな機会はめったにないが
あとやろうと思えばCLIでもエディタ操作でマウス以上に高速にコピペできるけど

2025/03/07(金) 02:01:32.04

GUIでポトペタばっかしとる奴らの前提が空で覚えるの前提なん草
そもそもTerminalもGitbashもインテリセンス効くことを知らんの無知すぎてクソワロタ

2025/03/07(金) 02:20:38.51

自分がやっていることを説明しない、説明できないタイプは、コマンドに逃げる傾向があるんだよな。

2025/03/07(金) 05:10:53.94

>>372
というより、そうする必要があるかどうか次第だな
>>367からも分かる通り、メクラコミット中心ならCLIで十分、コミット内容の細かな編集が多いならCLIの範疇だけでは難しい

2025/03/07(金) 08:46:11.25

>>373
難しくないだろ git add -e で完璧制御できる
パッチをそのまま目視できて編集できるんだから、もっとも確実
どんな細かい変更でも自由、なんらら一行に複数の変更がある場合に一部だけとか、実際にソースにない変更も可能

2025/03/07(金) 09:59:34.81

エディタ使ったらそれもうCLIじゃないでしょ
TUIではあるけど、それを広義のCLIと認めるならlazygitやtigのような実質GUIと変わらんようなTUIクライアントもCLIになってしまうがそれでよいか

2025/03/07(金) 10:28:55.57

Gitを使っておきながら、他人にはわからないコマンドだけの手順を書くやつは必ずいるしな

2025/03/07(金) 10:52:06.81

>>375
こんなの暴論だろ
どうやってコード書くんだよ

2025/03/07(金) 11:15:57.74

コーディングとは違ってステージ時のパッチ編集はGitのために行う操作なんだから、GUIクライアントとの比較の文脈ではGitの操作の一部と見做すべきでしょ
git guiはCLIか？git add -eでVSCodeを開くのはCLIか？
エディタを呼び出した時点でもはや純粋にCLIと呼べない以上、程度問題でしかないってことだよ

2025/03/07(金) 11:23:23.99

>>378
CLI といにはもともとがスクリプト書いたり、エディターから呼び出すパーツを想定してあって、毎回直接打たないといけないって意味じゃないぞ、あくまでも git にアクセスするインターフェイスの種類
自分用にカスタマイズして使うのは当然

2025/03/07(金) 11:35:48.56

そう。そしてGUIクライアントも同様にCLIを呼び出すインターフェースに過ぎない。
だから変な差別意識持たずに仲良くしような。

2025/03/07(金) 11:44:27.31

>>380
インターフェイスというのは「呼び出し側が理解して制御してる部分」と「制御していないブラックボクスとして扱う部分」の境界のことだ
UI ならユーザとアプリの境界、その動作が内部でどのコマンドに展開されるか想定してばスクリプトやエディタから呼んでもCLI
一方でボタン押すだけで中でどのコマンドに変わるのか全然理解できてなければCLIではない

2025/03/07(金) 11:49:35.66

ユーザーが制御できてるか簡易に見分ける方法は「自由に変更できるか」だ
呼び出すコマンドを理解する必要があって自由に変更できるならボタンからだろうショートカットからだろうとCLIでいい
自由に扱えないならそれはインターフェイスの向こう側だ

2025/03/07(金) 12:50:44.02

正直そんな事どうでもいいから>>354教えてほしいです

2025/03/07(金) 13:45:02.36

>>370
それ都合のいいようにCLIの不利なケースを排除してるだけだろ
お前みたいなやつは死ぬほど見てきた
CLIで曲芸してるだけ
適材適所で使うってだけの話を受け入れられない

2025/03/07(金) 13:58:21.86

>>384
そもそもCLIで使う前提でコミットログ書くし、ブランチ切るし、タグ打つし、git のUIは最初からそういう設計になってつんだよ
全部のハッシュ打たなくて確定できるまでの文字打てばすむのもそう
git は CLI を使うプログラマによって設計開発発展してきた履歴があるので CLI で困ることはない
「CLIではやってられない」とか言い出すのはそいつが未熟で git に慣れてないだけの妄想
まあ全員が git に慣れてる必要はないので口を閉じて「馬鹿でも使えるものは馬鹿しか使わない」という世界に閉じこもってろ

2025/03/07(金) 14:16:08.04

>>385
マウスの持ち替え気にするくせにハッシュを目視で確認して打ち込む非効率さは目をつぶる
インタフェースやビジュアライズの大切さを無視するエンジニアとは仕事したくないね
ちなデバッガももしかしてCLIかい？w

**デフォルトの名無しさん** (JP 0H33-qG2n) · 2025/03/07(金) 14:28:05.14

>>385
君の意見を否定するつもりはないが、事実としてGitの公式ディストリビューションにはGUIが付属しているし、git gui コマンドも存在するし、公式サイトで非常に目立つ形で非公式のGUIクライアントを紹介している
こんなところでヘイト撒いてる暇があったら削除するようリクエストしてきた方がいいぞ

2025/03/07(金) 14:58:36.90

CUIって自分の操作の履歴辿れるけど
GUIは何やったか覚えてないとか
意図しない変化があったときに今何した？ってなるのが嫌

2025/03/07(金) 15:02:30.73

>>354 の感じてる「なんか嫌」も >>388 と同じ理由だと思う

2025/03/07(金) 15:36:27.72

>>387
別にGUI使っちゃ駄目とは一言もいってないぞ、GUI使いたいやつだけ勝手に使ってれば良い、それで苦労しようが失敗しようが知ったこっちゃない
「CLIではやってられない」という虚言を否定してるだけ、俺はCLIで十分

2025/03/07(金) 15:40:54.21

>>386
キーボードで16進数4文字打つのが非効率なの？マウス操作の方が早いの？
俺とは違う技術で生きてるみたいだな

デバッガやプロファイラは自作スクリプト経由のことが多いな、スクリプトなしで簡易にやるならエディタのマクロ

2025/03/07(金) 17:31:19.43

>>391
タイピングの問題でなく目視でハッシュを確認ってのが非人間的で非効率って言ってんの
そういう受け取り方をするってことはやっぱりUI/UXの視点が欠如してるんだよお前は

でデバッガをスクリプトで使うとは恐れ入った
全く別世界に生きてるのは同意

2025/03/07(金) 18:54:27.19

>>392
良く分からんが目が悪いの？
普通はタグとか検索結果からの相対指定で使うんだよ
何らかで間違ってタグを消したとかごく稀にどうしてもハッシュ値で指定したい時に、年に1回くらい目視確認で4桁の数字打つだけだよ
簡単なんだけどなあ

2025/03/07(金) 19:04:16.99

チーム開発だと、かなり前の特定のコミットをrevertしたりcherry-pickしたりは全然珍しくないけどなあ

2025/03/07(金) 20:04:21.73

GUIならHash目視しないのかな

2025/03/07(金) 20:40:14.65

仕事でチーム作業してたらハッシュは4桁では足りないからやっぱ手打ちはヤダな
バグトラッカーやクラウドのツールと交互に使うからマウスに持ち替えずにキーボードだけであらゆるGit操作を駆使！スゴイ腕前！とはならないかなあ
やっぱり達人は5chもcurlで書き込んでんのかな

2025/03/07(金) 20:58:11.36

>>394
そもそもそういうのはref検索とかで指定しない？
ログを目視しながらハッシュ値を探したりしないと思うんだが
ハッシュ値で指定することなんてめっにないんだから気にする時点で何か効率の悪いことしてる気がする

2025/03/07(金) 21:01:27.92

GUIやCUIの原理主義者じゃない限り
どっちでも使いやすいところで使い分ければ済む話だろ
ただ、GUIに関しては、CUIのコマンドオプションの何を行うコマンドかが分かる程度に表記してほしい
英語表記でも微妙、日本語ならばなおさら困惑する
できればCUIのコマンドオプションを併記してほしい

2025/03/08(土) 00:55:57.26

ハッシュ値指定しない人は多分GitHub使ったことないんだと思う

2025/03/08(土) 11:24:47.06

Git v2.49.0-rc1

2025/03/08(土) 11:29:06.73

>>400
ChangeLogに以下の説明があり、Git3.0にむけてbreaking changeがある模様

* Following the procedure we established to introduce breaking
changes for Git 3.0, allow an early opt-in for removing support of
$GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure
remotes.

2025/03/08(土) 12:22:24.00

githubで全然草生やせないんだけど

2025/03/09(日) 18:13:33.28

>>356
gitk 見ながら CLI 操作ってのが個人的には最強

2025/03/11(火) 10:16:27.19

Git v2.49.0-rc2

2025/03/15(土) 12:09:57.15

Git v2.49.0

2025/04/08(火) 16:01:12.91

「Git」誕生から20周年を記念してリーナス・トーバルズ氏が開発初期の裏事情や使用頻度の高いコマンドなどを明かす
https://gigazine.net/news/20250408-git-20-years-linus-torvalds/

2025/04/09(水) 16:03:54.93

複数ファイル名を入力するときはGUIでポチポチ選択したい

2025/04/18(金) 20:54:17.74

10日で開発したL・トーバルズ氏も想定外？--「Git」誕生から20年、定番VCSの軌跡とその影響
ps://japan.zdnet.com/article/35231917/

2025/04/27(日) 17:55:28.09

このスレッドはLinux開発のGitの世界を語りだす気持ち悪い人間がいるから困る

2025/05/15(木) 13:14:12.18

最新版で行ったバグ修正の部分だけを旧バージョンにも適用したい場合、チェリーピックを行うことになりますか？
その場合、ログの樹形図には、このコミットを持ってきたよという線は作られずに、別々の作業という表現になってしまいますか？

2025/05/15(木) 13:54:33.66

>>410
それであってるよ

直接 cherry-pick せずにバグ修正だけ入ったブランチを作ってそっちをマージという形にするやり方も一応あるけど大した違いはない
系統樹にはならないのでコミットログにどこから cherry-pick したかを残しておく（変なオプション使わなければ勝手に残るよ）

2025/05/15(木) 17:08:27.77

>>411
ありがとうございます
旧バージョンのこういうメンテナンスは、チェリーピックを使っていくことになるのですね

2025/05/15(木) 17:42:53.69

>>412
親子関係にない（できない）間でのパッチの流用は cherry-pick でやるのが基本
git のコードの移動は（特殊なの除くと）merge, rebase, cherry-pick の3つだけ
逆に言うと cherry-pick は最重要3役のひとつ

2025/05/15(木) 18:00:11.34

rebaseってcherry-pickの繰り返しと同じじゃねーの？

2025/05/15(木) 20:13:23.49

>>414
似てるけど違うよ、オプションにもよるけど
●rebase は今いるブランチを移動させる
○cherry-pick はよそのブランチからコピーしてくる
コピーとムーブの違い、方向も逆なので注意
あと cherry-pick も範囲指定で複数一度にコピーできるよ

2025/05/15(木) 20:20:09.57

>>415
rebaseしても元のコミットは残ってるからmoveじゃないし

2025/05/15(木) 20:35:51.71

>>416
何言ってるわからん
ブランチを移動させたらもとのブランチはなくなる（ブランチに所属しなくなったコミットは後からガベコレで消される）
もちろん別の名前でブランチが残っていればそっちは移動してないのでコミットは消されない

2025/05/15(木) 21:36:14.90

>>417
gitにコミットのmoveなんて概念ないでしょってこと

2025/05/15(木) 21:39:50.81

>>418
概念はある
実装が移動先にコピーして後から削除になってるだけ（主に undo 用にしばらく残してる

2025/05/15(木) 21:48:52.03

mergeもcherry-pickもrebaseも普通に新しいコミットを作る
そのコミットの作り方がユースケースに応じて3種類あるってだけのこと

2025/05/15(木) 22:25:09.18

>>414
同じだよ

2025/05/15(木) 22:42:29.15

>>419
だからハッシュ番号変わるんだからmoveじゃないって
自分でも元が残ってるって言ってんじゃん
その理解大丈夫？

2025/05/15(木) 23:05:28.17

>>422
コンピュータ技術ではコピーして元のを消すのもムーブいうんだよ IDとかアドレスが変わってもムーブって呼ぶの
知らなかったの？勉強になって良かったな

2025/05/16(金) 00:59:49.81

円錐を横から見た人が三角だといい下から見た人が丸だというような構図ですね
人は争いをやめられないので滅ぼすしかないですね

2025/05/16(金) 01:36:29.34

>>423
そもそもコピーじゃないからな
コミットの内容は元とは完全に別物であり、差分だけが再現されている
勉強になって良かったな

2025/05/16(金) 08:05:25.71

>>425
幼稚園児か？
完全一致じゃないとコピーじゃないとか言いだしたらファイルコピーとかも所有者とか日付とかいろいろ変わるのコピーじゃなくなるぞ
git のは日付とか作者は変わらないのでまだ保存性高いぞ

cherry-pick と rebase が一緒なんて恥ずかしいこと言ったの話をそらしてごまかしたいんだろうけど無理がありすぎる
cherry-pick は元のが消えない、rebase は元のが消える、方向も逆、べつもの、あきらめろ

2025/05/16(金) 09:43:07.63

>>426
分かって言ってるのかどうか知らないけど、日付が変わるとかのレベルじゃなく、そもそも差分箇所以外は原理上全くの別物よ
変更内容のムーブというならまだしもコミットのムーブは流石に意味不明

2025/05/16(金) 10:35:41.49

>>427
誤魔化すな rebase と cherry-pick は別物、元が消える(ムーブ)のと、消えない(コピー)の違い
ここで言ってるのは元が消えるかどうか、完全一致とかの話題ではない

2025/05/16(金) 10:46:52.99

rebaseで元は消えないでしょおじいちゃん

2025/05/16(金) 10:57:16.90

>>429
もしかして誤魔化してるじゃなくて本当に分かってないの？マジ？

2025/05/16(金) 10:59:28.32

まあ公式が同じだって言ってるしなあ

2025/05/16(金) 11:09:39.47

0┳A━B
┗X━Y
を
0━A━B━X━Y
にする時に使うのが rebase
0┳A━B━X━Y
┗X━Y
にする時に使うのが cherry-pick
基本中の基本

2025/05/16(金) 11:30:53.42

いやどう考えてもそのレベルの話は全員わかってるやろ
この一連のやり取りに足りないのは知識でもIQでもなくEQ
お前ら小学生からリベースしろ

2025/05/16(金) 11:33:59.63

>>430
rebaseはcherry-pickで新しいコミットが作られてそっちに単なるポインタであるブランチが移動したのと同等
コミット消すとか移動とかいう動作は含まれない
どこからも参照されなくなったらいずれgcで消えるってだけ

2025/05/16(金) 13:50:52.44

英語が下手でコミットメッセージを書くのが苦手だったんだけど、AIで自動化したら快適になったぜ

2025/05/16(金) 14:44:19.53

>>435
そうなるともう、ログなんか書かなくていいんじゃないのとなってくるな

2025/05/16(金) 14:58:50.14

>>434
cherry-pick と rebase は別物って納得したんだな

2025/05/16(金) 15:09:24.62

rebase の内部動作の話するんなら
1. 分岐点を自動で探し出す
2. 分岐点からヘッドまでを対象の場所へ cherry-pick する
3. 元の場所のブランチ名を消す
4. 新しい場所にブランチ名をつける
5. ガベコレで古いブランチのコミットが消える
これを cherry-pick を繰り返すのと同じだと主張してる時点で何も分かってない

2025/05/16(金) 15:11:49.54

moveなんてアホな説明しなけりゃよかったのにね

2025/05/16(金) 15:18:53.26

>>439
移動してるだろ 432 見たら一目瞭然
コレが基本概念
内部実装の話しして誤魔化そうとしてても、お前が間抜けなこと言った時事は消えない

2025/05/16(金) 16:07:30.58

>>435
英語で直感的にヤバい時のメッセージに気付く訓練もいるから、AIは使えばいいけど読み書きの練習はしておけよ、と思った。

2025/05/16(金) 18:15:56.05

とりあえずDt80は一度公式読んできなよ
たかが間違って覚えてたところで誰も煽りやしないよ
あと描いてたツリーで、XだのYだのをリベースなりチェリーピックなりしたやつはXダッシュとかYダッシュとかにしよう
そこだけ流石に同じ文字じゃ読んでてちょっと気持ち悪すぎる

2025/05/16(金) 18:36:45.50

>>442
今でも「rebase は cherry-pick を繰り返しただけ」と主張してるの？
そんな覚え違いしてるのお前だけだろ、この通りの文言があったらポインタ示してみろ

どっかの変なサイトが誤訳してるのなら知らんが rebase は cherry-pick してるだけじゃないことはお前も完全に理解できてるだろ

2025/05/16(金) 21:29:57.00

このページのgit rebaseの項に書いてあるよ
https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Patching

2025/05/16(金) 23:12:54.87

>>444

どう訳したらそう誤解するんだ？別物だというのは文章から明らかだろう

エスパーしてみると
違うからこそ basically ってわざわざ明確に書かれてるに、もしかして basically て単語知らなかったとか？
native のつかうbasically は「基本部分では、だいたいにおいて」みたいなニュアンスで、本当に同じ時には使わない
「だいたい同じ」を「同じ」って覚えてたんじゃないの？

**デフォルトの名無しさん** (JP 0H27-s4bX) · 2025/05/16(金) 23:28:45.03

>>445
さすがに苦しいぞ

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埋め込みにすればいいんじゃね？