Git 20

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のおかげで移行するメリットは説明しやすくなったと思うけど

2025/10/30(木) 13:33:16.77

移行できないのは無能のおっさんだけだけとな
若い奴らは学校で使ってたし、できるやつは仕事以外などで当然git使った経験ある

2025/10/30(木) 15:54:37.40

まあ苦労を愚痴るくらいはいいだろう
けど一度両方に使い慣れるとソース管理でSVNを選ぼうとする人間はほぼいなくなる
心理的ハードルの高さを理由に未だに挑戦すらできないのは自身の経験からしか学べない愚か者か情弱か、周囲が低スキルの作業者しかいない色々諦めてる人かなと思う

2025/10/30(木) 16:29:49.89

何をしたいかによるな
ちゃんと手間暇かけて記録を残して共有したいのなら git は素晴らしい
某バケツくんのようにバックアップ取りたいだけなら svn でも過剰機能

2025/10/30(木) 17:05:22.68

某バケツ/長文くん...
GitHab 他で、外部のホスティングサービスを使うのが普通になるなんて10年前には、中々考えにくかったね。
Git の力は凄いね。

2025/11/03(月) 13:15:47.38

オンプレや望むならローカルでもGitLabのCE版やGitBucket使えば出来るけどなあ。
VisualSVNほどお手軽ではないけど。

2025/11/13(木) 20:41:16.25

Gitはいろんな使い方ができてしまうことがあだとなってしまっている。

2025/11/13(木) 20:48:42.86

Gitって、
Pullして自動でソースコードをマージってできないの？

2025/11/13(木) 23:03:52.93

>>553
pull って単に「fetch して merge 」の省略形なので当然 merge されるが
何を聞きたい？

2025/11/15(土) 07:14:55.95

マージ・シンプソン

2025/11/16(日) 09:33:15.00

ブランチやFork切ったやつを本流にPR通さず自動的にマージしたいってことかな。
答えは「できない以前に絶対にやるな」だけど。

2025/11/16(日) 10:11:35.18

Excelファイルで更新し合ってケンカになるタイプだろ

2025/11/16(日) 13:13:38.57

.xls .xlsm .xlsx は .gitignore すべし

2025/11/16(日) 13:48:39.22

>>556
puah は他リポジトリへのマージなので push 権限もってれば普通にできるが
何がしたいの？

2025/11/16(日) 13:54:18.17

git は色々柔軟な使い方ができるんだが
質問するやつも回答するやつ自分の使い方限定で詳細言わずにやり取りするせいで
何をしたいかさっぱり

2025/11/16(日) 20:37:45.50

質問してるやつも戻ってこないし本気で解決する気ないんだろ
ほっとけ

2025/11/17(月) 20:05:10.72

>>554
ローカルに変更がある場合、
それを一回commitしてから、pullするとマージされるんですかね？
そのへんがわかりませんでした…

2025/11/17(月) 21:28:52.94

疑うぐらいなら自分の手元で試したらいいだろカス

2025/11/18(火) 02:15:32.71

>>562
当然される。むしろそのためのコマンド
pull は remote のブランチを取ってきて local のブランチにマージするために使うのが基本
取ってくるだけなら fetch コマンドを使う

2025/11/18(火) 06:57:03.10

>>564
いや、そういう質問意図じゃなくて、
マージしたいけど、commitしないとマージできないんだなと…

ありがとう

2025/11/18(火) 08:50:56.32

>>565
用語を誤解してるのかな？
「マージ」というのはリポジトリのブランチに対して「新しいコミット」をつなげる作業なのでリポジトリに入れていないワーキングツリー上のみの変化は対象外
矛盾が出る場合は警告が出て失敗する

現在の変更作業中のものをコミットせずに pull したい場合にはいったん stash に退避して pull した後に stash pop でワーキングツリーに再反映させるのが基本

2025/11/18(火) 09:45:22.80

マジ卍

2025/11/18(火) 11:21:49.31

>>565
先にコミットしないといけない理由はプルで競合したりミスを後悔したり後から気づいたときに変更が混ざってうまく戻せなくて詰むから
わざわざコミットが必要なのかと感じたならその考えが古い
Gitのコミットはプッシュするまでは単なるセーブポイントみたいなものでしかないのでコミット後に切ったり貼ったり戻したり自在にコントロールできる
リスクのある面倒事はセーブしてからやろうねという親切設計

2025/11/18(火) 12:43:24.98

分かるんだけど聞きたかったのは多分そういうことじゃないと思うよw

**デフォルトの名無しさん** (ｽﾌｯ Sd22-A2v6) · 2025/11/19(水) 10:20:49.06

commit して push する前に merge すれば医院で内科医

2025/11/19(水) 14:59:07.00

mergeでcommitする5秒前

2025/11/20(木) 00:40:42.89

ステージング機能マジで有り難いな
及第点のコードを一旦ステージングで確保してからさらにcopilotに書いてもらって、壊れちゃったら破棄、みたいなことが何度もできる

2025/11/21(金) 18:29:40.27

TortoiseGit使ってる方いますか？
2.18.0になってから、特定の日本語フォルダ(「その他」とか「あああ」とか)の下にクローンしてくると、
TortoiseGitから何かを行うだけで落ちて、drdump.comに報告が送られるのだけど、
これって作者の方たちには伝わっているということですか？

2025/11/21(金) 21:33:57.40

質問は伝わってるかどうかなんだw

2025/11/22(土) 00:17:06.76

>>573
伝わってますよ
いい結果になることをじっと(Git)待ちましょう

2025/11/22(土) 11:22:51.10

>>574-575
言語特有の問題っぽいし、日本人開発者のサイトも見当たらないし、
落ちてる関数などが伝わっているのならあとは待つしかないかと思いました。
ちなみにこれ、他の方の環境でも起きますよね？

2025/11/22(土) 19:00:06.30

>>576
英語できないヘボなんか知らんが今時AIでなんとでもなるやろがい
このページぐらい自力で見つけて読め
https://tortoisegit.org/support/

2025/11/23(日) 14:38:29.81

>>576
↓日本語とWindowsで思い当たるならこれかな
git config --global core.longpaths true
git config --global core.quotepath false

これでダメなら自分でissue投げたらいいんじゃないかな?
https://gitlab.com/tortoisegit/tortoisegit/-/issues

ただTortoiseGitはGitの機能フルに使えるわけじゃなくアジア圏でユーザーがほとんどいないんじゃ？
Windowsなら、ほぼSourceTree一択な気が。

2025/11/23(日) 18:39:23.92

>>568
ソースコードを混ぜたいんですが、
commit後にpullすればいいんですかね？

あと、stagingした後、変更してcommitしたとき、
その変更はcommitされないんですかね？

2025/11/23(日) 19:07:48.40

コード混ぜたいなら、stash利用するか、今編集してるのとは別のフォルダにcloneしてから、winmergeなんかで
手動でマージすりゃいいんじゃないの?

2025/11/23(日) 22:26:15.51

>>578
TortoiseGitはあくまでエクスプローラー拡張として入れてるな
メインはVSCode＋拡張機能が一番使いやすいと思う

2025/11/26(水) 12:25:25.04

>>578
GitLabのアカウントを持っていないので保留してたけど、誰かが同じ問題を投げたみたいで、
マルチバイト文字のフォルダで落ちるというIssueが増えてました
SourceTreeも試したことあるけど、個人的には使いにくかったです

2025/11/28(金) 06:06:01.80

>>582
投げた人ですが修正がcommitされてcloseされたでって通知が。
日本語コード領域だけの現象とか謎過ぎ。

2025/11/28(金) 09:25:15.69

>>583
ありがとうございます。
「ああああ」などの偶数文字数は大丈夫で、「あああ」などの奇数文字数だと落ちるとか、
よくわからない現象でした。

2025/11/28(金) 17:55:15.74

おまいらどうやって鍛えた？

2025/12/01(月) 21:05:40.66

会社で使ってますが、
commitしないで、ソースコードをGitHubから落としてマージできないんですかね？

commit履歴は残したくないので…

2025/12/01(月) 22:00:34.57

>>586
マージはコミットの一種なので、言葉通りに解釈するなら不可能
お前が何故そんなことをしたいのか、目的を教えてくれたら適切なアドバイスができる可能性はある

2025/12/02(火) 00:28:36.40

多分無能やろな

2025/12/02(火) 02:17:51.61

>>586
変更したファイル(仮にA.txt)を別名ファイル(仮にA_20251202編集中.txt)でどこかに移動
git checkoutで変更前に戻す
ソースコードをGitHubから落とす
WinMergeでA.txtとA_20251202編集中.txtを比較して手動で変更点を取り込む

素晴らしい
誰にでもできる

2025/12/02(火) 06:13:08.87

>>589
そんな古いやり方はけしからん！
git checkoutではなくgit restoreを使う
これで完璧だろ♪

2025/12/02(火) 06:52:09.73

>>587
目的は、
余計なコミットを増やしたくないので

2025/12/02(火) 06:52:37.60

>>589
まあ、
これは原始的なやり方ですね…

2025/12/02(火) 06:53:49.44

>>590
まあ、
結果としては同じでしょ？

2025/12/02(火) 06:55:06.22

>>589
↑
これを素早くやりたい
ファイルが100個とかある場合

2025/12/02(火) 07:36:35.04

>>594
git pull —rebase

2025/12/02(火) 08:00:27.10

一回コミットを作成してコピーを取ってコミットを消せばいいんじゃないの？
別ブランチにしとけば良いだけなのに、何ためにコミットを残したくないのかわからないけど、コミットなんて自由に消せるだろ

リポジトリに一切変更を入れたくないのなら git diff で差分を取り出して patch コマンドとかもできるけど、git 使う意味は？

2025/12/02(火) 09:06:25.08

「commit履歴は残したくないので…」
理由は？
「余計なコミットを増やしたくないので」
まともな会話に期待する方が無理じゃね？
ネタだろ
マージコミットを潰しリーダーがあとでレビューとコンフリクトで苦しみ、権利関係のあやしいコミットをこっそり取り込んで上司が青くなる

2025/12/02(火) 09:32:54.59

手元の作業中のブランチに対して上流からのマージコミットを残したくないという意味なら、普通にあるrebaseのユースケースでしょ
1コマンドでやりたいなら>>595で終わり

2025/12/02(火) 12:06:56.01

>>598
用語の問題なの？
rebase でもコミットは残るだろ

merge commit じゃなければ残っても良いの？
branch 切ってそっちに commit 残すのは駄目なの？

2025/12/02(火) 12:36:20.96

履歴残したくないって、gitが非同期分散ってのわかってないんじゃねーの？

2025/12/02(火) 16:52:38.92

後できれいに履歴を簡単に齟齬なく編集できればこんなに悩むこともないんだけどねぇ

2025/12/02(火) 17:33:10.55

Gitにコミットしてはいけないファイル（例えば password.txt）をコミットしてしまいました
すべての履歴から完全に削除する方法を教えてください！

2025/12/02(火) 17:49:58.41

git rebase -iでがんばれ

2025/12/02(火) 20:13:02.23

>>595
git pull —rebase
↑
やってみたけど、エラーが出ました…

2025/12/02(火) 20:13:50.78

>>599

rebaseでも履歴は残りますね…

2025/12/02(火) 20:15:37.22

>>596
↑
結果としてはこれかな

チーム開発なので、余計な履歴は残したくないという意図です…

2025/12/02(火) 20:18:31.25

>>606
pushしてpullリクエストしてる間に、ローカルで色々実装して、
リモートではその一時ブランチがマージされたけど、それをローカルに落とせない感じです…

2025/12/02(火) 23:40:44.84

>>607
ローカルの変更はコミット前ということなら
git stash って知ってる？

例えば
git stash
git pull
git stash pop
ってやれば良いだけの話だったりしない？

2025/12/03(水) 01:46:06.58

履歴残さない方がいいってどんだけクソ開発チームだよ
愚かすぎるわ

2025/12/03(水) 01:54:14.66

>>602
それはもうPCを破壊するしかありませんね！

2025/12/03(水) 04:59:41.43

>>606
こんだけわかってない人がチームに居るとか気の毒だな

2025/12/03(水) 11:44:52.15

>>608 が正解
は置いといて
>>602 は
push する前なら commit --amend するだけ
push してしまってから気付いたのが push 直後なら速やかに commit --amend して push -f
気付くのが遅れたらアキラメロン

2025/12/03(水) 20:30:47.60

>>608
それかもしれません
それでソースコードがマージされる？
試してみます

ありがとう

あと、--autostash　ってのがありますね…

2025/12/03(水) 21:15:29.61

アホにアホな使い方教えるの犯罪だろ

2025/12/04(木) 00:19:41.31

GitHubに「stashしてmerge」ボタンあるでしょ？
PRでレビューでガンガンに修正push/commitしても最終的には綺麗にできる

2025/12/04(木) 06:41:15.57

>>615
確認してみます…

現在は、主にPRを出す側です
WIndowsかLinuxで…