Git 20

1 名前：デフォルトの名無しさん mailto:age [2024/02/15(木) 09:50:09.07 ID:En27mXas0.net] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git git-scm.com/ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja Git入門 www8.atwiki.jp/git_jp/ ◆前スレ Git 17 https://mevius.5ch.net/test/read.cgi/tech/1599016710/ Git 18 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 44 名前：デフォルトの名無しさん [2024/11/02(土) 19:40:13.72 ID:5OmbLV2R0.net] gitでファイルを管理したいです というのも、あるide上で削除したファイルは完全削除になり、ゴミ箱に移動されません またリドゥも出来ません だから定期的にgitに保存して、そこから復元という形になるみたいです しかし、例えば10秒に1回ファイル削除をした場合10秒ごとにリポジトリに保存しなければいけないのでしょうか 自動化はできそうですが、凄まじく面倒です 45 名前：デフォルトの名無しさん [2024/11/02(土) 19:55:48.59 ID:fimlNyEi0.net] 何も難しくねーんだから自動化すれば良いだろ 凄まじく面倒なんて言い訳は頭が悪いことを自白しているようなもんだ 46 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 71b8-jwtj) mailto:sage [2024/11/03(日) 05:29:56.13 ID:3rcZcbik0.net] gitの用途間違えてるよ 高頻度で削除するようなファイルを復元したがるケースがまず不明 どのIDEでどんなプロジェクトをどう運用してるか説明したほうがいい 本当に実現したいことに対して手法が間違ってる気がする 47 名前：デフォルトの名無しさん [2024/11/06(水) 12:12:04.99 ID:spMsN6R20.net] Gitの使い方のルールが明文化されていない職場が増えた 48 名前：デフォルトの名無しさん mailto:sage [2024/11/06(水) 15:17:18.19 ID:wtWzgVpw0.net] >>47 どんなルール？ 49 名前：デフォルトの名無しさん mailto:sage [2024/11/06(水) 20:07:20.18 ID:4GufIMK30.net] 職場でのルールってことでしょ Git自体にルールはないよ 50 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ b25c-xN5v) [2024/11/07(木) 08:56:52.06 ID:JbCijT/T0.net] そりゃそうだろ何の話してると思ったの?w 51 名前：デフォルトの名無しさん mailto:sage [2024/11/07(木) 23:37:53.08 ID:Ivqaow380.net] >>44 そんなに頻繁にファイル消すてどういうプロジェクトなんだろう？ 削除せずに、ゴミ箱的なフォルダに移動するとか、ファイルをリネームするとかで どうにかならないの？ 52 名前：デフォルトの名無しさん mailto:sage [2024/11/08(金) 04:47:19.41 ID:x510xVeP0.net] git は履歴保管箱じゃねーぞ 変更点の採用/不採用や再利用や順番の入れ替えなどをする道具だぞ 履歴の保管はそのための単なる手段だぞ ファイル保管の道具と勘違いしてるやつが多過ぎる、特に他の VCS から移ってきたやつ 53 名前：デフォルトの名無しさん mailto:sage [2024/11/08(金) 16:10:07.37 ID:9cqAhTbE0.net] またお前か 54 名前：デフォルトの名無しさん [2024/11/08(金) 18:49:52.14 ID:y8v+DuF60.net] >>51 彼はIDEとGitの二重管理がしたいらしいが、二重管理そのものが良くないと教えてやってよ。 55 名前：デフォルトの名無しさん [2024/11/08(金) 18:51:25.49 ID:y8v+DuF60.net] >>52 それはGitではなく、GitHub、GitLabなどのGitのホスティングサービスのことだ。 56 名前：デフォルトの名無しさん mailto:sage [2024/11/09(土) 11:14:39.71 ID:/e9Pqeqm0.net] チェックインチェックアウト型の方が合う職場の方が多いけどgit原理主義者がジャマをする 57 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ad6e-xvOx) mailto:sage [2024/11/10(日) 23:26:27.94 ID:7LupYrhE0.net] ファイルを弄ろうとした瞬間にダイアログが自動で開いて お前は一体何のためにこのファイルを編集しようとしているんだ？ と意図を聞いてくるようなguiのgitクライアントやエディタってないの？ コミット時のコメントを先に書くようなの 58 名前：デフォルトの名無しさん mailto:sage [2024/11/13(水) 18:08:56.60 ID:LKqY2Vyg0.net] それ必要ある？ 煩わしいだけだよね 59 名前：デフォルトの名無しさん mailto:sage [2024/11/14(木) 16:08:53.18 ID:owZ2H+n10.net] やることを明確にしてから手を動かす癖をつけるには悪くないアイデアだと思う しかし強制力がないと結局煩わしいだけで終わりそうだから、宣言した内容から逸れるような変更をAIが検知して電気ショックを与えるような仕組みとセットだな 60 名前：デフォルトの名無しさん mailto:sage [2024/11/14(木) 17:05:51.92 ID:rZHGzr+/0.net] 基本的に git はコードを書いてから、それをどのように他人に見せるか考える仕組み 最初に目的を書くとか git ではありえない 他の VCS 使え、無理して git を使う必要ないぞ ステージが何のためにあるのか分かんない奴、ステージの便利さが分かんない奴は他のを使った方が幸せだと思うぞ 61 名前：デフォルトの名無しさん mailto:sage [2024/11/14(木) 18:05:15.86 ID:QfnZRB7z0.net] そりゃ暴論だな Git自体は開発ワークフローではなくソースコードを管理するツールだから、UNIX的ミニマリズムの帰結でそうなってるだけの話で、 開発ワークフローとして先にコミットメッセージを決めちゃいけないわけではない そういうワークフローをサポートする周辺ツールを作ればいいだけのことで、それを妨げるものは何もない 62 名前：デフォルトの名無しさん mailto:sage [2024/11/14(木) 18:59:29.63 ID:1DNjm3wn0.net] なんかGitと関係ない気がする 63 名前：デフォルトの名無しさん mailto:sage [2024/11/14(木) 19:39:03.69 ID:JxemxwF40.net] GitにはSVNのneeds-lockに相当するものはない 開発のスループットを上げるためにロックの考えは省いて競合解決はなるべく機械に頼る そのあたりの思想やポリシーはリーナスが語ってたはず 彼が自分のために作ったツールだからそのあたり色濃くコマンドに現れてる だがフロントエンドの開発を妨げるものはなにもない 必要だと思ったやつが自分で作ればいい Git自身の思想とは別ベクトルを向いているので特殊でマイナーな用途のうちに入るから巷で誰かが公開してくれている可能性は低いかもしれないな 64 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ e378-QmVt) [2024/11/14(木) 19:59:56.31 ID:knCj/+H40.net] 急にどうした 65 名前：デフォルトの名無しさん mailto:sage [2024/11/14(木) 20:17:06.85 ID:rZHGzr+/0.net] git の思想合わないのなら git以外を使えば良いのになんで git にこだわるんだろ git は汎用ニュートラルなツールじゃなくて思想性の強いクセがあるツール、その分はまったら手放せなくなるけど 料理で言ったらカレー粉レベル、カレー味にしたくない時に使うのはお勧めできない 66 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ e3dd-R46Z) [2024/11/14(木) 21:23:12.93 ID:5gfdBupH0.net] GitもSubversionも使い方は自由 67 名前：デフォルトの名無しさん mailto:sage [2024/11/16(土) 11:27:19.19 ID:mDoixnK70.net] 思想性にクセの無い VCS なんてあるんかいな 68 名前：デフォルトの名無しさん mailto:sage [2024/11/16(土) 14:54:04.41 ID:ahS7aS5o0.net] >>67 ないよ、だから自分たちの手法/考えにあったやつを使うべき 有名だからといって git 向いてないやつが git 使うのは不幸になるだけ git は素晴らしいツールだけど万人向けというわけではない 69 名前：デフォルトの名無しさん mailto:sage [2024/11/16(土) 16:46:21.48 ID:l/37O0wv0.net] >>67 何にだって濃淡はあるだろ あるなしの二択でしか考えられない1ビット脳かよ 70 名前：デフォルトの名無しさん mailto:sage [2024/11/16(土) 16:51:08.62 ID:ahS7aS5o0.net] >>69 濃淡といっても濃いやつかすごく濃いやつかの違い 薄いやつは存在しない もちろん自分の思想にあってれば空気みたいに感じて薄いと思うかもだが、他の人にとっては猛毒という個人差 71 名前：デフォルトの名無しさん mailto:sage [2024/11/16(土) 17:05:38.74 ID:l/37O0wv0.net] >>70 うん、だから >>63 はGitはかなり濃い目の部類って言ってるんだよ 72 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 11:09:45.68 ID:1w/WFdpP0.net] いやわかるんだけどさ、適材適所にならずにgitが一番、git使うのが正しい、gitも使えないような奴ぁ、みたいにいらぬ波風を仕事で起こす迷惑な原理主義者が実際多いのよ 73 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 11:57:45.29 ID:XBj9RB2E0.net] たかがソースコードのバージョン管理に適材適所とか多様性とか要らん くだらん自転車置き場の議論で時間を無駄にするだけだから問答無用でgit一択でいい ゲーム開発で巨大なアセットを管理する必要があるように管理対象の性質によって他を選ぶのは仕方ないが、 些細なワークフローの問題で他の選択肢を検討するべきではない 74 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 12:30:40.26 ID:4bPBMVA80.net] >>73 git 使う理由を考えろ お前みたいな変なのがいるから、git でロックしたいだの、事前にコミット・メッセージ入れたいだの的外れなこと言い出すやつが湧いくことになる git 使うんなら git のワークフローになるし、他のワークフローにしたいのなら他の VCS 使うべき （全部が一緒に見えるアホはどれ使っても駄目だが） 75 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 14:21:11.61 ID:Mcc4e1u50.net] Gitのワークフローなんてものは無い 個人の小規模開発では、手元のフォルダ上でデフォルトブランチにコミットするだけの使い方も多い GitHub使ったクローズドな組織での開発では単一のリモードリポジトリで作業する中央集権型のワークフローが普通だ 一方で、OSSではフォークして互いにpullし合うのが一般的だろう 素のGitにはレビューやコメントもなければCI/CDもなく、マージやデプロイを承認するような機能もない それらはあくまでGitと直行するものとしてGitHubによって自然な形で実装されたものだ GitはLinuxカーネル開発のワークフローを前提として設計されたものではあるがGitそれ自体はワークフロー中立であり、 多様な使い方を受容することがGitがこれだけ広く普及した大きな理由だ 76 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 15:03:16.35 ID:GO7/5tRJ0.net] svnはバイナリも差分で保存してくれることは覚えといて損はないぜ 脳死でgit一択なんてこたーない 77 名前：73 mailto:sage [2024/11/17(日) 15:08:32.39 ID:Mcc4e1u50.net] >>76 よく読んでくれ 俺は管理対象の性質に応じて選択することは否定していない 78 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 18:01:53.15 ID:hkK5KPG+0.net] >>75 もっと大きな部分を考えろ 分散して手元で開発 複数の人が同じファイルを並行して作業 ロックを取らずにマージ時に調整 ステージングでパッチを読みやすく整形 リベースでチェインを整形 個別ロックのかわりにブランチを使う みたいなのも全部ワークフローだ git 使ってると当たり前過ぎて空気になってるだけ、中央集権とかだけがワークフローじゃない 79 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 18:22:05.70 ID:hkK5KPG+0.net] Q. バッティングするといやなのでロック取りたいんだが A. ブランチ切れ、自分専用ブランチならバッティングしない Q. 作業開始前に今からする作業の説明保存したいんだが A. ブランチ切ってブランチの説明を追加しろ だいたい git のワークフローに適した代替のやり方がある 個人ごとで保管すべきものが何で、全員で共有すべきものは何か？ という根幹の考え方が VCS ごとに違っている 80 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 18:43:36.44 ID:hbhRcMl00.net] だからそういう話だろ？ なんか勘違いをしているようだが、質問者はあくまでクライアントの話をしている 自分の手元で自分以外誰も見ないし触らないブランチでやる分にはロックしようと自由だ 81 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 19:09:27.90 ID:hkK5KPG+0.net] >>80 ロックは自由だ LとR間違ってないか？ 何のため誰のためのロックの話？ 82 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 19:28:00.48 ID:hbhRcMl00.net] だから>>57の通り、メッセージを先に書きたいだけでしょ そもそもロックしたいとは言っていないが、実装するなら少なくとも手元のブランチに対する排他制御は必要だろうね 83 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 19:37:35.19 ID:hbhRcMl00.net] いやブランチじゃなくてリポジトリに対しての排他制御が必要か コミット前だからどうせブランチは切り替えられないもんね 補足すると、自分で重複して同じクライアントを起動することによる競合を防ぐことを目的とした、同一PC上の同一のクライアント自身に対する排他制御な 84 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 19:51:48.68 ID:odgQ051H0.net] ソースコードの履歴管理上の排他制御とリポジトリ内部の整合性を保証するための排他制御がごっちゃになってない？ 85 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 20:35:32.55 ID:Jr+9HLroM.net] なんでGitはおかしな原理主義者出てきやすいのだろう？ そりゃGitの〜を使えばできます、は事実ですだろう でも無理してなんでもかんでもGitでやる必要ないよなあ どうも原理主義者くんはこの用途はこっちのバージョン管理ツールが合ってる、と言われるとGitにはその機能がない、と責められているように聞こえるらしい 86 名前：デフォルトの名無しさん mailto:sage [2024/11/17(日) 21:12:22.55 ID:9BT2IQwv0.net] git 以前にプログラミング向いてないやつがいるな 「ローカルでエディットしてるファイルを排他したいだけなら VCS じゃなくてエディタのロックの仕事」 って言われたら顔真っ赤にして反論するんだろうか？ 87 名前：30 mailto:sage [2024/11/17(日) 22:38:40.72 ID:G7eUir2J0.net] git一択と言ってる奴いて草 これが原理主義か怖いねえ😱 88 名前：デフォルトの名無しさん [2024/11/18(月) 23:21:35.04 ID:cZsx9Sbk0.net] 日本人はやたら正解があることにしたがるが、外国人は正解が複数存在するという考えだから発展する。 89 名前：デフォルトの名無しさん mailto:sage [2024/11/19(火) 07:05:59.68 ID:8dOnv38L0.net] >>85 > なんでGitはおかしな原理主義者出てきやすいのだろう？ 馬鹿がイキるのに丁度良い複雑さだから まともな人はコードに忙しくツールなんて出来るだけ疎かにするのもあって 90 名前：デフォルトの名無しさん mailto:sage [2024/11/19(火) 17:13:14.46 ID:ADRNByYj0.net] ゴミ箱くんが帰ってきたのか？ 91 名前：デフォルトの名無しさん mailto:sage [2024/11/19(火) 19:37:11.73 ID:dPz/0I6b0.net] >>90 思い出した。 専用のスレッド作ってもらっていて、2022/11/20だ。あれから2年か。 92 名前：デフォルトの名無しさん mailto:sage [2024/11/25(月) 16:12:49.15 ID:dXKNZcvG0.net] Git v2.47.1 93 名前：デフォルトの名無しさん [2024/12/02(月) 01:10:56.87 ID:rhvdeBiud.net] ファイルのパーミッションって保存されないの? 94 名前：デフォルトの名無しさん mailto:sage [2024/12/02(月) 09:32:52.91 ID:9ZwZTn5W0.net] >>93 実行権限以外は管理されない、git は保存ツールやバックアップツールでなくてコラボツールなので読み書き権限の管理は不要 Windows 使いとかで実行権限がうまくいかない場合は core.filemode=true 設定とか、--chmod とオプションとかを使うと良い 95 名前：デフォルトの名無しさん mailto:sage [2024/12/03(火) 09:10:05.62 ID:6hEsCuOf0.net] >>93 なんかバックアップと勘違いしてる人多いよね。 複数のPCで使う前提なのにパーミッション管理して何したいの？って思う。 96 名前：デフォルトの名無しさん [2025/03/13(木) 11:47:43.76 ID:AvSsTnXYq] 中学生カップ儿刺殺は盆暗議員どもが教育無償化だのほざいて税金もらいまくっていながら何イチャついてやがんだふ゛ち殺してやるって いつものロクに支援されない氷河期世代の仕業だったが石破茂も親御さんが死んだら住む場所も大変になるからリスキリングがどうたら 氷河期世代は無能とか決めつけて自宅で大人しくさせてりゃいいものをJАLだのАNΑだのクソヘリだのクソセスナだのテロリストに閑静な 住宅地まて゛騷音まみれにさせて藪の中の蛇をつつき出してんだからあれこれ事件を起こすのは当然だわな２0２5年は氷河期蛇が暴れまわる年に なること間違いなし大企業か゛無能集団でありながら年収１千万超なのは自民行政癒着による公共事業名目の補助金に日銀にまで金もらって 優越的地位の濫用と不正と犯罪で儲けてるからだからな例えばマネシタ電器とか企業とは無関係の個人が自宅で作ったソフトウェアを 著作権侵害のGｐL違反で繋ぎ合わせて小学生レベルのポンコツUIをちょこっと挿し込んでテレビやらに搭載して儲けてるだけなのが現実 航空燃料税リッタ１万圓にして最低所得保障する以外に有効な治安対策など存在しない (rｅf.)　ｔtрs://www.Call4.jp/info.php?tｙＰe=iΤems&id=I０000062 Тtps:／/hanｅda-ρrojecТ.jimdofreе.com/ ,　тtps:/／flight-rouＴе.com/ ttΡs：//n-souonhigaisosyoudan.amebaownd.Сom/ 97 名前：デフォルトの名無しさん [2024/12/03(火) 12:44:13.34 ID:yqFxGGnO0.net] >>93 されないね 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない 他のVCSには出来るものもあるんでそっちを検討するか、毎回シェルスクリプトを叩くか、置けるならGitのフックを使うか それこそドットファイルの管理なんかでマージとかはあんまり考慮しなく出来るなら、rsyncみたいな世代バックアップのツール使ってもいいかも 98 名前：デフォルトの名無しさん [2024/12/03(火) 16:09:40.34 ID:OOgT5lr40.net] perforceは出来るけどまああれだしな 後はそれこそRCSくらいしか思い浮かばないけど他になんかあったっけ 99 名前：デフォルトの名無しさん mailto:sage [2024/12/03(火) 17:16:17.61 ID:vojirIcj0.net] >>98 昔は、 新しいのは考え方や目的が違う、ファイル単位で読み書き権限の管理とかしたかったら今まで通りRCSとかCVS使い続けろ って言うのが常識だったんだが 100 名前：デフォルトの名無しさん [2024/12/03(火) 23:07:05.89 ID:bTlhOqOWd.net] >>97 >>98 なるほどありがとう そういうことならスクリプトでやるかな 101 名前：デフォルトの名無しさん [2024/12/05(木) 01:07:05.86 ID:PwliRaIW0.net] >>93 それはOSが管理しているのであって、ファイルそのものにそういう情報があるわけではない。 102 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 09:32:47.93 ID:BvdDuGAN0.net] んなこと言ったらファイル名もいらないって話になっちゃうぞ。 ファイル名はinodeではなくデータだとかいうツッコミは無しな。それこそファイルシステムの実装の都合に過ぎないんだから。 Gitがパーミッションを扱わないのはLinuxカーネル開発のソース管理においてそれを必要としないからで、それ以上のこじつけは必要ない。 103 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 14:04:38.28 ID:pujK8SSF0.net] xlsxとかxmlとしてバージョン管理できないの？しなくて良いのかもしれんが 104 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 15:31:26.26 ID:jrS77sb50.net] >>102 git 出てくる以前から svn とか他の分散型でも実行権限しか管理しないのが常識だったから linux kernel のせいにするのは間違い 105 名前：デフォルトの名無しさん [2024/12/05(木) 19:17:01.43 ID:xwxGapJaF.net] >>102 プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw 106 名前：デフォルトの名無しさん [2024/12/05(木) 19:17:26.14 ID:f+d6ZP2RM.net] >>102 プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw 107 名前：デフォルトの名無しさん [2024/12/05(木) 19:19:57.44 ID:f+d6ZP2RM.net] Windowsだってファイルにアクセス制御情報があるのではない。 DOSがディスクオペレーションシステムだと知っていれば、ファイルを管理しているのはOSで、ファイルがOSに指示しているという発想が出てくるはずがない。 108 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 20:15:24.74 ID:3xJzv6vp0.net] （この流れ早く終わらないかなあ） 109 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 20:36:07.99 ID:+3mg3S2k0.net] 必要な機能が欠けている、という事でしかないのでは。 実行権限だけ管理するというのもチグハグだし。 >>102 > それ以上のこじつけは必要ない。 完全に同意。 Git信者はGit一神教徒だから、Gitは間違ってない、間違わない、という前提で話をするからおかしくなる。 本当に間違ってないのであれば、更新する必要がない。ある意味CやHTMLがこれに近い。 Gitはツギハギだらけなんだから、パーミッションも今後は保存されるようになる、それの方が便利だから、というだけでよいのでは。 110 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 20:59:18.56 ID:jrS77sb50.net] >>109 逆に git しか使ったことないやつがこういう戯言言うよな 最近のメジャーな VCS は実行権限しか管理しないのが普通なのに git 特有の仕様だと思い込んでる。git 以前からなのに 111 名前：デフォルトの名無しさん [2024/12/05(木) 21:27:58.46 ID:mSFWhExMd.net] みなさんケンカはやめよう 112 名前：デフォルトの名無しさん [2024/12/05(木) 22:57:49.39 ID:i4nmZT4E0.net] しかし教科書ではきれいにブランチだのフィックスだのと理想的なバージョン 管理が語られるが、会社でそれなりの規模になってくるとユーザーもいろいろだし MSオフィスファイルや画像やとファイルの種別も多いのでほんとカオス化するなあ もうやだ 113 名前：デフォルトの名無しさん mailto:sage [2024/12/05(木) 23:18:07.05 ID:SPvCQMZG0.net] >>107 だからその理屈だとgitが実行権限やファイル名を扱えることを説明できないでしょ Linuxでは実行権限はメタデータだし、ファイル名はファイルではなくディレクトリのデータだ Windowsではファイル名はアクセス権限と同等のメタデータの一つだね 114 名前：デフォルトの名無しさん [2024/12/05(木) 23:37:35.74 ID:PwliRaIW0.net] >>113 それはGitの話ではなく、Gitの使い方の話だぜ？ 115 名前：デフォルトの名無しさん [2024/12/05(木) 23:38:42.52 ID:PwliRaIW0.net] >>113 ファイル名がパス名なのはUNIXの話でLinux独自の考えじゃない 116 名前：デフォルトの名無しさん [2024/12/05(木) 23:39:42.78 ID:PwliRaIW0.net] >>113 「メタデータ」の意味を取り違えていますけど？ 117 名前：デフォルトの名無しさん [2024/12/05(木) 23:42:05.86 ID:PwliRaIW0.net] このスレッドはLinuxにおけるGitのスレッドじゃねえのにな 118 名前：デフォルトの名無しさん mailto:sage [2024/12/06(金) 09:03:40.82 ID:fS/z7DY00.net] >>113 不毛だと思うが続けるつもりならシンボリックリンクを突いた方がいいのでは？ Gitに整合性なんて無いし、 Linusには不要だったから付いてないが、一般人には必要だから質問されるって事にしかならないと思うが 119 名前：デフォルトの名無しさん mailto:sage [2024/12/07(土) 15:04:30.30 ID:4vDr1gw70.net] 必要ならそのツールを使えばいいだけ。 GITではそんな機能はないと言うだけのこと。 120 名前：デフォルトの名無しさん [2024/12/08(日) 01:32:04.62 ID:69SzSHkA0.net] 随分ひどいが質の低いのが回答者側に回ってきてるのは悪いことなのかそれとも良いバロメータなのか 121 名前：デフォルトの名無しさん mailto:sage [2024/12/08(日) 09:44:23.06 ID:neBRud1Z0.net] 昔から専門系の板は簡単そうに見える質問が来ると極端な知識マウントで自己重要感を補おうとする人が湧くよ 今風に言うと「完全に理解した」人々ってやつ 122 名前：デフォルトの名無しさん [2024/12/08(日) 13:11:46.15 ID:1OHrCiTu0.net] 事故重要感って言葉初めて聞いた 123 名前：デフォルトの名無しさん mailto:sage [2024/12/08(日) 14:49:01.54 ID:VtvkCH1/a.net] 検索したら出てきたから使っている人いるんだね。 自尊心と何が違うのかは知らんし、どうでもいいけど 124 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 08:29:12.66 ID:oqd+iiqc0.net] 他人の作ったツールでマウント取ろうとしてる時点で頭おかしいけどな せめて「ぼくのすごいそふとうぇあ」でやれよと (この意味ではQiitaは正しい) それはさておき、 ・実行環境の全てを保存したい→パーミッションも全部保持して欲しい ・ソースコードの変遷が辿れればいい→パーミッションは全部755でいい 実行権限のあり/なしで動作が変わるシェルスクリプトなんて普通作らんし、 (Git以前かららしいが)実行権限だけ保存するのはどういう理由なん？ 125 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 08:58:03.97 ID:4HU/GnaT0.net] >>124 多分だけど古くからの unix 文化の影響 ファイル所有者の読み書きの権限は無制限、ファイル所有者の実行権限は個々のファイルごとによって違うという使い方をするのが普通だった 分散型だと他人とかグループとかを管理する必要はない（そもそも所有者とか所有グループを管理してないので他人と所有者の区別がない） 結論として「実行権限」だけが残った 126 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 09:59:14.74 ID:oqd+iiqc0.net] >>125 つまりデフォの644→手動で755に変更の履歴を残すのが目的だったと なら750とか400とか使って真面目に管理してる連中には機能が足りないのだろうね 機能が足りないのなら追加すればいいだけの話 そこでGitは間違ってない、今後ともパーミッションが保存される事はない、他VCSもそうだし、とか考えるのは頭おかしいと思うぜ 127 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 10:54:51.44 ID:4HU/GnaT0.net] >>126 そもそもバックアップはないのでファイルの所有者とかグループとかを保存管理してない ・つまり644だろうと666だろうと600だろうと違いがない、後ろの2つの数字は意味がない ・開発において所有者自身の読み書きを禁止する意味はない という考えなので所有者の実行ビットのみくらうしか汎用的なユースケースが存在しない みんなが役に立つ具体的な使い方思いつけば拡張されるかもしれないが、それを思いついたやつは今までいないので現状があると理解しろ 128 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 12:05:14.30 ID:oqd+iiqc0.net] >>127 > それを思いついたやつは今までいないので現状があると理解しろ それはお前が知らないだけ ソースコード管理者≠実行者なのは普通にある 例えばapache等のWebサーバーはnobodyやothers等の低権限で動かすのが一般的だ この場合は少なくとも自分とapacheの権限は独立して記録出来てないと不便だろ そもそも今回の質問が発生するのも、また、 > 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない (>>97) あるあるになるのもみんなその機能を使いたいからだろ > そもそもバックアップはないのでファイルの所有者とかグループとかを保存管理してない バックアップ程度で大半の人には十分だし、実際、デプロイしたらいきなり使える方が便利だろ これを言うとデプロイツールでもないと言い出すんだろうが、 いちいちパーミッションを設定するだけのスクリプトを書いたり、手動で走らせるのは全くの無駄だろ(>>97-100参考) Git信者にはGitは間違ってない！としか思えないのだろうが、 俺は単純にパーミッションも保存すればもっと便利になるからそうすればいいだけだと考える まあこの点は平行線なのでもういいが とにかく今できないのは事実としてもね というかね、このスレのGit信者にはパヨクや意識高い系馬鹿と同じ類の勘違いを感じる 「Gitではパーミッションは保存されないのが正しいのだ！だからお前らもGitの正しい使い方を学べ！」ではなく、 大衆が望んでる機能だし、今からでもパーミッションを保存するように改善すれば終わる話だと思うのだけどな 129 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 12:09:10.99 ID:4HU/GnaT0.net] >>128 もしそう思うなら具体的なユースケースをつけてコミットしろ みんなの役に立つと思われば採用されるだろう お前の役にしか立たんと思われればフォークして勝手にやれと言われるだけ 結果が全て、お前の妄想はいらない 130 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 12:21:54.83 ID:4HU/GnaT0.net] git に限らずオープンソースというのは実際に手を動かして実物で利便性を証明したものの集大成 誰もやらないのは、やる価値がないから（コストに見合わないと思うから） 怠慢だと思うならお前がやって証明しろ 131 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 13:27:52.18 ID:oqd+iiqc0.net] >>129-130 長期的には俺がフォークするかもだが、今はやらないよ 誰かがフォークしてパーミッションも保存するバージョンを作ったら、そっちを使うけど (同じスタンスの奴も多いはず。そもそもGit以前のLinusも同様だし) というかそこでムキになる理由が分からんのよ お前がGitの基本設計をしたわけではないのだから、お前が間違った事にはならないし、 必要な機能なのだから、最終的には実装されるだろうし、なら付ければいいだけだろ 現実的には99のように自分でスクリプト等を『余分に』整備して我慢してる人が大半で、 いつか誰かがブチ切れて実装されるのを待ってるだけだろ OSSなんてそんなに大した物でもないよ (Gitに限らず、どれもこれも結構ポンコツ) なお俺がGitにコミットする事はないぞ。やるなら必ずフォークする 理由はコマンドをほぼ全部リストラしたいから 132 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 13:55:32.71 ID:4HU/GnaT0.net] 「何で？ 理由は？」ってお前が問うから ・unix の伝統的に必要性が低いから ・そのせいで今まで誰もやろとうとしなかったから という今そうなってない理由を答えてやっただけ（理由を間違えてるなら指摘しろ それがお前の需要を満たしてないと思うのならば、それは別問題、それはお前が変えろ 変えるのは自由、そっちは議論してない 133 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 14:08:27.99 ID:oz7HR5eE0.net] バケツ君 再来? 134 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 14:14:55.04 ID:oqd+iiqc0.net] >>132 お前らGit信者はOSSを勘違いしてて、 ×　OSSは自由に改変出来るので必要な機能は全て実装されている ○　OSSに実装されている機能は全て、 　誰かがブチ切れて「こんなのやり続けるくらいなら俺が実装してやる！」となった結果であって、 　当たり前だが不満は常に溜まった状態にあり、爆発ない限り何も改善しない 　(不満があってブチ切れたとき、プロプライエタリでは使用を止めることしかできないが、 　OSSなら自分で機能を付加するという選択肢もある、程度) つまりGitに限らずOSSは完璧でもなく、足りない機能は普通にありまくりで、 Gitの場合はパーミッションがそうだ、というだけ お前らがそこで、ムキー！！！ならお前が実装しろ！！！ってなるのも狂ってるよ 135 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 14:26:15.08 ID:4HU/GnaT0.net] >>134 誰も git が完璧なんて言ってないが、今頃になって長文君論法は何故？ 道具なので完璧である必要なんてそもそもない、自分が満足いく性能ならそれで良し oss なんて情熱をもってそれを作る人がいるかとそれを使いたい人がいるかの論理積 存在しないのは作る人がいないか、使いたい人がいないかのどっちか 結果が全て、満足いかないなら、文句あったらお前が変えろの世界、それこそ気に要らなければ使わなくても良い 136 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 14:31:09.65 ID:oz7HR5eE0.net] >>134 誰かが実装するまで不満は残ったままということだろ? だから不満があるなら自分で実装すればいいと言われている 137 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 14:47:29.93 ID:oqd+iiqc0.net] >>135 > 変えるのは自由、そっちは議論してない(131) > 長文君論法は何故？(134) それはお前がフォークしろ論法に逃げたから、俺はフォークしない理由を述べたまで というか、元の話に戻すと、パーミッションが保存されない件について、 あるある質問者： 保存して欲しい、或いは保存されるのが当然だと思ってたのに… 俺： 機能の不備で、いつか追加されるだろ Git信者： 保存されないのが仕様だし、正しい！文句あるならGitを使うな！ 　或いはフォークしろ！フォークもしないのに文句言うな！ であって、これはもう平行線だからいいと既に127で言ったろ その後お前がフォークガー論法(128-129)で論点逸らししてきたから、 俺もちょっとつき合ってみたら、逆に俺が論点逸らしした風に装うのだからGit信者は頭おかしい 論点を逸らしたのはお前だぞ (まあお前が議論慣れしてないだけかもしれんが) とはいえこの話題についてはもう何も生産性無いし、やめでいいが 138 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 14:54:58.40 ID:4HU/GnaT0.net] 俺は 123 の最後にある「どういう理由？」に答えようとしただけで、それ以前の議論の回答はしてないぞ？ 現状が気にいらないとう方向に話が逸れたのでそっちはコミットするなり勝手にしろといってるだけ 139 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:04:27.86 ID:oz7HR5eE0.net] >大衆が望んでる機能 と言いながらそれを望んでいる人がどれくらいいるかというデータは示さない 「俺が望んでいるのだから皆望んでいるに決まってる!」と言ってるだけ 140 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:25:10.39 ID:oqd+iiqc0.net] >>138 > それ以前の議論の回答はしてないぞ？ お前がそう思うのならそれでいいが、俺もお前の「パーミッションを保存しなかった理由の推定」には文句言ってないぞ 俺が突っ込んだのは、127で引用したとおり、 > それを思いついたやつは今までいない なわけあるかボケ！であってね というかむしろ、パーミッションも保存してくれると考える方が自然だ 既に言った通り、お前らはGitが正しいという前提で考えだすから話がおかしくなる とはいえこの辺は本当に平行線なのでもういいよ OSSなんてどれもマグマは溜まってる状態で、ある意味これが仕様だ > 結果が全て(134) これでいいよ 俺： いつか誰かが追加して、パーミッションも保存出来るようになるだろ Git信者： Gitではパーミッションは保存されないのが正しいので、未来永劫この機能は付きません で、どっちの予想が正しいか、結果で判断するのが正しい そしてこれを現時点で結論づけるのは不可能なので、この話は終わりでいい 141 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:31:54.27 ID:4HU/GnaT0.net] OSS なんて「仕様に文句言う暇があったら修正コード書け、コード書いてない時点で困ってない」と判断する修羅の世界 「その機能がない」＝「今まではそれを入れる理由はなかった」なんだよ 未来は知らん、困ってるやつが頑張れ 142 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:36:35.15 ID:oz7HR5eE0.net] >>140 この先ずっと実装されないままでも「俺は正しい」と言い続けるわけだ 143 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:43:57.63 ID:oqd+iiqc0.net] >>141 × > 今まではそれを入れる理由はなかった ○ 我慢出来る範囲だったので我慢してた (130で言ったとおり) なんだよ というかお前のOSS最強信仰がどこから来るのか分からんが、 Gitに限らず何であれ、或いはプロプライエタリでも、 「ここもうちょっとなんとかならんかったんか」とは感じるものだと思うのだがな ただまあ、中には、現状をひたすら受け入れるタイプも居て、君がそうだというだけなのかもしれんが 144 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:52:55.63 ID:oqd+iiqc0.net] >>141 おっとすまん、見落とした > OSS なんて「仕様に文句言う暇があったら修正コード書け OSSは主語が大きすぎるので『Gitは』ということにして欲しいが、実際Gitではそうなのだろう 仕様を軽視しすぎだからあんなコマンドの山になる とはいえ、これに関しては作った奴がそうなんだし、気に入らなければ使うなにしかならないが 145 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 15:52:58.51 ID:oz7HR5eE0.net] >>143 「我慢出来る範囲」を超えたのなら実装すればいい グダグダ言うだけで実装しない・できない奴ばかりならこの先もずっと変わらない 146 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 16:40:26.01 ID:4HU/GnaT0.net] 我慢できてる時点で困ってないんだよ 俺の git には（俺にしか役に立たない）パッチがいくつも当たってるけど、git に限らず OSS ってそういうもんだろ 他にも同じ問題で困っている人がいたら公開して共有するし、そうじゃなきゃ自分専用で使えばいい 147 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 18:04:22.56 ID:oqd+iiqc0.net] >>146 > 我慢できてる時点で困ってないんだよ なるほどそういう考え方か、全く同意はしないが 俺は逆に、93-99の流れの時点で駄目だと思うけどな(＝困っていると判断する) 高い確率で、欲しい機能（または、あって当然と思ってる機能）が動かないから質問してるわけだし 手間を減らす為のツールなのに、手動で別スクリプト用意して管理が必要なのは、二度手間だし、アウトだよ そして最初に仕様を練ってれば、つまり、 「本当にパーミッションは保存する必要ないのか？保存した場合に何か問題があるのか？」を熟慮してたら、回避出来た問題だという話さ とはいえ、仕様を軽視する連中にはこの辺の話が全く通じないのもいつも通りではあるが まあどこまで行っても平行線だし、合意する必要もないしで、もう終わりでいいよ 結果を待てばいい 148 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 18:22:17.32 ID:oz7HR5eE0.net] >>147 >>142 149 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 18:28:39.87 ID:oz7HR5eE0.net] >この話は終わりでいい >もう終わりでいいよ そう思うなら黙っていればいいのに 150 名前：デフォルトの名無しさん [2024/12/09(月) 19:40:56.21 ID:/rVJ/4Ts0.net] まだやってたんだ なんでこんなことになってるんだ? 151 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 20:11:13.66 ID:ZPo7jPZJ0.net] 久しぶりに長文君 (https://mevius.5ch.net/test/read.cgi/tech/1668901194/) が帰ってきたからさ。 152 名前：デフォルトの名無しさん mailto:sage [2024/12/09(月) 21:50:22.89 ID:RQhO7hoM0.net] >>128 ＞バックアップ程度で大半の人には十分だし、実際、デプロイしたらいきなり使える方が便利だろ だったらgitじゃなくてバックアップツールを使えばいいのでは？ 誰もお前にgit使えなんて頼んでないし 153 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 00:43:59.32 ID:LZyb1uxu0.net] パーミッションも記録するようになったらなったで今度は誰かがACLも入れてくれと言い出す 154 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 08:19:56.89 ID:iBb8Uq0X0.net] >>153 プラグイン出来るようにすれば済む話 155 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 10:33:12.74 ID:sGQQlBSJ0.net] 昔の状態を保存したい目的に使うのはバックアップツール、アーカイバとかでも良い 長文君といい今回といい、なんで git とかのバージョン・コントロール・ツールをバックアップと勘違いするやつが定期的に湧くんだろう？（同一人物が暴れてるだけ？） このペンチでは釘が打てないと文句を言ってるレベルの無知さらけ出してるの気づいてないんだろか 156 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 11:39:48.78 ID:iBb8Uq0X0.net] >>155 そこが疑問になるのは、お前に一般化能力が全く足りないからだな まあGit自体に一般化能力が皆無だから、Gitに不満がない奴等は一般化能力もかなり低めで、 この意味ではGitは一般化能力の低い連中のエコーチェンバーになってる このスレもそう 並の一般化能力があれば、あの全く整理されてないコマンドの山を見れば発狂する、俺がそうだ して本題だが、単純にバックアップツール/アーカイバとしても使えるからだ 例えばtgzして毎日保存して、必要ならコメントも付けて、必要ないファイルは除外して、重複してる部分は圧縮して、検索機能も付けて、… とかやりだすとほぼVCSになる 鯖なしで単体アプリとして使えるVCSで一番目に付くのはGitになる バックアップ＝ブランチのない一本線コミット履歴、でしかないのでどのVCSも(一般人が期待する機能の)バックアップツール/アーカイバとしては使える 「別物」としてしか捉えられないのなら一般化能力が全く足りてない (「勘違い」ではなく、分かってて「流用/転用」しようとしてるだけなのを、一般化能力が低すぎる故に理解出来ない) Git信者風に言えば、「ぼくはいっぱんかのうりょくがかいむです」と言ってる事に気づいていないんだろうか、となる ただなんつうか、この手の一々イヤミを言うのもお前らが嫌われてる理由だと思うんだけどさ 最後の文なんて意味不明な選民思想の露呈であって、しかも間違ってるしで、言わない方がましだよね (まあリアルでは絶対に言わないがここは5chなので試しに言ってみる、というのならアリだが) 157 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:15:22.20 ID:6HlM5sdR0.net] こいつの言ってるは「ペンチでも頑張ったら釘を打てるんだから、もっと釘打ち能力を強化しろ」ということだな 普通の人はペンチと金槌を使い分けるし、専門家なら用途ごとに複数のペンチや金槌を準備する 一つの道具で全部やろうとしてる時点でド素人だと気付けない病気かな？ 158 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:26:57.55 ID:ChjTkXcv0.net] 言っていることはごもっともだが、一方で、ツール選定の際には使い慣れているものや既に運用されているものを優先するバイアスがあった方が効率的なのも事実だ 些細な課題に必要以上に固執してすぐに別のツールを使おうとするのも、それはそれで生産性を低下させる原因となる典型的な悪癖 もちろん上記のバイアスが強すぎるのも良くないけどね 159 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:28:35.11 ID:nRxMArw0a.net] 双極性障害で、今が元気な期間で鬱に入ったら静かになるよ。 160 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:31:13.80 ID:sGQQlBSJ0.net] >>156 ブランチ使わねーとか、やっぱお前長文君だろ 開発どうなったんだ？ 自分のスレに帰れ、完成まで戻って来んな 161 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:55:13.36 ID:maUGvQsbM.net] 仮にパーミッション対応するにはどうしたらいいか、という生産的な議論はできんのか？ 162 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:04:16.91 ID:iBb8Uq0X0.net] >>157 > 用途ごとに複数のペンチや金槌を準備する ペンチや金槌ほど違いはないって事 ソフトウェア界隈でよく言われる、 「気に入らないからといってオレオレフレームワーク/ライブラリを作っても どうせ９割は同じコードになるのだから、(＝車輪の再開発でしかないので) 多少気に入らなくとも既存のフレームワーク/ライブラリを使え、その方が生産性が断然高い」が該当する 俺はGitを気に入らないが、かといって自分で作ったとしても９割は同じコードになるので、 わざわざ作り直すよりはそのまま使って、本来のアプリケーション開発に注力する方が全体的にマシ、ということ コマンドが糞の山だが、基本コマンド以外は使わなければいいだけではあるので その他てんこ盛りの機能も同様 まあ俺的にはタイプスタンプを保存して欲しいんですけどね 理由は一番分かりやすいから でもLinusは何か知らんがこれは絶対に認めないんだろうしね 163 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:15:59.11 ID:maUGvQsbM.net] gitも再発明だろ お前はひたすらやらない理由を考えるタイプ 164 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:17:40.15 ID:iBb8Uq0X0.net] >>161 Gitでやるなら>>93-100 Gitを改造する気なら、commit時に何かしらのメタファイル(的なもの)を自動コミットしてしまって、 その中にパーミッションを記録しておき、戻すときに使えばいいだけ まあ、やる気になればすぐ出来る問題だから、現時点で入ってないのは、 ・本気で要らないと思ってる ← Git信者の予想 ・まだブチ切れた奴が居ないだけ ← 俺の予想 ・何かしらの理由で、政治的に拒否している ← Linusならあり得る 最後のは、例の発言 > マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。 > https://cpplover.blogspot.com/2013/05/linus-torvalsc.html なので、Git信者が喚き散らしてる「Gitをバックアップツールとして使わせない！！！」為に意図的にやってるってのは、 (半分ジョークだとしても、)Linusならあり得る 165 名前：デフォルトの名無しさん [2024/12/10(火) 13:21:33.43 ID:1EevVDftM.net] ファイルの中身の先頭にファイルそのものの属性情報を付けるという発想は、メインフレームなどの古い思想。 166 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:23:12.69 ID:0BGH+xex0.net] >>160 同意 長文君のスレ 日常の進捗履歴記録ツールWitBucket(仮称)検討中 https://mevius.5ch.net/test/read.cgi/tech/1668901194/ 167 名前：デフォルトの名無しさん [2024/12/10(火) 13:49:10.16 ID:yCEb4nkG0.net] ごっみばけっつ君来てるのか ばーじょん0.1でいいから早く成果物公開してや 168 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 14:56:53.30 ID:sGQQlBSJ0.net] 長文君は問題外なので放っておくとして unix 文化圏の KISS 原則というのは他の文化圏から来たやつには不思議でしょうがないんだろうな Keep It Simple Stupid 「単純で馬鹿なままにしておけ ＝ 余計なことはするな」 単純なものを組み合わせて何か複雑なものを作るのは簡単だけど、複雑なものを組み合わせるのは困難 お仕着せじゃなくて自分で工夫して何とかする人には元が単純であるほど良い 169 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 15:14:11.48 ID:r7RcD6Xd0.net] まあ使いやすくしたければ自分でツール作れば良いだけの話なのに何で作らないの？ 必要なら作った方が効率がいいと思うんだけど。 170 名前：デフォルトの名無しさん [2024/12/10(火) 16:47:08.21 ID:IViAh4+E0.net] 元の質問者だけど、質問はただ出来るのかどうか聞いてただけなんだけどなあ こうなって欲しいとかあるべきとか別に何とも思ってないんだが、なんで勝手に仮定してそんなに膨らませるんだろw あとバックアップがどうのって言ってる人が最初の方からちらほらいるけど、バックアップの話ってどこから出してきたんだ? 誰もそんな話しとらんよね 171 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 17:00:49.95 ID:nRxMArw0a.net] Gitのことは嫌いでも、Linusのことは嫌いにならないでください！！ 172 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 18:03:32.07 ID:6HlM5sdR0.net] >>170 読んだら分かると思うけどこのスレには「git は初心者向けのバックアップ・ツールであるべき」というのが持論の変なやつが一人居着いていて定期的に湧くんだ そして、ちょっとでもバックアップぽい使い方をしてるやつや初心者っぽい質問があると持論の補強に使おうとする で、他の人がそれに反論したり予防するのが日常風景になってる 関係なければ軽く無視しても大丈夫だよ 173 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 18:45:20.68 ID:iBb8Uq0X0.net] >>168 GitはKISSとは真逆だけどな >>170 手動でスクリプト書いてパーミッションを保存する気なのに、自分が使いたい機能と認識出来ないのは知障だろ >>171 いやLinusの発言内容は大体同意だし、(163に挙げた物含めて) ズバズバ言うところも割と俺は好きだけどな もちろん会った事も話した事もないが ただGitはなぁ…OSSの中でもここまで仕様がグダグダなのは存在しない 仕様を詰めるのは時間の無駄だ、として嫌う奴はいるが、大体そいつらはプログラミング初心者で、 Linusがこの辺理解出来無いとも思えないので、意図的に放置してる気もする 結果的にVCS界のmulticsになってるので、いつかunixが生まれる ただまあ、使う分にはコマンドが多すぎても大して困らないんだよ、使わなければいいだけだから しかしメンテするとなると、本来は全部のコマンドが正しく動く事をチェックしないといけないので、肥大化すると無理になってくる Gitはこの辺、自動テストもする気無く、動かなければ動きませんね、文句があるならお前が直せ、でやってるように見える また、勿論OSSなのでプロプライエタリと比べれば限界点は10～100倍上であり、 行けるところまで行ってしまえ、限界点のテストだ、という風にも取れる この辺の思想が俺には合わないね、まあ他も多々あるが だから、俺が参戦するとしたら、Gitではなく、unixを作る側だよ 174 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 21:54:47.54 ID:KgYOToHf0.net] そんなにGitが嫌なら使わなければいいのでは？ 誰もお前にGit使えなんて言ってないでしょ 175 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 23:14:48.26 ID:cIogiqHs0.net] ゴミバケツ君また自分でVCS作る話してる。 前のはどうなったのか。 176 名前：デフォルトの名無しさん [2024/12/11(水) 01:32:29.88 ID:bYjfV/I80.net] バージョン管理システムを変更履歴システムだと思い込んでいる人間は多いよなあ。 変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。 177 名前：デフォルトの名無しさん [2024/12/11(水) 01:35:22.67 ID:bYjfV/I80.net] Linuxは開発者の質が低いんだよ カーネルに次々と新しいバグを追加する だからLinuxを採用するとカーネルを独自に直すという作業が必要になる 178 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 01:50:58.96 ID:Y83IEE6u0.net] このスレ痛いやつ多いのな ↑とか 179 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 08:49:43.35 ID:bZvW/lze0.net] >>176 > 変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。 それはdiffで十分だし、しかもGitの場合はdiffを内包してしまってる（俺はこれにも反対) だから不満があるとするならバイナリか？(Excel等を含む) 勿論これは対応してないだけだし、 また、対応するにしても、Gitが直接差分を出す「モノリシック」ではなく、 「プラグイン」で各社が自社アプリ用の差分出力ツールを供給出来る形態にするのが正しい VCSから各種diffを直接出力すべきと考えるのは間違いだと思うぜ >>177 そうだとしてもLinux以外にないわけだが、 > カーネルに次々と新しいバグを追加する これはポリシーというか戦略が違ってて、「今より少しでも改善するなら採用」だからじゃないかと 従来型の「最低限のクオリティに達するまではreject」へのアンチテーゼでもあるから そして(文句あるかもしれんが)カーネル開発者は元々のエンジニアの質がそこそこ高かったからそれでも何とかなったものの、 同じ事をGitでやったからあの「ぼくがおもいついたすごいこまんど」の山になったのだと思う 交通整理すらやる気無かったわけだ とはいえ、「使われなくなったコマンドは、いつしか動かなくなった事すら認識されなくなり、死んでいく」という、 Gitコマンド内でのライフゲームをやるつもりなら、ありなんだろうさ 厳選されてるように思えるunixコマンドだって、レイヤーが1つ違うだけで同じライフゲーム状態だし 180 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 09:57:22.36 ID:34XO7K6O0.net] お前よりAIのほうが賢いんじゃね？ https://i.imgur.com/V1cME8T.png 181 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 12:19:18.72 ID:+nAxu/ku0.net] git を始めとして最近のVCSは著者(author)とか承認者(commiter)とかの由来を管理するけど、所有者(owner)とか所属グループ(group)とかの現状は管理しない 管理の粒度もファイル単位ではなくて変更点単位 「バックアップ」という言葉の使い方次第だが次元の違うものを管理してるというのは最低限の事前知識 182 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 12:25:55.27 ID:JMogi+gN0.net] GitHubを容量無制限のファイルバックアップ置き場として紹介しているサイトもあるけどな 183 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 12:45:40.19 ID:kPp0f2Rs0.net] >>162 タイムスタンプがそうなっている理由はプログラマならわかるかと。 makeとかのビルドシステムがファイル更新をタイムスタンプで判定しているんだから、gitが書き換えるごとにタイムスタンプが新しくなるのはビルドシステムを考慮したら当然の話。 タイムスタンプを勝手に書き戻したら再現困難なバグになるから、採用は無いだろうね。 184 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 13:21:42.72 ID:JMogi+gN0.net] 自分もタイムスタンプは戻してほしい派 その手のビルドツールって、なんで「タイムスタンプが古くなってても更新扱い」にしてくれないの？ 185 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 13:29:52.53 ID:+nAxu/ku0.net] 1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？ そのタイムスタンプ更新の著作権は誰に所属するの？ コミッタはそれを確認して承認作業するの？ 古いパッチの再利用したら日付が昔に戻るの？ ブランチ統合したらどっちの日付が採用されるの？ アホらし過ぎる議論 ファイルのバックアップは別に取れ 186 名前：デフォルトの名無しさん [2024/12/11(水) 17:38:01.33 ID:HXU8Fpor0.net] >>170 今話してるのは質問がGitをバックアップに使ってると勘違いしてる人たちだから無視していいよ 他の人は>>100でやりとりが終わってると分かってる 187 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 18:37:28.10 ID:bZvW/lze0.net] >>180 それは「現時点でもGitはバックアップツールとして十分使えます」と言ってるんだがお前はそれで良いのか？ >>183-184 つ make distclean >>185 回答を期待してるわけではないだろうが、俺が今思いついた範囲なら、 1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？→古い日付のファイルに戻してからcommitしろ(或いは「内容が同一のファイルは非更新扱いにする」オプションをcommitコマンドに追加するからそれを使え) そのタイムスタンプ更新の著作権は誰に所属するの？→上記なので関係なし コミッタはそれを確認して承認作業するの？→同上 古いパッチの再利用したら日付が昔に戻るの？→パッチを当てた日になる、つまり戻らない ブランチ統合したらどっちの日付が採用されるの？→マージ時に変更されたファイルはマージした日付になる これで別段大して問題ない気がするが まあ日付を保存する事について技術的問題はないと思うけど Linusがわざわざ外したんだから、政治的な問題はあって、採用はされないんだろうけどさ (全世界からメール等で連絡受けてたLinusは、テメエのローカルタイムなんて知るか！！！とブチ切れ、 タイプスタンプでの連絡が出来ないように作ったと予想) が、多分根本は、形式主義者か現実主義者か、といったところか 形式主義者： GitはVCSであり、それ以外の使い方をしてはならない 現実主義者： 機能が揃ってればラベルがどうであれ使う 　つまりGitもバックアップツールとして使えるし、 　GitHubは容量無制限のファイル置き場だし、 　git clone GitHubのURL: が現状一番簡単なデプロイ方法であるので、Gitはデプロイツールでもある 　(ただし目的外流用だから色々機能が揃ってないが、それでも他ツールよりマシなら使うだけ) 188 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 19:28:51.98 ID:kPp0f2Rs0.net] >>187 開発者に「俺達の利便性のために、お前らはチェックアウトするごとに手動でcleanして一からビルドしろ」と言ったらさすがに傲慢かと。 gitはプログラム開発者がソースコード管理のために用意したツールだから、開発者にとって百害あって一利無しの機能が入ることは無いんじゃないんかね。 189 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 20:38:24.90 ID:WFtEMDpk0.net] >>183 Subversionには、ファイルのタイムスタンプをコミット日時にする設定はあるけどな もちろん、makeを使うような人には危険な機能だが、それなりの要望はあったのだろう 190 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 20:46:11.17 ID:bZvW/lze0.net] >>188 それはお前が傲慢すぎ 元々makeはインクリメンタルビルドの為のツールで、 Git以前からC界隈ではほぼ100%使われてたし、勿論Linusも使ってたはず make clean; make distclean; は常識であり、知らない奴は死ねレベル ただし通常はそもそも clean する必要がない clean はだいたい rm *o だが、そもそも中間ファイル(*.o)は tar ボールには入ってないので、自分で make しない限り存在しない だから「同一ディレクトリで『再度』makeしなおす」前に make clean であって、初回はやる必要がない つまり「何度もビルドし直す」実際の開発者向けの機能であり 「ソースをダウンロードして一回ビルド成功したら終わり」のユーザーはどのみち clean なんてやる必要がないし、知らなくていい これがGitの普及で毎回全部リビルドがデフォになっており、 君のように勘違いしてたり、あるいは makefile 内の clean が機能しなくなってる(メンテされてない)、という可能性はある 或いは、この辺の行き違いがLinuxで相当数発生し、『常に全部リビルド』するようにLinusが作った、という可能性もある (Linus発言見てる限りは「タイムスタンプじゃなくてちゃんとコメント書けやボケ！」のように感じるが) ただまあ、どのみちお前らのような、現状のGitに満足してる連中にはどうでもいい事だし、 俺ならタイプスタンプは戻すし、Gitにはコミットせずにフォークして勝手に作る 勿論気に入らなければ使うな、タイムスタンプ戻したければ勝手に使えだし ただお前ら、繰り返すが > それを思いついたやつは今までいない (126) とか考えるのがとにかく傲慢すぎるんだよ 自分以外は超絶馬鹿としか思ってない奴しかこんな発言はできない 実際には、考えた上で、違う選択になってる 「タイムスタンプも保存した方がいいのでは」という提案を、これまで世界で誰も思いつかなかった、なんて事はあり得ない Linus自身も最初から分かってて、敢えて落としてるんだよ で、本来は、その落とした理由が分からないと地雷を踏むだけなので確認すべきなんだけども、 Git信者共はポジショントークを繰り返すだけでクソ使えねえ、 まあどのみちrejectされるのは分かり切ってるのでやるならフォークしかない、といったところ 191 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 21:17:41.31 ID:+nAxu/ku0.net] 何も分かってないやつがいて草 タイムスタンプは過去には戻らない未来に進むだけ、という前提で多くのツールが設計されてる make もそう この前提を壊さないように配慮することが大原則で git のみならず unix 系のツールは設計されてる バックアップからの復元はこの前提を壊して過去に時間を戻す行為なので特別な時にのみ使うもの 192 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 21:35:45.41 ID:bZvW/lze0.net] >>191 zipやtarは普通にタイムスタンプは保存されるだろ その延長で考えるなら、保存された方が自然だし有用だ、というだけ ただまあ、これも合意する必要はない フォークしてどちらがウケるかで決するフォーク主義が正しいし、ユーザーは好きな方使えば済むだけ (現実的にはcp -p と同様にオプションで切り替えるのが普通で、 逆に言えばオプションすら存在しないGitは何らかの「意図」をもってそうしてるとも言える 理由は今のところ不明なので思いつく人はよろしく) まあ心配せずとも、Linuxカーネルにコミットしてくる連中で、make clean を知らない奴なんて一人もいないよ (だから多分問題はここではない) 193 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 00:21:35.10 ID:C7R5gozk0.net] git pull した後に make clean とか git 使ったことないのが丸わかりだな 何のための make だよ？ 194 名前：デフォルトの名無しさん [2024/12/12(木) 01:11:52.06 ID:2Npzz1EV0.net] 負け組のためのだろ 195 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 08:57:54.12 ID:yWChnlb80.net] >>190 「俺はタイムスタンプの管理をgitでやりたいから、お前らはチェックアウトするごとにmake dustclean しろ」と言ったら、温厚になったLinusでもさすがに罵倒するかと。 gitはLinusがlinuxのソースコードを管理するために作ったツール。今もメインユーザーはLinux開発者で想定利用シーンもLinux開発なんだから、「Linux開発者の足を引っ張る機能」を追加するのはディレクターの正気を疑うレベルですな。 196 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 09:15:02.60 ID:C7R5gozk0.net] >>195 いや linux とか Linus とかもはや関係なく全プログラマー大爆笑案件だろ git pull で同期したら日付が過去に戻りましたとか全員が git の使用やめるレベル 197 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 09:16:55.48 ID:OOlmzVQX0.net] https://stackoverflow.com/questions/1964470/whats-the-equivalent-of-subversions-use-commit-times-for-git PythonやPerlを使う人には、makeのためにタイムスタンプが失われるのはいい迷惑だと言われてるな 今さらリポジトリにメタデータを埋め込むのは難しいにしても、 gitconfigで>>189くらいさせてくれてもいいのにとは思う 198 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 15:16:51.62 ID:d+ZuY6W00.net] >>197 当然だが既に同じことを考えてパッチしてた奴が居たか > Linus' rationale of timestamps being harmful just because it "confuses make" is lame: 189に書いたようにこれはないと思ってたが、マジだったとは makeで問題になる場合って、 makeした同じディレクトリでより古いバージョンでソースを上書きしてcleanせずにmakeした場合、 に限られるのでLinus以外はほぼやらねえし、Linusがmakeの使い方知らんわけねえし、ねえわと思ってたが、 自分専用ツールだからカスタマイズ済みの感じか とはいえ謎の地雷があるわけではなさそうというのは分かった、ありがとう 普通に考えれば、保存した上で戻す際にオプションで選べるようにしておけばいいだけなのだがな この辺Gitは無駄に押し付けがましいのが意識高い系と被るし、 だからこそ連中とも親和性が高く、このスレにもそういう奴が多いのだろうけど 用途は考え方の違いで、(俺がそういう使い方をするわけではないが) cron に commit させとけば、VCSはバックアップツールとしても使えて、 偶に過去バージョンにパッチ当てる際は branch すればいいのだから、 一本線しか許されないバックアップツールよりはソースコードのバックアップには向いているというだけ ただHgなら保存されるのか？なら俺はそれでもいいんだが (料理の腕前で勝負してるのに、整理棚に必要以上にこだわっても本末転倒) 199 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 15:21:09.29 ID:JM/xCx8/0.net] 料理の腕前で勝負してるつもりならさっさとWitBucketとやらを作れよ 200 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 16:33:59.70 ID:d0NKDmelM.net] >>198 ChatGPTで3行に縮めて投稿しろ 201 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 18:58:50.56 ID:yWChnlb80.net] >>198 >Linus以外はほぼやらねえし、 「gitはLinusがLinux開発で使うために作った」という大前提を忘れるのはアルツハイマー病の一種かしらん？ 202 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 10:34:37.92 ID:mefXJp+A0.net] Gitの使い方というかSourcetreeの使い方というか質問があります とある1コミットに複数ファイルがあって複数個所に変更がまたがってて 別ブランチにそのコミットの1ファイルの1部分だけをマージしたいです その場合はチェリーピックは使えないので1部分のHunkをステージングに移動して コミットするという方法が素直なマージ方法でしょうか？ 203 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 11:43:48.24 ID:kPFQFgKW0.net] >>202 採用元が push 後とか他人のコードだとそんな感じかな 私だと cherry-pick してから巻き戻し修正するけど、複数パッチなら rebase -i で edit を使う 採用元がローカルにしかない push 前なら元のコミットを分割しておくのが良い方法だろう 将来的に再利用するときにも別々に利用する可能性があるものは、今のうちに別パッチに分割しておくのが賢いと思う 204 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 11:54:03.74 ID:mefXJp+A0.net] >>203 回答ありがとうございます まさに他人がプッシュしたものを派生ブランチにも適用させようとしています その中に特定ブランチの対応分も混ぜてしまっていたため どう対応すべきか質問した次第です コミット分割は癖にしておきたいと思います 205 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 14:22:21.70 ID:jFwYZGRF0.net] ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな 206 名前：デフォルトの名無しさん [2024/12/14(土) 19:07:11.21 ID:cLbKsfdN0.net] >>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった 7bは置いとくとしても100レスも使ってこの体たらくとは情けない 207 名前：デフォルトの名無しさん [2024/12/15(日) 22:01:21.97 ID:D9xraIFr0.net] >>179 diffでわざわざ比較するというのは時間の無駄 208 名前：デフォルトの名無しさん mailto:sage [2024/12/15(日) 22:49:45.11 ID:9FCwcKO70.net] >>207 相手にすんな バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので 209 名前：デフォルトの名無しさん mailto:sage [2024/12/15(日) 23:49:43.28 ID:UElXL8/K0.net] >>204 コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題 210 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 00:02:22.98 ID:I9YsDANU0.net] 不毛っていうのも程度問題でしょ 経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある hot−fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる 211 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:28:18.00 ID:UeL/Eu4T0.net] cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？ 212 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:38:05.37 ID:ZibPg38H0.net] 同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ 特にブランチ切るまでもない単純な修正の場合とか 要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ 213 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:42:21.10 ID:UeL/Eu4T0.net] せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？ 214 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:53:45.68 ID:ZibPg38H0.net] >>213 cherry-pick はブランチ切るまでもない修正用だよ コミット1個ならどこから cherry-pick したか分かれば良いだけだし 215 名前：デフォルトの名無しさん [2024/12/16(月) 13:11:10.31 ID:56LO+jCc0.net] 今度はチェリーピックでやり合いか 216 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 13:17:14.68 ID:I9YsDANU0.net] 将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる 程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う hotfixが必要ない現場なら必要になる機会は少ないだろうな 217 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 13:41:54.88 ID:ZibPg38H0.net] cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利 ・最新版から過去リリースへのバックポート ・セキュリティなどの hotfix の適用 ・テスト用の addhoc 修正版（正式なマージは今ではない ・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない など多数 「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再利用や利用中止がやり易くなるといだけ 218 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 15:08:47.67 ID:/03Ox5VG0.net] cherry-pickって言葉のニュアンスの通り 219 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 16:03:21.23 ID:ZibPg38H0.net] git の rebase と cherry-pick は同じ概念なので rebase とか使わない派閥のやつは cherry-pick も使わないだろうなあ cherry-pick はブランチ切って rebase してブランチを消すを一発でやってくれるコマンド 正確には rebase の方が cherry-pick を繰り返した後にブランチ位置をそっちに切り替える機能というべきだけど 要はブランチを使うか使わないかの違い 220 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 22:52:09.15 ID:m/ncuAnJ0.net] すみません、チェリーピックに関して質問した者ですが 追加で質問よろしいでしょうか？ 本流ブランチAから子ブランチBが作成されて 子ブランチBから一時的に孫ブランチCが作成されました ブランチCで修正した一部コミットだけブランチBにチェリーピックしてマージして 他のコミットは無駄なのでブランチCがもはや不要となりました 孫ブランチCを削除してもブランチBにチェリーピックした内容は 削除される（元に戻される）ことはない認識で合っているでしょうか？ 221 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 22:58:16.88 ID:m/ncuAnJ0.net] コミットの独立性が保たれているためチェリーピック元のブランチを 削除しても問題ないと認識しています 222 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 00:55:20.81 ID:Np7JyJBV0.net] >>220 削除されないから大丈夫 まず第一に、残ったブランチやタグのいずれかから到達可能なコミットは生存し続ける 第二に、cherry-pickによって作られたコミットはマージと違って元のコミットとは別物の複製体になるので原本がどうなろうと知ったこっちゃない 223 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 07:53:20.59 ID:n6Rf+SXX0.net] >>222 ありがとうございます Sourcetree独自の機能か分かりませんが チェリーピック元のコミットIDをコメントに付与しているため もう辿ることもないコミットならコメントから余計な情報は 省いた方がよさそうですね 224 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 09:46:53.70 ID:Np7JyJBV0.net] >>223 それは git cherry-pick -x で付く情報だと思う 公開されないコミットへの参照は残さないほうがいいね 225 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 12:10:27.20 ID:Mk8ZrsM80.net] 残ってても邪魔にはならないだろうけど cherry-pick 元がすぐ消える予定なら、付けないのが普通ですね 226 名前：デフォルトの名無しさん [2024/12/17(火) 13:07:22.36 ID:bMW/7Xg20.net] チェリーピックって童貞狩りじゃねえのか？ 227 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 13:48:26.81 ID:8t1OBzHLM.net] つまんな 228 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 14:02:58.22 ID:Mk8ZrsM80.net] cherry pick 1. 都合の良いものだけを (恣意的に) 選び出す 2. 慎重に必要なものを選別する 2. 好きなもののみを摘み食いする 4. バーゲン品から掘り出しものを漁る 5. 木から熟したサクランボだけをもぎ取る 5が本来の使われ方、1の意味で使われることが多い 229 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 22:22:58.48 ID:uhdhcEFf0.net] コミットする内容を複数に分けたい場合、必要な部分だけステージングすると読んだのですが、 この機能を使っても作業フォルダの内容は変化しないので、 一緒にコミットするべきだったところを入れ忘れてしまい、 プルしても正しく動かない状態のものを上げてしまっていたということがあります この一発勝負みたいなステージングの機能をみんな使いこなしているのでしょうか？ 230 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:11:14.06 ID:Np7JyJBV0.net] >>229 一発勝負っていう感覚はおかしいでしょう 一度ステージングした後やコミットした後でプッシュするまでもいくらでも再確認とやり直しのチャンスがある 危うい操作をしたのに十分に確認していない内容をプッシュしてしまう習慣のほうがどちらかというと諸悪の根源だと思う SVNだってローカルの変更を部分的にコミットしようと思えば同じようなリスクがあるので、ステージングという考え方自体のリスクではない 分割してコミットはビルドの通らないコミットを作ってしまうリスクは増すから不慣れで自信のないオペレーションになったときはstashやswitchを活用して疎通確認しておくとか、要らん変更と意図的に残した変更と漏れた変更を混同しないようにassume-unchangedやskip-worktreeなんかを活用してもいい 231 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:14:08.08 ID:QjcMYSDT0.net] >>229 複数のコミットで一つの修正になるならrebase してまとめたら？ 232 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:25:32.69 ID:Np7JyJBV0.net] >>229 問に回答してなかった ステージングの機能を使いこなしているかはNoです 差分確認からコミットまでの流れはGUIのほうが好きなのでステージングは全然活用できてない 233 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:33:17.82 ID:Mk8ZrsM80.net] >>230 git status とかを頻繁に打つくせをつけた方が良いぞ、それでコミットし忘れ防げる（ついでによく使うオプションは alias にするとさらに良いぞ） あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ 234 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:34:08.72 ID:Mk8ZrsM80.net] >>233 アンカミス >>229 あて 235 名前：デフォルトの名無しさん mailto:age [2024/12/18(水) 09:25:32.99 ID:IhQ3pKwU0.net] Git v2.48.0-rc0 236 名前：デフォルトの名無しさん mailto:sage [2024/12/18(水) 11:41:14.09 ID:pGa0ZLUBM.net] >>229 もうでてるけど いれないものはstashして動確してcommit stagingの存在理由わかってくる 237 名前：デフォルトの名無しさん mailto:sage [2024/12/19(木) 21:05:36.88 ID:KU+lpcLj0.net] >>219 言うほど同じか？ rebaseを好む派閥がrebase使う最大のモチベーションはログの直線化 そういう神経質な連中がcherry-pickによる重複コミットの大量発生を許容するとは思えないのだが 238 名前：デフォルトの名無しさん [2024/12/19(木) 21:38:31.24 ID:QSrQ7dPA0.net] やってることの内容は似てるけど用途が全然違うからなあ かのPro Gitもリベースの章はベタ褒めでahhとかthe bliss of rebasingなどと顔もやや恍惚気味の御様子だが チェリーピックとなると淡々とした説明で真顔だよ 239 名前：デフォルトの名無しさん mailto:sage [2024/12/19(木) 23:45:56.41 ID:b251oEg00.net] >>237 目的じゃなくて動き(実装)の話 rebase で cherry-pick できるし cherry-pick で rebase できる どっちもコミットの再利用(付け先の変更)を目的とするコマンド あと直線化にしか rebase 使わないと思ってるうちは git の実力が認識できてない 240 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 01:21:38.28 ID:+bubGwJY0.net] リポジトリを分けるか、モノでやるか 統合度合いが微妙な場合にものすごく悩む 241 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 09:56:06.03 ID:PANCPXf30.net] そんなところで悩んでいる段階なら分けなくていいよ。最初から細かく分けようとするのは基本的に時間の無駄。 成功している組織はだいたいクソデカリポジトリなのも事実。それについては戦略としてモノレポが優れているというよりは結果的にそうなっただけだろうけど。 242 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 11:20:48.46 ID:Vt9p1L/d0.net] >>240 一般論にはメンバーで分けるとうまくいく事が多い 将来的に人が増えたり入れ替わっても同じ1つのグループで開発を続ける予定なら一緒にする、 対応するグループが分割されて片方だけに関わる人が出てきそう、もしくは不明なら別にしておく 243 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 12:26:56.43 ID:PANCPXf30.net] 「うまくいく」の定義によるかなあ 分かれている方が良いという前提のもとで失敗の可能性を下げるという意味では>>242に同意するが、 個人的には不適切な分割による失敗は幾度も見たことがあるが、逆に一緒であることの直接的な実害にはあまり遭遇した経験がない 巨大なモノリスへと誘導されやすいみたいなアーキテクチャに対する影響は否定しないが、そのへんは日常的なコーディング作業というより もっと大きな視点で恣意的に判断すべきことかと思う そして、その判断を今すべきか、そもそも可能なのかは冷静に考えた方がいい 244 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 12:53:34.97 ID:Vt9p1L/d0.net] >>243 ・分かれてるものを一緒にするのはとても簡単だが、1つのものを分割するのはかなり手間がかかる ・単純なものどうしを組合わせるのは単純作業だが、複雑なものを組合わせるのは不可能な場合がある という一般原則による、悩んだ時は原則に従うのがたいてい正しい 245 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 08:12:17.24 ID:/IqCjkFy0.net] >>244 同様に、下記も言える - 共通化されているものを個別化するのは簡単だが、個別化されているものを共通化するのは難しい 世の中そんなに単純じゃないんだわ 246 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 10:33:21.60 ID:Hifil6s+0.net] >>245 俺の書いた2つは、お前が書いた共通化の手間より断然難しいというのが一般的だと思うが、お前にとっては同レベルなんだろうなあ まあ頑張れ 247 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 11:20:34.07 ID:w/Sbt61U0.net] >>246 誤解させたようで申し訳ないが、単なるリポジトリの統合じゃなくてコードの共通化の話な 一般論として、集中管理は密結合を、分散管理は重複を招く 共通部分を介して密結合しているモジュール同士を切り離すには最悪共通部分をコピペすればよい 一方、分散管理され各所で個別化された重複を後から共通化する作業には、それほど自明な移行パスは存在しない コードスタイルや設計の問題といえばそれだけだが、それはモノレポだって同じことだ 248 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 12:43:49.34 ID:Hifil6s+0.net] >>247 一般論だけどコードの共通化は難しくない というのは必須ではないし時間の制限がないから バラバラのまま結合して共通化できるところから時間をかけてゆっくり丁寧に共通部品に切り替えていけば良い linux kernel とか部品の共通化に3年とか5年とかかけてゆっくりやってることも多い、共通化しないこともある （手間だけの問題と技術的難易度の問題という本質的な部分の優先度を分けて考えると理解できると思うよ） 249 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 14:07:45.37 ID:w/Sbt61U0.net] うーん、難しいと感じるかどうかはあなたの感性の問題だから、比較対象と根拠を示してね 250 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 17:31:11.06 ID:Hifil6s+0.net] >>249 感性の議論はしてないよ、お前がそう思ってるだけ 技術的にすぐに必要なものもと、条件によって無くてもすむし後回しにもできるものとを同次元で語るなって指摘なだけ （後回しにして良いなら簡単、やらなくて済むのが一番簡単、という当たり前の指摘、感性の余地とかない） 251 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 18:23:30.51 ID:Bjr5M2i00.net] >>250 読み返してみたけど>>245のツッコミがまとも お前は自分の意見が一般的と言い張ってるだけ 252 名前：デフォルトの名無しさん mailto:sage [2024/12/22(日) 11:25:46.33 ID:KQFeVRO70.net] >>230-236 みなさんご意見どうもです SVNを使っていた頃や、ステージングを使ってみる前は、 変更ファイルをいったんどこかに逃がして、作業フォルダを綺麗な状態に戻して、 今回コミットしたいところだけくっつけ直して、動作確認できたらそれらをすべてコミットして、 逃がしておいたものを元の場所に戻して作業再開、みたいな操作をしてました 結局プッシュする前にステージングし忘れなどを確認する必要があるとなると、 コミット時に確実に確認できる上記の方法もそんなに悪くはないってことですかね 253 名前：デフォルトの名無しさん mailto:sage [2024/12/22(日) 14:58:34.96 ID:1vLY5nWA0.net] >>252 それで良いんじゃないかな？ 私だと2つに分けたのを両方先にコミットしておいて、両方別々にチェックアウトしてテストを走らせるけど 問題があれば巻き戻してやり直し 問題がなけば push push 前ならローカルでいくらでもやり直しが効くのが git の利点なので個人的に分かりやすいやり方でやれば良い 慣れたらテストの自動化とか検討すると捗る 254 名前：デフォルトの名無しさん mailto:age [2025/01/01(水) 05:03:32.91 ID:RPjVgyjf0.net] Git v2.48.0-rc1 255 名前：デフォルトの名無しさん mailto:age [2025/01/07(火) 09:45:36.95 ID:DbV6+6Xe0.net] Git v2.48.0-rc2 256 名前：デフォルトの名無しさん mailto:age [2025/01/11(土) 11:00:17.95 ID:tzzUwbv+0.net] Git v2.48.0 257 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 11:20:09.87 ID:L3maUoeD0.net] サル先生でGitの学習を始めました そこで質問です！ 下記コマンドの中に dewfr という記述が存在するのですが、これは何を意味するのでしょうか？ > git config --global core.editor "\"[使用するエディタのパス]\""dewfr 参照：https://backlog.com/ja/git-tutorial/intro/06/ 258 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 12:11:34.88 ID:hjmuezNa0.net] 先生が個人的に使っているエディタのファイル名なのでは？ 直前がパス区切り文字で終わってるし 259 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 12:24:19.20 ID:L3maUoeD0.net] あ〜なるほど！謎が解けました！ ありがとうございます！ 260 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 17:53:29.03 ID:6ooBodrm0.net] Git用GUIがなまじっか日本語化されていると、 求めているコマンドを探すときに面倒くさい 261 名前：デフォルトの名無しさん [2025/01/12(日) 18:29:09.15 ID:ORJFqn4Yd.net] >>260 わかる 262 名前：デフォルトの名無しさん [2025/01/12(日) 18:29:16.18 ID:ORJFqn4Yd.net] >>260 わかる 263 名前：デフォルトの名無しさん mailto:age [2025/01/15(水) 09:29:23.33 ID:3C2APGzS0.net] Git v2.48.1 264 名前：デフォルトの名無しさん mailto:sage [2025/01/15(水) 14:32:20.61 ID:gq5bJ2fy0.net] Git for Windows 2.47.1(2)Latest 265 名前：デフォルトの名無しさん mailto:sage [2025/01/15(水) 14:42:56.61 ID:gq5bJ2fy0.net] Git Credential Managerの脆弱性で Git for Windows 2.47.1、2.46.2、2.45.2の各バージョンで差し替え （日本時間2025-01-15 03:11） 266 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 09:18:49.62 ID:vFJWSuXb0.net] ローカル上の作業ブランチで複数回コミットして、まだマージやプッシュをしたくない状態のとき、 ここでPCやSSDが壊れたら痛いのでローカルの内容をバックアップしておきたいとなったら、 どうやるのが常套手段なんでしょうか 267 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 09:22:23.44 ID:5LAJlDxM0.net] 個人作業用のブランチにpushすりゃいいじゃん 268 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 10:01:54.42 ID:RFmrvYtC0.net] 常套手段は知らんけど壊れることまで心配するならクラウドバックアップとRAIDじゃないの 手軽な手段ならpushとpush -fだな -fで困る人いないでしょ 269 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 10:05:22.41 ID:RFmrvYtC0.net] 汚すことができないやむを得ない事情があるなら自由になる別のリモートを増やしてブランチをミラーリングしておく 270 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 10:42:03.41 ID:JYmON0LL0.net] >>266 ・ディスクをレイドとかにして耐障害性を上げる ・ディスク／ファイルシステムのバックアップを取る ・バックアップ用の別のリモート・リポジトリにプッシュする ・共用リポジトリに別のブランチ名でプッシュしておく どれでも好きなのをどうぞ 全部やれば完璧 （最後のなら簡単、運用ルール的にかぶらないブランチ名の付け方決めとくだけでOK、個人名_ブランチ名 とか 271 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 12:27:44.30 ID:vFJWSuXb0.net] >>267-270 参考になりました、ありがとうございます .gitフォルダだけを圧縮して逃がしたりしていましたが、 自分しか使わない前提のブランチなら、リモートにプッシュしてしまってもよいものなのですね 272 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 12:36:39.07 ID:5LAJlDxM0.net] >>271 チームでやってるならチームのルールを確認 273 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 12:54:07.03 ID:JYmON0LL0.net] >>271 git のブランチなんていくら push しても容量がそんなに増えるようなもんじゃないし、邪魔にもならないんで駄目って言われることはほぼないよ フィルターしやすくしたり、名前かぶるの避けるためにブランチの命名規則だけは決めておくと良い （方針によってはバックアップは別のリポジトリがあるからそっち使えって言われることはあるかもしれない 274 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 18:26:22.96 ID:ZEFHCs1J0.net] >>266 ローカルにスタッシュする or 専用ブランにコミットした上で、.git以下を適当にバックアップするんじゃないの？ リモートに個人的なブランチをpushするのは抵抗感があるなぁ。 275 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 18:36:02.43 ID:vFJWSuXb0.net] >>274 >>271で書いたような、今自分がやっている方法と同じですね Gitの使い方としてどうかと思っていたのですが、それも間違いではないのですか 276 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 19:41:26.62 ID:ZEFHCs1J0.net] >>275 大丈夫じゃない？ https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain 277 名前：デフォルトの名無しさん mailto:sage [2025/01/24(金) 14:03:41.62 ID:/oFMYy+rM.net] 仕事でやってるならそれは個人的な作業ではないのだから堂々とリモートにpushすればよい OSSならそもそもforkしてるだろうからリモートは元々自分専用 278 名前：デフォルトの名無しさん mailto:sage [2025/01/25(土) 15:00:31.31 ID:i3NO8nb7M.net] 道具として異常 知恵遅れがしがみつく道具がgit 279 名前：30 mailto:sage [2025/01/25(土) 17:08:54.33 ID:i1hyUUYx0.net] じゃあ天才は何使ってんの 280 名前：デフォルトの名無しさん mailto:sage [2025/01/25(土) 17:22:25.79 ID:W3I6NstP0.net] 未だにsvnから移行できないじじいはいたな 281 名前：デフォルトの名無しさん mailto:sage [2025/01/25(土) 17:57:50.21 ID:aP269JYO0.net] better cvs として使ってます。本当にすみません。 ブランチとか良く使わないです 282 名前：デフォルトの名無しさん [2025/01/26(日) 13:26:52.01 ID:uiy/DQQ3H.net] やっぱりVisual Source Safeが一番わかりやすくていいよね 283 名前：デフォルトの名無しさん mailto:sage [2025/01/26(日) 16:30:13.37 ID:h32xfORHM.net] Better CVSではないGitならではのやり方と言えるのなんて、 複数のリモートリポジトリ間でpullし合うような真に分散管理された伝統的なOSS開発スタイルくらいだろ 基本的に大半の人の使い方はBetter CVSの域を出ない ローカルリポジトリがリモートリポジトリへの反映前のバッファとして使えて便利だな、という程度 284 名前：デフォルトの名無しさん mailto:sage [2025/01/26(日) 16:51:43.41 ID:v8RHgYNZ0.net] ↑中途半端にわかった気になってるじじい 285 名前：デフォルトの名無しさん mailto:sage [2025/01/26(日) 17:14:21.11 ID:OHuPDl3g0.net] >>283 もうちょっと上手に煽んないと乗れないぞ そもそもこのスレに cvs 使ったことあるやつがどれだけいると思ってんだ 30年前のアプリ比較に出しても自分が年寄りと表明することにしか まちもに cvs 使ってたやつなら、恥ずかしくこの書き込みできないんで、きちんと使ったことないのまでは分かるけど 286 名前：30 mailto:sage [2025/01/26(日) 22:56:56.08 ID:Im+l/vn00.net] CVSなら知ってるよ コンビニのことでしょ 287 名前：デフォルトの名無しさん [2025/01/27(月) 23:35:25.04 ID:5zVfH4ct0.net] >>285 40歳以上なら知っている 288 名前：デフォルトの名無しさん mailto:sage [2025/01/28(火) 00:30:38.67 ID:knz0Jl8ca.net] RCSの話をしたくなるね 289 名前：デフォルトの名無しさん [2025/01/28(火) 06:16:26.21 ID:OdcIn15O0.net] VSSもかなりあとまで使っていたけどな 35歳以上なら知っていることが多い 290 名前：デフォルトの名無しさん mailto:sage [2025/01/28(火) 12:37:10.14 ID:bnD9cEyX0.net] いまでもVisualStudioのソースコード管理はVSSライクなのあるよね。 Gitも使えるけど。 開発の中心じゃないメンバーも使う仕様書管理とかだとそっちの方が 評判高いというか、Gitは使わないよなw 291 名前：デフォルトの名無しさん [2025/01/28(火) 13:19:48.30 ID:dqvH8r5Ca.net] SVNも忘れないで 292 名前：デフォルトの名無しさん mailto:sage [2025/01/28(火) 20:38:47.97 ID:n6IrqaQHa.net] Gitを知ろう！昔のソース管理とGit の絵を見るとGitって難しい事してるな、って思う。 逆に古いツールは複雑なマージ出来るんだっけ？と不安になる。 293 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 13:05:47.15 ID:iK+g/tdh0.net] Gitはオープンソースのプロジェクトを分散管理するのが目的だろうから、 社内のソース管理とかに使うと、なんか前より面倒くさくなったなと感じる 294 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 13:38:14.63 ID:vsr4sfYf0.net] >>293 git は world wide にユニークな名前で管理して無限（おおげさな表現）にスケールすることが利点の1つなので 少人数のプロジェクトだとこの利点は感じ難いのは仕方ない、あらゆる利点は逆からみれば欠点なわけだし 295 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 13:41:47.19 ID:vsr4sfYf0.net] git の他の利点、例えばブランチを切ったり繋いだりするのが早くて操作も簡単 みたいなのに慣れてくると個人利用のみでも手放せなくなる 296 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 15:51:35.40 ID:O2q9bD9Z0.net] 正直、ローカルリポジトリを持たずに直接GitHubにコミットできるオプションがあったら便利だと思う クライアントとサーバーが等価なのがアーキテクチャとして美しいのはわかるけど、 安定したネットワーク環境とリモートへの反映が前提なら実用的にはあまり意味ないのよね 余計な手間が増えるだけだし、作業者マインドの人(情シスとか情シスとか)に理解させるのに苦労する 297 名前：デフォルトの名無しさん [2025/01/29(水) 16:45:51.30 ID:NEN1+s6c0.net] なるほど、必要なら作ってくれ 298 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 17:08:05.77 ID:j23j/EVS0.net] 最近のGitHubはweb上で編集してプルリク投げまで完結できたよね？ あんまし使ったことないけど 299 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 17:26:33.12 ID:wXwWo4Yf0.net] 会社ではプッシュばっかり使っててプルリクの概念がいまだによくわかってない このブランチをプルしてマージしてください ってお願いするのがプルリクなんだよね？ 会社でこれをやるなら、ソース管理者みたいな人を立ててその人に依頼すんの？ 300 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 18:19:19.91 ID:u4GPoyB40.net] 君のチームのワークフローに合わせればいい。Gitだからどうとかじゃなく。 考え方は簡単、他者の承認またはレビューを必要とするときに pull request を作る、承認したらマージする、これだけ。 例えばタスク毎にメイン開発者AとレビュワーBがアサインされていて、リリースにオーナーCの承認を必要とするなら、下記が考えられる。 開発タスクのクローズ : AがタスクのブランチからmainブランチへのPRを作成し、Bにレビューを依頼。BがPRを承認し、AまたはBがマージ。 リリース : 開発チームの誰かが main から production ブランチへのPRを作成し、Cがマージ。その後GitHub Actions等のCI/CDツールが本番環境へデプロイする。 上記はよくある流れではあるが、GitやGitHubだからこうするというわけではないことに留意せよ。 開発フローはそれらとは独立に決められるべきであり、それをGitHubの機能を使って実装するだけだ。 301 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 19:20:58.17 ID:vsr4sfYf0.net] >>299 ワークフロー次第だが、もともと想定されてるのは 個人用公開リポジトリ ←push― 個人用ローカルリポジトリ ←commit― 作業ディレクトリ という環境を全員が持ってる前提で プルリクエストというのは、「俺の公開リポジトリに push したので、そこからお前のリポジトリに pull してくれ」という要求 これを責任者宛に出せば チームリーダーとかリリース・マネージャーとかの責任者がチェックして問題なければ、それを彼の個人ローカル・リポジトリでマージする（その後に彼の公開リポジトリに push して公開する） 302 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 21:57:23.24 ID:u4GPoyB40.net] 企業での開発においては共通のリポジトリを皆で触るのが一般的であり、”pull” requestは実際には同一リポジトリ内でのマージのみに使用する forkはガバナンスを困難にし情報漏洩につながるリスクがあるため、そもそもorganizationまたはenterpriseのポリシーで一律禁止するのがベストプラクティス 303 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 01:09:50.68 ID:o8nH7UIQ0.net] GitLabだとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ 304 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 01:12:38.22 ID:sgBWR4v+0.net] プルだと向こうが主語だもんな 引っ張ってぇ、的な 305 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 08:03:04.92 ID:yzi2OnyQ0.net] リクエストだから向こうが主語だよ 何いってんのさ どちらも依頼だけど取り込む段階に着目するかマージする段階に着目するかの違いだよ 306 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 08:48:49.49 ID:5L7oVd850.net] pull ってのは 「fetch して merge 」の省略形なので当然 merge もリクエストしてる 分散リポジトリなら先に merge の前に fetch してもらう必要があるので pull リクエストを出す 共用リポジトリとかなら fetch する必要がないので単なる merge リクエストを出す この違いが分かって使い分けできないやつが git 使ってるの爆笑ものなんだが ここは分かってないやつ多そうだな 307 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 10:31:13.18 ID:Be3+/jiBM.net] 企業内での開発の場合、pull(merge) requestは要請というよりレビューと承認を求める意味合いが強い。 結局マージを行うのも同じ人(別の人間かもしれないが基本的には同一の責任主体と見做せる)であることがほとんどだから。 その意味ではシンプルに review request 308 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 10:47:11.99 ID:sLaRrBQRM.net] 企業内での開発の場合、pull(merge) requestはコードレビューと承認を得ることを目的に作成され、その上でマージを誰が行うかは重要ではないんだよね。 というか多くのチームでは作成した本人がマージしている。 このへんの用語は実際初心者に教えてると理解しづらいようで、pullじゃなくてmergeにしたら解決というものでもない。 まあ、だからってもっと良い呼称は俺は思いつかないが。 309 名前：307 mailto:sage [2025/01/30(木) 10:52:20.88 ID:sLaRrBQRM.net] すまん、>>307は誤って書き込んだ。 310 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 11:21:31.02 ID:aXMNWhD7r.net] >>306 じゃあなんでGitLabはプルリクエストじゃなくてマージリクエストなの？ GitLabユーザーはfetchなんてしないのかしら？ 311 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 15:36:37.44 ID:yII0bm57d.net] しない。したとしても極めて稀。 OSS開発者のためのソーシャルコーディングサービスとして開発されたGitHubと異なり、 GitLabは当初からエンタープライズでのクローズドな開発を前提としており、>>302の通り基本的に共有リポジトリを使うから。 312 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 16:07:15.77 ID:5L7oVd850.net] >>308 それはちょっと違う 本来は review とかが全部終わった完成したものについて出すのが merge/pull リクエスト review する人と merge する人が一緒の時に手抜きで一回で済ますだけでワークフロー上は完全に別物 313 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 16:38:36.48 ID:NcQM/92I0.net] >>312 使ったことがあるとは思えん pull requestに対するレビュー結果の追加とマージの実行は別の操作だぞ 314 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 16:53:48.01 ID:sgBWR4v+0.net] 盛り上がってまいりました 315 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 17:25:50.04 ID:5L7oVd850.net] >>310 >>312 github は分散リポジトリを念頭にサーバ上の統合作業の用語を選択した gitlab は共用リポジトリを念頭にサーバ上の統合作業の用語を選択した これは本来の git の意図とはズレてるのでリーナスが切れた（サーバ上では統合作業 merge/pull しない、それらは手元のローカル・リポジトリでやるのが git 本来の流儀） git で pull request はもともと相手のローカル・リポジトリへの pull を要求するというそのままの意味（github は用語を変に流用しただけ、本来の使い方ではない linux kernel だと subsystem maintainer とかが subsystem の開発リポジトリから完成した分をリーナスの個人リポジトリに取り込んでリリースに含めるよう最終的な要求するのが pull request の意味 コードのレビューとかはもっとずっと前に ML とかで多くの人が議論し尽くしてる、そういうのが全部終わって次のバージョンのリリースに含めて良くなったら pull request 出す 316 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 21:25:55.92 ID:yzi2OnyQ0.net] fetchしないってかなり語弊があるよな 317 名前：デフォルトの名無しさん mailto:sage [2025/01/31(金) 09:01:26.86 ID:fWRcePGc0.net] >>315 で、あんたは>>299が会社でGitHubのpull requestを活用するにあたってLinuxカーネルと同様のMLベースのプロセスを導入すべきだと言いたいのか？ でないならその情報は質問者にとってたんなるのいずだ 318 名前：デフォルトの名無しさん mailto:sage [2025/01/31(金) 09:31:32.44 ID:uF0JLDg90.net] >>317 ここは GitHub スレではなくて git スレだ git 本来の用法と用語があるんだ GitHub の勝手用語を前提にしていない 319 名前：デフォルトの名無しさん mailto:sage [2025/01/31(金) 10:15:03.05 ID:9dfMKsJi0.net] >>317 > あんたはGitHubのpull requestを活用するにあって 俺に聞いてる？ 俺のアドバイスなら git 本来の pull request は業務フローによって必要だったり不要だったりする、参考に知っておくと良い Github の pull request は使う必要も学ぶ必要もないゴミ、そのまま忘れてしまって良い、周りで使おうとするやついたら全力で止めるレベル 320 名前：デフォルトの名無しさん [2025/02/05(水) 14:37:49.09 ID:RWIQAOlpa.net] fork して勝手に成長させて fork 側が立派に育ったら pull request なんてしなくても勝手に pull してくれるのが理想 321 名前：デフォルトの名無しさん mailto:sage [2025/02/06(木) 01:42:29.43 ID:3KBUKtr20.net] >>320 いつ、誰が、何のために、どこから、どこへ pull すべきか指定するのが pull request なんだが 超絶AIでも開発してタイミングや理由を説明するのか？ 誰がはどうする？ 人間が AI から命令を受け取るのか？ 責任者不明のコミットができる GitHub状態なのか？ 楽し過ぎるな。それやるくらいなら多分AIに全部のプログラム書かせた方が早いと思うぞ 322 名前：デフォルトの名無しさん mailto:sage [2025/02/08(土) 21:27:04.90 ID:yVxtkiH10.net] また説教おじさん 323 名前：デフォルトの名無しさん mailto:sage [2025/02/12(水) 02:05:12.31 ID:3tQGE9a70.net] git stashで、新規のファイルも一時退避したいのですが、デフォだと無視されるようですね 何か方法はないでしょうか ま、新規ファイルはgitに未登録だから放置プレイせよ、ということなのかもしれませんが なんとなくスッキリしないというか 324 名前：デフォルトの名無しさん mailto:sage [2025/02/12(水) 02:14:56.55 ID:W9y8zQE70.net] git add -A してから git stash 325 名前：デフォルトの名無しさん mailto:sage [2025/02/12(水) 02:20:20.50 ID:J/UI6pYQ0.net] -u こんなとこ書き込む暇あったらググるかAIに聞け 326 名前：デフォルトの名無しさん mailto:sage [2025/02/13(木) 23:46:41.27 ID:hYbijExcr.net] スレ過疎ってるんだからええやん別に 327 名前：デフォルトの名無しさん mailto:sage [2025/02/14(金) 12:09:29.98 ID:wNm1lBEt0.net] 2月寒いなあ、まだ冬型続くのかな？ みたいな質問するのは挨拶、話題作り、ネタ提供で雑談のきっかけにしたいだけなのに 「そんなのはググって気象庁のサイトを調べろ」とか言われちゃう感じだよねw 328 名前：デフォルトの名無しさん mailto:sage [2025/02/14(金) 12:41:44.04 ID:cflAAi0P0.net] >>327 みんなの集まる会議の席上で天気の質問とか始めたら、「さっさと始めろ、他人の時間を無駄にするな」って怒られるだろ 個人の雑談と、多数が集まる場所での発言は違うんじゃないかな？ 他人の時間を無駄にしないために自分で調べられることは調べた上で、分からない部分があったら質問するのが人としての礼儀 329 名前：デフォルトの名無しさん mailto:sage [2025/02/14(金) 12:57:41.89 ID:b+7l3s230.net] はたから見た感想 質問者の「ま、～というか」っていう余計なくだりを書かなければ余計な苦言も返されなかったかもと思った 330 名前：デフォルトの名無しさん mailto:sage [2025/02/15(土) 00:32:15.20 ID:6v957rAir.net] >>328 このスレに多数の人が集まってるって言えるの？ 331 名前：デフォルトの名無しさん mailto:sage [2025/02/15(土) 01:49:01.01 ID:ueLeU4Nj0.net] >>330 俺とお前の二人きりでないのは確実だ 332 名前：デフォルトの名無しさん [2025/02/15(土) 05:04:09.56 ID:0wMi8etC0.net] >>331 俺とお前と大五郎 333 名前：デフォルトの名無しさん [2025/02/16(日) 12:05:30.15 ID:rAQQ2/+ca.net] 点呼始めると急に人減るからな 334 名前：デフォルトの名無しさん [2025/02/26(水) 19:03:01.07 ID:dyHUusCc0.net] GitはConflictの修正で強制的にVim使わせんのやめてほしいんだが WindowsユーザーがVimなんて日常的に使ってるわけねーんだが想像力ねーのかよ馬鹿が みんなしち面倒だから極力競合しないように気を使ってて競合修正すること自体も少ないから たまに競合すると修正するのだけでも怠いのにそれに輪を加えてVim使わされるから調べ物が二倍になんだよハゲが さっさと競合の修正をVSCodeのエディタでできるようにしろボケ 335 名前：デフォルトの名無しさん mailto:sage [2025/02/26(水) 21:59:35.09 ID:tc9QKrsR0.net] >>334 お前のって変更できないの？ 何をつかってるんだろう 336 名前：デフォルトの名無しさん mailto:sage [2025/02/26(水) 22:20:46.32 ID:uVlYXScm0.net] Vimの使い方を必死で調べる癖に、Gitの使い方は調べないのか おかしいよな、やっぱり釣りかな 337 名前：デフォルトの名無しさん mailto:sage [2025/02/26(水) 22:22:24.99 ID:ZoHclDk+0.net] キレてんね～ https://docs.github.com/ja/get-started/getting-started-with-git/associating-text-editors-with-git 338 名前：デフォルトの名無しさん [2025/02/26(水) 22:24:39.42 ID:dyHUusCc0.net] >>335 開発環境はVisual Studio 2022かVScodeなんだがGitはTerminalのPowerShellのCLIでコマンド入力して使ってんだわ だからTerminalからbarnchをmergeしたときに競合が起きると強制的にVimになってただでさえ競合でマズっ！て動揺しとんのlにブチギレそうになるんよ TerminalからGitを使って競合したときにVSCodeでDiffする機能がググってもみつからねーんだよ 339 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 06:49:34.86 ID:CZtmiDI/M.net] まあ、ぐーぐるが蔓延ってからフリーソフトはダメになったよな マイクロソフトを使ってるやつらが雪崩れ込んできてからさらに異質になってきた 340 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 07:25:35.18 ID:1tEOde+m0.net] どういう意味？ 341 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 08:17:38.02 ID:3+Px+dpt0.net] ドキュメント読まない、考えない奴が増えたということでは？ 342 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 09:10:37.13 ID:8vSp/RjD0.net] この流れでフリーソフトがダメになったとか言い出すの謎 初心者の不満に優しい回答者が解決してあげただけで、不満はお門違いなもので必要な機能は完全な形で提供されてた 343 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 09:36:53.23 ID:XU/twqEe0.net] git は機能が多過ぎてマニュアル読んでもどこに書いてあるんだか見つけれないというのはあるんだと思う けなしたりせずに最初から丁寧に質問すれば良いのに、質問者が悪い 344 名前：デフォルトの名無しさん [2025/02/27(木) 12:49:05.52 ID:VQNvJTxha.net] >>338 だっさ 345 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 13:38:03.41 ID:XU/twqEe0.net] 個人的には unix/linux屋の感性だとエディタとか特定のやつ強制されたら、もう宣戦布告扱いなんで絶対に変更できるようになってる EDITOR環境変数とかに追従しないならチュートリアルの先頭あたりで説明がある とういの感覚なんだけど Windows みたいにお仕着せに甘んじるのに慣れさせられた子羊ちゃんたちには厳しい世界に見えるんだろうか？ 346 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 15:26:47.55 ID:epdZy57f0.net] >>343 難しくてわからない質問されて見下された気がしてイラッとしたからとりあえず煽っとくまで読んだ 347 名前：デフォルトの名無しさん mailto:sage [2025/02/27(木) 18:59:01.12 ID:8vSp/RjD0.net] おかしな人を一人見ただけで最近の子は～とか言い出しちゃうのって老化現象なのでは 348 名前：デフォルトの名無しさん [2025/02/28(金) 01:35:09.82 ID:1HSOHgVq0.net] >>338 ターミナルも仕様がよくわからないのによく使うな 比較的、新しいものを使うなら古い方を知ったうえで使わないと 349 名前：デフォルトの名無しさん mailto:sage [2025/02/28(金) 02:45:09.17 ID:anIDZvfV0.net] ここ老人ばかりだし老化現象ではと言われてもあんまり効かないよね 350 名前：デフォルトの名無しさん mailto:sage [2025/02/28(金) 08:41:15.61 ID:rekq6zs60.net] >>337 に礼くらいしろ。 感謝すらできないタダメシ寄生虫かよ。 351 名前：デフォルトの名無しさん mailto:sage [2025/02/28(金) 09:19:01.12 ID:f1y1aNyV0.net] 礼を求めるのはムリだろー 素直に教えを請うのではなく怒り散らすことで回りが俺様を助けてくれることを期待する駄々っ子タイプなのは最初の発言からわかってる 352 名前：デフォルトの名無しさん mailto:sage [2025/02/28(金) 09:30:18.88 ID:f1y1aNyV0.net] 今回の場合、Gitのダメなところをぶちまけて憂さ晴らししようとす来たら反論で恥かかされてさらに怒ってるまである 353 名前：デフォルトの名無しさん [2025/03/01(土) 11:36:53.90 ID:dZ2eBKvGa.net] 久々に落ちて来た餌に群がる深海魚のようでつね 354 名前：デフォルトの名無しさん mailto:sage [2025/03/01(土) 12:39:20.26 ID:uxtJasyd0.net] よく言われる 顔が深海魚みたいだって 355 名前：デフォルトの名無しさん [2025/03/05(水) 20:27:54.18 ID:k4iH0qBY0.net] masterからbranch切ってコミットして、VSCodeにSyncronizeってボタンでたからそれ押したらmasterブランチで？に？pushされた これってコマンドだとどういうコマンド使ったことになるの？ 何か嫌だったからmasterブランチの方はpullしてrevertして、masterと新しく切ったbranchをpushしなおした 356 名前：デフォルトの名無しさん mailto:sage [2025/03/05(水) 20:32:53.30 ID:DnMeoT1g0.net] GitはCLIの方が圧倒的に使いやすいわ GUIやとでけへんことが多すぎるし逆に面倒やからな ニワカどもがSourcetreeとかGithub Desktopとかを初心者にすすめんのやめーや 最初が肝心なんやからどうせ教えるならしっかり手取り足取りCLIで教えたれ 357 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 02:17:50.54 ID:X0p8pnT00.net] コミット履歴見ながらあれこれやるときはcliはやってられんでしょ 358 名前：デフォルトの名無しさん [2025/03/06(木) 08:13:14.54 ID:SoBTsc5U0.net] サーバ側のログ見たけどエラーログしか吐いてなくて、アクセスログ的なログは無かった 359 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 08:37:02.92 ID:TZy25+2E0.net] >>357 why? CLI しか使ったことないけど 360 名前：デフォルトの名無しさん [2025/03/06(木) 13:33:57.70 ID:SW3gTDW+M.net] >>356 コマンドはネット上に嘘が大量に書かれているからなあ 361 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 14:56:33.55 ID:hrpDJRUa0.net] >>360 マジで？ 困った時しか調べないので気付いてない。 362 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 15:07:24.98 ID:X0p8pnT00.net] >>359 マウスなら数手で済むところをハッシュ見て打ち込んでスクロールアウトしたから見直してとか非効率 何事も向き不向きがある 363 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 16:54:30.08 ID:TZy25+2E0.net] >>362 意味わからん 普通キーボードから手を離してマウスに手を持っていく暇があれば、その時間にコマンド打ち終わって実行結果の確認まで終わって次の作業始めれるけど？ CLI使うかエディタのショートカット使うかの2択だろ、マウスの出る幕はない 364 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 17:47:20.86 ID:X0p8pnT00.net] >>363 それいうならおれはトラックポイント使ってるから持ち替えるなんて無駄はとっくの昔に排除してるっての おれはCLIでも使える 環境変えた時に困るからな で比較した上で言ってる 365 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 18:43:44.49 ID:TZy25+2E0.net] >>364 何が言いたいか分からん、俺は無能なのでGUIで十分って言ってるの？ 「CLIだとやってられない」の根拠をまるで示せてないけど？ command のオプションとか使いこなせてないだろうことは何となく察せられる。例えば履歴見る時に git log に -G とか --grep とか使ったことある？ この違いって即答できる？ 366 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 19:00:28.81 ID:/b+y/+WW0.net] いやGitは明らかにGUIよりCLIの方が使いやすいんやがwww いやちゃうなCLIが使いやすいんやなくてGUIがどれもクソすぎるんや 唯一マシなGitKrakenはクソ高いサブスクやしな 367 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 19:10:55.39 ID:EYycW5pS0.net] CLI派はステージする行を取捨選択したいときどうするの？ 煽りたいわけじゃなくて興味がある なお俺は普段VSCodeとlazygitを使っていて込み入った操作のときだけCLI使っている 368 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 20:03:56.86 ID:TZy25+2E0.net] >>367 git add -e でエディタで選択 git add -i でCLIメニューで選択 個人的には前者を多用してる 369 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 23:00:54.80 ID:FATO06L/0.net] マウスに一切持ち替えないCLI過激派の人ってハッシュは目視確認して手で打ってるの？ HEAD~~とかHEAD~4とかでだいたい済むから手打ちするにしても稀な感じなのかな 370 名前：デフォルトの名無しさん mailto:sage [2025/03/06(木) 23:23:19.37 ID:54POgzsF0.net] 過激派じゃないからやったことないけど、マウス使わずにCLI単体で目的のハッシュ検索→コピー→ペースト出来んじゃないの？ 371 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 00:54:33.86 ID:t6N/68bn0.net] CLI で hash値を入れることなんてまずないだろ 直近のは HEAD やブランチ名からたどるし、古いのはタグ打ってたり、検索条件で特定する どうしても hash値で特定したい時は先頭の4文字とか打つだけでいけるので全部入れる必要はないよ、そんな機会はめったにないが あとやろうと思えばCLIでもエディタ操作でマウス以上に高速にコピペできるけど 372 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 02:01:32.04 ID:hA31zhIA0.net] GUIでポトペタばっかしとる奴らの前提が空で覚えるの前提なん草 そもそもTerminalもGitbashもインテリセンス効くことを知らんの無知すぎてクソワロタ 373 名前：デフォルトの名無しさん [2025/03/07(金) 02:20:38.51 ID:DC3oMiFw0.net] 自分がやっていることを説明しない、説明できないタイプは、コマンドに逃げる傾向があるんだよな。 374 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 05:10:53.94 ID:rO0CBAe5d.net] >>373 というより、そうする必要があるかどうか次第だな >>368からも分かる通り、メクラコミット中心ならCLIで十分、コミット内容の細かな編集が多いならCLIの範疇だけでは難しい 375 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 08:46:11.25 ID:t6N/68bn0.net] >>374 難しくないだろ git add -e で完璧制御できる パッチをそのまま目視できて編集できるんだから、もっとも確実 どんな細かい変更でも自由、なんらら一行に複数の変更がある場合に一部だけとか、実際にソースにない変更も可能 376 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 09:59:34.81 ID:qPWIu0Mm0.net] エディタ使ったらそれもうCLIじゃないでしょ TUIではあるけど、それを広義のCLIと認めるならlazygitやtigのような実質GUIと変わらんようなTUIクライアントもCLIになってしまうがそれでよいか 377 名前：デフォルトの名無しさん [2025/03/07(金) 10:28:55.57 ID:DC3oMiFw0.net] Gitを使っておきながら、他人にはわからないコマンドだけの手順を書くやつは必ずいるしな 378 名前：デフォルトの名無しさん [2025/03/07(金) 10:52:06.81 ID:i3TW8fQU0.net] >>376 こんなの暴論だろ どうやってコード書くんだよ 379 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 11:15:57.74 ID:TL3VpnxxM.net] コーディングとは違ってステージ時のパッチ編集はGitのために行う操作なんだから、GUIクライアントとの比較の文脈ではGitの操作の一部と見做すべきでしょ git guiはCLIか？git add -eでVSCodeを開くのはCLIか？ エディタを呼び出した時点でもはや純粋にCLIと呼べない以上、程度問題でしかないってことだよ 380 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 11:23:23.99 ID:t6N/68bn0.net] >>379 CLI といにはもともとがスクリプト書いたり、エディターから呼び出すパーツを想定してあって、毎回直接打たないといけないって意味じゃないぞ、あくまでも git にアクセスするインターフェイスの種類 自分用にカスタマイズして使うのは当然 381 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 11:35:48.56 ID:TL3VpnxxM.net] そう。そしてGUIクライアントも同様にCLIを呼び出すインターフェースに過ぎない。 だから変な差別意識持たずに仲良くしような。 382 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 11:44:27.31 ID:t6N/68bn0.net] >>381 インターフェイスというのは「呼び出し側が理解して制御してる部分」と「制御していないブラックボクスとして扱う部分」の境界のことだ UI ならユーザとアプリの境界、その動作が内部でどのコマンドに展開されるか想定してばスクリプトやエディタから呼んでもCLI 一方でボタン押すだけで中でどのコマンドに変わるのか全然理解できてなければCLIではない 383 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 11:49:35.66 ID:t6N/68bn0.net] ユーザーが制御できてるか簡易に見分ける方法は「自由に変更できるか」だ 呼び出すコマンドを理解する必要があって自由に変更できるならボタンからだろうショートカットからだろうとCLIでいい 自由に扱えないならそれはインターフェイスの向こう側だ 384 名前：デフォルトの名無しさん [2025/03/07(金) 12:50:44.02 ID:i3TW8fQU0.net] 正直そんな事どうでもいいから>>355教えてほしいです 385 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 13:45:02.36 ID:hv4T53nE0.net] >>371 それ都合のいいようにCLIの不利なケースを排除してるだけだろ お前みたいなやつは死ぬほど見てきた CLIで曲芸してるだけ 適材適所で使うってだけの話を受け入れられない 386 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 13:58:21.86 ID:t6N/68bn0.net] >>385 そもそもCLIで使う前提でコミットログ書くし、ブランチ切るし、タグ打つし、git のUIは最初からそういう設計になってつんだよ 全部のハッシュ打たなくて確定できるまでの文字打てばすむのもそう git は CLI を使うプログラマによって設計開発発展してきた履歴があるので CLI で困ることはない 「CLIではやってられない」とか言い出すのはそいつが未熟で git に慣れてないだけの妄想 まあ全員が git に慣れてる必要はないので口を閉じて「馬鹿でも使えるものは馬鹿しか使わない」という世界に閉じこもってろ 387 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 14:16:08.04 ID:hv4T53nE0.net] >>386 マウスの持ち替え気にするくせにハッシュを目視で確認して打ち込む非効率さは目をつぶる インタフェースやビジュアライズの大切さを無視するエンジニアとは仕事したくないね ちなデバッガももしかしてCLIかい？w 388 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 14:28:05.14 ID:0jIQFjkxH.net] >>386 君の意見を否定するつもりはないが、事実としてGitの公式ディストリビューションにはGUIが付属しているし、git gui コマンドも存在するし、公式サイトで非常に目立つ形で非公式のGUIクライアントを紹介している こんなところでヘイト撒いてる暇があったら削除するようリクエストしてきた方がいいぞ 389 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 14:58:36.90 ID:xU3go4h6a.net] CUIって自分の操作の履歴辿れるけど GUIは何やったか覚えてないとか 意図しない変化があったときに今何した？ってなるのが嫌 390 名前：デフォルトの名無しさん [2025/03/07(金) 15:02:30.73 ID:xU3go4h6a.net] >>355 の感じてる「なんか嫌」も >>389 と同じ理由だと思う 391 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 15:36:27.72 ID:t6N/68bn0.net] >>388 別にGUI使っちゃ駄目とは一言もいってないぞ、GUI使いたいやつだけ勝手に使ってれば良い、それで苦労しようが失敗しようが知ったこっちゃない 「CLIではやってられない」という虚言を否定してるだけ、俺はCLIで十分 392 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 15:40:54.21 ID:t6N/68bn0.net] >>387 キーボードで16進数4文字打つのが非効率なの？ マウス操作の方が早いの？ 俺とは違う技術で生きてるみたいだな デバッガやプロファイラは自作スクリプト経由のことが多いな、スクリプトなしで簡易にやるならエディタのマクロ 393 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 17:31:19.43 ID:hv4T53nE0.net] >>392 タイピングの問題でなく目視でハッシュを確認ってのが非人間的で非効率って言ってんの そういう受け取り方をするってことはやっぱりUI/UXの視点が欠如してるんだよお前は でデバッガをスクリプトで使うとは恐れ入った 全く別世界に生きてるのは同意 394 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 18:54:27.19 ID:t6N/68bn0.net] >>393 良く分からんが目が悪いの？ 普通はタグとか検索結果からの相対指定で使うんだよ 何らかで間違ってタグを消したとかごく稀にどうしてもハッシュ値で指定したい時に、年に1回くらい目視確認で4桁の数字打つだけだよ 簡単なんだけどなあ 395 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 19:04:16.99 ID:bYeAoHPJ0.net] チーム開発だと、かなり前の特定のコミットをrevertしたりcherry-pickしたりは全然珍しくないけどなあ 396 名前：デフォルトの名無しさん [2025/03/07(金) 20:04:21.73 ID:xU3go4h6a.net] GUIならHash目視しないのかな 397 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 20:40:14.65 ID:ZrsdmfZ80.net] 仕事でチーム作業してたらハッシュは4桁では足りないからやっぱ手打ちはヤダな バグトラッカーやクラウドのツールと交互に使うからマウスに持ち替えずにキーボードだけであらゆるGit操作を駆使！スゴイ腕前！とはならないかなあ やっぱり達人は5chもcurlで書き込んでんのかな 398 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 20:58:11.36 ID:t6N/68bn0.net] >>395 そもそもそういうのはref検索とかで指定しない？ ログを目視しながらハッシュ値を探したりしないと思うんだが ハッシュ値で指定することなんてめっにないんだから気にする時点で何か効率の悪いことしてる気がする 399 名前：デフォルトの名無しさん mailto:sage [2025/03/07(金) 21:01:27.92 ID:qVctmwDB0.net] GUIやCUIの原理主義者じゃない限り どっちでも使いやすいところで使い分ければ済む話だろ ただ、GUIに関しては、CUIのコマンドオプションの何を行うコマンドかが分かる程度に表記してほしい 英語表記でも微妙、日本語ならばなおさら困惑する できればCUIのコマンドオプションを併記してほしい 400 名前：デフォルトの名無しさん mailto:sage [2025/03/08(土) 00:55:57.26 ID:f1gAdLsE0.net] ハッシュ値指定しない人は多分GitHub使ったことないんだと思う 401 名前：デフォルトの名無しさん mailto:age [2025/03/08(土) 11:24:47.06 ID:lsvDMVeL0.net] Git v2.49.0-rc1 402 名前：デフォルトの名無しさん mailto:age [2025/03/08(土) 11:29:06.73 ID:lsvDMVeL0.net] >>401 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. 403 名前：デフォルトの名無しさん mailto:sage [2025/03/08(土) 12:22:24.00 ID:kCgnTDtk0.net] githubで全然草生やせないんだけど 404 名前：デフォルトの名無しさん mailto:sage [2025/03/09(日) 18:13:33.28 ID:fe3LNf260.net] >>357 gitk 見ながら CLI 操作ってのが個人的には最強 405 名前：デフォルトの名無しさん mailto:age [2025/03/11(火) 10:16:27.19 ID:gbyV8IdY0.net] Git v2.49.0-rc2 406 名前：デフォルトの名無しさん mailto:age [2025/03/15(土) 12:09:57.15 ID:PGLL/72K0.net] Git v2.49.0 407 名前：デフォルトの名無しさん mailto:age [2025/04/08(火) 16:01:12.91 ID:3wE3gtcN0.net] 「Git」誕生から20周年を記念してリーナス・トーバルズ氏が開発初期の裏事情や使用頻度の高いコマンドなどを明かす https://gigazine.net/news/20250408-git-20-years-linus-torvalds/ 408 名前：デフォルトの名無しさん mailto:sage [2025/04/09(水) 16:03:54.93 ID:IrWwI/nb0.net] 複数ファイル名を入力するときはGUIでポチポチ選択したい 409 名前：デフォルトの名無しさん mailto:sage [2025/04/18(金) 20:54:17.74 ID:pzk2UeIY0.net] 10日で開発したL・トーバルズ氏も想定外？--「Git」誕生から20年、定番VCSの軌跡とその影響 ps://japan.zdnet.com/article/35231917/ 410 名前：デフォルトの名無しさん [2025/04/27(日) 17:55:28.09 ID:sTr1luuSM.net] このスレッドはLinux開発のGitの世界を語りだす気持ち悪い人間がいるから困る 411 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 13:14:12.18 ID:UmAf9vRJ0.net] 最新版で行ったバグ修正の部分だけを旧バージョンにも適用したい場合、チェリーピックを行うことになりますか？ その場合、ログの樹形図には、このコミットを持ってきたよという線は作られずに、別々の作業という表現になってしまいますか？ 412 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 13:54:33.66 ID:F0izL13m0.net] >>411 それであってるよ 直接 cherry-pick せずにバグ修正だけ入ったブランチを作ってそっちをマージという形にするやり方も一応あるけど大した違いはない 系統樹にはならないのでコミットログにどこから cherry-pick したかを残しておく（変なオプション使わなければ勝手に残るよ） 413 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 17:08:27.77 ID:UmAf9vRJ0.net] >>412 ありがとうございます 旧バージョンのこういうメンテナンスは、チェリーピックを使っていくことになるのですね 414 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 17:42:53.69 ID:F0izL13m0.net] >>413 親子関係にない（できない）間でのパッチの流用は cherry-pick でやるのが基本 git のコードの移動は（特殊なの除くと）merge, rebase, cherry-pick の3つだけ 逆に言うと cherry-pick は最重要3役のひとつ 415 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 18:00:11.34 ID:eepuMYHW0.net] rebaseってcherry-pickの繰り返しと同じじゃねーの？ 416 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 20:13:23.49 ID:F0izL13m0.net] >>415 似てるけど違うよ、オプションにもよるけど ●rebase は今いるブランチを移動させる ○cherry-pick はよそのブランチからコピーしてくる コピーとムーブの違い、方向も逆なので注意 あと cherry-pick も範囲指定で複数一度にコピーできるよ 417 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 20:20:09.57 ID:eepuMYHW0.net] >>416 rebaseしても元のコミットは残ってるからmoveじゃないし 418 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 20:35:51.71 ID:F0izL13m0.net] >>417 何言ってるわからん ブランチを移動させたらもとのブランチはなくなる（ブランチに所属しなくなったコミットは後からガベコレで消される） もちろん別の名前でブランチが残っていればそっちは移動してないのでコミットは消されない 419 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 21:36:14.90 ID:eepuMYHW0.net] >>418 gitにコミットのmoveなんて概念ないでしょってこと 420 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 21:39:50.81 ID:F0izL13m0.net] >>419 概念はある 実装が移動先にコピーして後から削除になってるだけ（主に undo 用にしばらく残してる 421 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 21:48:52.03 ID:6KG6JIoe0.net] mergeもcherry-pickもrebaseも普通に新しいコミットを作る そのコミットの作り方がユースケースに応じて3種類あるってだけのこと 422 名前：デフォルトの名無しさん [2025/05/15(木) 22:25:09.18 ID:AuSI2AJ/0.net] >>415 同じだよ 423 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 22:42:29.15 ID:eepuMYHW0.net] >>420 だからハッシュ番号変わるんだからmoveじゃないって 自分でも元が残ってるって言ってんじゃん その理解大丈夫？ 424 名前：デフォルトの名無しさん mailto:sage [2025/05/15(木) 23:05:28.17 ID:F0izL13m0.net] >>423 コンピュータ技術ではコピーして元のを消すのもムーブいうんだよ IDとかアドレスが変わってもムーブって呼ぶの 知らなかったの？ 勉強になって良かったな 425 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 00:59:49.81 ID:9SpA05Ma0.net] 円錐を横から見た人が三角だといい下から見た人が丸だというような構図ですね 人は争いをやめられないので滅ぼすしかないですね 426 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 01:36:29.34 ID:b2vWvm610.net] >>424 そもそもコピーじゃないからな コミットの内容は元とは完全に別物であり、差分だけが再現されている 勉強になって良かったな 427 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 08:05:25.71 ID:D2sZkK900.net] >>426 幼稚園児か？ 完全一致じゃないとコピーじゃないとか言いだしたらファイルコピーとかも所有者とか日付とかいろいろ変わるのコピーじゃなくなるぞ git のは日付とか作者は変わらないのでまだ保存性高いぞ cherry-pick と rebase が一緒なんて恥ずかしいこと言ったの話をそらしてごまかしたいんだろうけど無理がありすぎる cherry-pick は元のが消えない、rebase は元のが消える、方向も逆、べつもの、あきらめろ 428 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 09:43:07.63 ID:L+lmGGRS0.net] >>427 分かって言ってるのかどうか知らないけど、日付が変わるとかのレベルじゃなく、そもそも差分箇所以外は原理上全くの別物よ 変更内容のムーブというならまだしもコミットのムーブは流石に意味不明 429 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 10:35:41.49 ID:D2sZkK900.net] >>428 誤魔化すな rebase と cherry-pick は別物、元が消える(ムーブ)のと、消えない(コピー)の違い ここで言ってるのは元が消えるかどうか、完全一致とかの話題ではない 430 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 10:46:52.99 ID:FmZiuEdw0.net] rebaseで元は消えないでしょおじいちゃん 431 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 10:57:16.90 ID:D2sZkK900.net] >>430 もしかして誤魔化してるじゃなくて本当に分かってないの？ マジ？ 432 名前：デフォルトの名無しさん [2025/05/16(金) 10:59:28.32 ID:iN5covy8d.net] まあ公式が同じだって言ってるしなあ 433 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 11:09:39.47 ID:D2sZkK900.net] 0┳A━B ┗X━Y を 0━A━B━X━Y にする時に使うのが rebase 0┳A━B━X━Y ┗X━Y にする時に使うのが cherry-pick 基本中の基本 434 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 11:30:53.42 ID:9SpA05Ma0.net] いやどう考えてもそのレベルの話は全員わかってるやろ この一連のやり取りに足りないのは知識でもIQでもなくEQ お前ら小学生からリベースしろ 435 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 11:33:59.63 ID:epkpTq3tM.net] >>431 rebaseはcherry-pickで新しいコミットが作られてそっちに単なるポインタであるブランチが移動したのと同等 コミット消すとか移動とかいう動作は含まれない どこからも参照されなくなったらいずれgcで消えるってだけ 436 名前：デフォルトの名無しさん [2025/05/16(金) 13:50:52.44 ID:BDyQbzP90.net] 英語が下手でコミットメッセージを書くのが苦手だったんだけど、AIで自動化したら快適になったぜ 437 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 14:44:19.53 ID:x3RHmTCL0.net] >>436 そうなるともう、ログなんか書かなくていいんじゃないのとなってくるな 438 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 14:58:50.14 ID:D2sZkK900.net] >>435 cherry-pick と rebase は別物って納得したんだな 439 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 15:09:24.62 ID:D2sZkK900.net] rebase の内部動作の話するんなら 1. 分岐点を自動で探し出す 2. 分岐点からヘッドまでを対象の場所へ cherry-pick する 3. 元の場所のブランチ名を消す 4. 新しい場所にブランチ名をつける 5. ガベコレで古いブランチのコミットが消える これを cherry-pick を繰り返すのと同じだと主張してる時点で何も分かってない 440 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 15:11:49.54 ID:FmZiuEdw0.net] moveなんてアホな説明しなけりゃよかったのにね 441 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 15:18:53.26 ID:D2sZkK900.net] >>440 移動してるだろ 432 見たら一目瞭然 コレが基本概念 内部実装の話しして誤魔化そうとしてても、お前が間抜けなこと言った時事は消えない 442 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 16:07:30.58 ID:Jf7EmrNva.net] >>436 英語で直感的にヤバい時のメッセージに気付く訓練もいるから、AIは使えばいいけど読み書きの練習はしておけよ、と思った。 443 名前：デフォルトの名無しさん [2025/05/16(金) 18:15:56.05 ID:Mw5Je42+0.net] とりあえずDt80は一度公式読んできなよ たかが間違って覚えてたところで誰も煽りやしないよ あと描いてたツリーで、XだのYだのをリベースなりチェリーピックなりしたやつはXダッシュとかYダッシュとかにしよう そこだけ流石に同じ文字じゃ読んでてちょっと気持ち悪すぎる 444 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 18:36:45.50 ID:D2sZkK900.net] >>443 今でも「rebase は cherry-pick を繰り返しただけ」と主張してるの？ そんな覚え違いしてるのお前だけだろ、この通りの文言があったらポインタ示してみろ どっかの変なサイトが誤訳してるのなら知らんが rebase は cherry-pick してるだけじゃないことはお前も完全に理解できてるだろ 445 名前：デフォルトの名無しさん [2025/05/16(金) 21:29:57.00 ID:iN5covy8d.net] このページのgit rebaseの項に書いてあるよ https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Patching 446 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 23:12:54.87 ID:D2sZkK900.net] >>445 どう訳したらそう誤解するんだ？ 別物だというのは文章から明らかだろう エスパーしてみると 違うからこそ basically ってわざわざ明確に書かれてるに、もしかして basically て単語知らなかったとか？ native のつかうbasically は「基本部分では、だいたいにおいて」みたいなニュアンスで、本当に同じ時には使わない 「だいたい同じ」を「同じ」って覚えてたんじゃないの？ 447 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 23:28:45.03 ID:CtDSSAzzH.net] >>446 さすがに苦しいぞ 448 名前：デフォルトの名無しさん mailto:sage [2025/05/16(金) 23:33:35.97 ID:D2sZkK900.net] >>447 でどう訳したの？ 449 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 08:56:34.42 ID:TogutASM0.net] 方向の違いとかコピーとムーブの違いが「同じ」と「だいたい同じ」の違いというわけか。 450 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 09:18:39.88 ID:S33C25YC0.net] 間違いを絶対認めたくないマン 公式まで否定 451 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 17:33:51.01 ID:t4AM4T1l0.net] >>450 あー、どう訳したか説明しないとこ見るとエスパーが図星なのか 公式が初心者向けに「ほぼ同じです、でもこういう点が違います。詳しい説明はこちらって」って書いてるのの最初のとこだけ見て「ほぼ」も見ないで、後に続く説明もリンク先の詳細も無視して同じって言い張ってただけか それはお前の読解力が足りてないだけ、公式のせいじゃないぞ 452 名前：デフォルトの名無しさん [2025/05/17(土) 17:48:34.70 ID:C8ddlcHs0.net] >>451 訳というかそもそもそのドキュメントは色んな言語版が用意されてて日本語のものもあるよ 訳が気になるなら読んでみよう 453 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 18:11:19.00 ID:t4AM4T1l0.net] >>452 誤魔化してないで「お前が」同じだと主張する部分を説明してみろ 少なくともリンク先の英語の初心者向けの紹介には書いてないぞ 本当に同じならお前が cherry-pick で rebase 実装してみろ、そうすればみんな納得するだろう、技術者なら実際にやれば同じか別物か分かるだろう git のソースコード読んだことないやつには想像もつかんだろうが rebase はかなり複雑なことをやってる、初心者向けのページすらまともに読み解けないお前には最初の1歩目の分岐点を探し出す作業ですら絶対に無理と予言しよう 454 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 20:46:35.58 ID:S33C25YC0.net] そこで何か違うか端的に説明できたらよかったねおじいちゃん 何がmoveしてんですかぁ？ commitじゃなくてbranchのことですかぁ？ じゃcopyってどうゆうことですかぁ？ 455 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 23:11:17.26 ID:t4AM4T1l0.net] >>454 話逸らさずに同じとういうことを証明してみろ 細かい事いえば山程違いがあるけど、違うというのは 432 で素人にも一目瞭然なのに覆せるわけないだろう 間違えた恥ずかしい事実はごまかせないぞ 456 名前：デフォルトの名無しさん mailto:sage [2025/05/17(土) 23:17:53.88 ID:pDSuIsUc0.net] 違いがあるというなら、あなたがコミットのコピー/ムーブと呼ぶものはどちらも実際には全く異なるコミットを作り出すでしょう そういうのをダブスタという 457 名前：デフォルトの名無しさん mailto:sage [2025/05/18(日) 00:30:50.11 ID:t1q8u3yl0.net] >>456 読解力ないの日本語のなんだな 458 名前：デフォルトの名無しさん mailto:sage [2025/05/18(日) 03:09:09.55 ID:G2loPi6x0.net] なんて？ 459 名前：デフォルトの名無しさん mailto:sage [2025/05/19(月) 09:09:53.56 ID:E91ALV1Y0.net] >>433 XY両方ではなく、XやYのみを取り込むのがcherry-pickというイメージだが 460 名前：デフォルトの名無しさん mailto:sage [2025/05/19(月) 21:35:49.68 ID:LwAOa5bv0.net] >>459 普通の範囲指定が効くので その図なら git cherry-pick ..Y みたいに指定すれば X と Y の両方 cherry-pick できるよ 461 名前：デフォルトの名無しさん mailto:sage [2025/05/20(火) 08:32:54.32 ID:IobDhVYO0.net] 会話が噛み合わないコントみたいなスレで草 みんな文意文脈にももっと気を配ろうぜ 462 名前：デフォルトの名無しさん mailto:sage [2025/05/20(火) 15:48:18.98 ID:iWs/HqBfa.net] 「エクスプローラー」の「Git」統合などが実現へ ～Microsoftが開発者向け新機能 ps://forest.watch.impress.co.jp/docs/news/2015419.html 463 名前：デフォルトの名無しさん mailto:sage [2025/05/20(火) 16:58:09.70 ID:lxraH8Xn0.net] 亀の出番がなくなるのか？ 464 名前：デフォルトの名無しさん mailto:sage [2025/05/21(水) 08:05:21.38 ID:oZBirtTV0.net] エクスプローラーなんて、Windows7のときに使わなくなったな 465 名前：デフォルトの名無しさん mailto:sage [2025/05/21(水) 10:18:53.96 ID:va6/rMbaa.net] MSアカウントにログインしないとExoplorer使えないとか もうWindows要らんな 466 名前：デフォルトの名無しさん mailto:sage [2025/05/25(日) 03:59:20.13 ID:5SaResX20.net] わざわざExplorerからコミットとかプッシュする奴おるんかw 467 名前：デフォルトの名無しさん mailto:sage [2025/05/25(日) 07:06:19.26 ID:EfROU4yga.net] OSのSystem領域も含めて全部がリモートリポジトリの運用かな。 468 名前：デフォルトの名無しさん mailto:sage [2025/05/25(日) 08:49:46.44 ID:JDhr0Ivk0.net] >>466 申し訳ありません、今でもTortoiseGitでやってます 469 名前：デフォルトの名無しさん mailto:sage [2025/05/25(日) 09:13:50.01 ID:TXvAFiBF0.net] Windowsだと、手取り足取り指示してあげないと自分で何もできない「開発者」をExcel方眼紙の手順書で「プログラミング」してあげるような仕事も多いから、 そういう場合に「開発者」の手元にいちいちGitクライアントを導入させるという頭悪い手順を記載する必要がなくなるなら便利かもしれない 470 名前：デフォルトの名無しさん mailto:age [2025/05/29(木) 02:32:23.75 ID:oHIdrLSz0.net] Git v2.50.0-rc0 471 名前：デフォルトの名無しさん mailto:age [2025/06/04(水) 13:13:31.34 ID:nhmcxHVz0.net] Git v2.50.0-rc1 472 名前：デフォルトの名無しさん [2025/06/06(金) 01:08:14.98 ID:45aWa19td.net] gitもはや20年か 473 名前：デフォルトの名無しさん mailto:sage [2025/06/07(土) 08:05:32.65 ID:tgCEw1aU0.net] gitアレルギー 474 名前：デフォルトの名無しさん mailto:age [2025/06/10(火) 09:49:47.00 ID:DFb9gzxN0.net] Git v2.50.0-rc2 475 名前：デフォルトの名無しさん mailto:age [2025/06/17(火) 08:04:33.42 ID:JQTnqwjt0.net] Git v2.50.0 476 名前：デフォルトの名無しさん mailto:sage [2025/06/18(水) 00:48:41.95 ID:zWpFFB0D0.net] オススメのgitクライアント教えて source treeはなんかuiの一つ一つがデカくて肌に合わなかった 477 名前：デフォルトの名無しさん mailto:sage [2025/06/18(水) 02:39:03.14 ID:QsB71xf70.net] 自分はlazygitとVSCodeだな 478 名前：デフォルトの名無しさん mailto:sage [2025/06/18(水) 08:16:55.75 ID:6RiwAFGc0.net] うちではSourceTreeというやつを使ってるよ 479 名前：デフォルトの名無しさん mailto:sage [2025/06/18(水) 09:02:23.67 ID:7Ghn3yO50.net] 使いにくいやつね 480 名前：デフォルトの名無しさん mailto:sage [2025/06/18(水) 18:04:24.45 ID:c2eS9NyS0.net] lazygitかSourcetreeだな。 481 名前：デフォルトの名無しさん mailto:sage [2025/06/19(木) 20:10:05.29 ID:dNWjhAfr0.net] わかばちゃんの中の人 ps://x.com/llminatoll/status/1935310637196095988?t=KJizsM3DHuYlJSyTCzcZcg&s=19 482 名前：デフォルトの名無しさん mailto:sage [2025/06/21(土) 23:55:27.59 ID:Rsg0aBc50.net] VSCodeの拡張機能で提供されてる Git Graphが 使いやすいね 483 名前：デフォルトの名無しさん mailto:sage [2025/06/22(日) 00:39:02.97 ID:L6Wg3CMhM.net] あれいいよね、見やすい ハッシュ手打ちの人がんばってw 484 名前：デフォルトの名無しさん mailto:sage [2025/06/22(日) 06:56:54.23 ID:APGUbecj0.net] CUI でもハッシュを手打ちすることなんてほぼないだろ ブランチもタグも検索も使ってないんだろうか？ 485 名前：デフォルトの名無しさん mailto:sage [2025/06/22(日) 18:51:38.68 ID:4jZfNTw30.net] >>482 んー でも、他のGitクライアントも似たもんじゃないの？ 486 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 11:27:58.47 ID:KosRMA640.net] 似たような、がどの辺を指してるかにもよる。 rebaseかstash簡単にしたい、tag打ちたい、ブランチ作りたいならだいたいどれでも出来る。 　ただ現場で初心者多くて教育面倒だし日本語じゃなきゃだめとかいうなら、SourceTreeか 非公式多言語版GitHub Desktopしかないと思う。 487 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 12:06:20.95 ID:9uUr9jSA0.net] >>486 で、ベストは？ 英語でも有料でも、なんでもいいので 488 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 12:11:55.90 ID:qqxmiRlS0.net] interactiveなrebaseをサポートできてないやつ多いでしょ 489 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 17:00:15.66 ID:KosRMA640.net] 基本は好きなの使えばいいよ。 対面レビューで追加コミット後に「レビューOKだからコミットひとつにまとめといて」って言われたり 「ウチは協力会社に外資いるから日本語コメントだめなんだ、英語にしといて」って言われない限り rebase(やsquash)やamend使うこともないだろうし。 490 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 18:37:21.89 ID:MPl++Mur0.net] いや rebase -i も --amend も使いまくりだろ 何なら一番多く使うコマンドまでありえる 一発で完璧な記録できて後は触らないみたいな超人じゃなきゃ、普通に多用するだろ 491 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 19:49:45.04 ID:Z8z+4HFt0.net] といっても元のコミットがある程度ちゃんと作られてることが前提じゃない？ 単に作業のチェックポイントとして気軽にコミットしてると、いざコードレビュー前に整理しようとしたときには元のコミットを無理に再利用するより resetして作り直した方が早いことが個人的には多い 書いてて思ったけど、元のコミットがすでに整理されている上で修正を入れる状況としては、コードレビューの中での修正があるね もしチームのポリシーとして瑣末な指摘反映をログに残さないことにしているなら、レビュー後マージ前にrebase -iするのは便利かもしれない 492 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 21:20:02.74 ID:MPl++Mur0.net] そっちじゃなくて手元で色々作り散らかしたコミット履歴を綺麗に読み易く整理してから、レビューに出す。 順番入れ替えたり、コミットメッセージを分かり易くしたり、不要な履歴を消したり、コミットを意味に合わせて分割したり、統合したり その整理に活躍するコマンドが rebase -i、慣れると手放せない 読み易く整理されてれば他人の時間の節約になる、試行錯誤とかタイポ修正とかの痕跡を他人に見せて時間を奪わなくてすむ 493 名前：デフォルトの名無しさん mailto:sage [2025/06/23(月) 22:25:23.37 ID:YcF93ZoT0.net] そんなの方法を議論する以前にもうAIにやらせたらいいんじゃないかという気もするが、 AIにやらせるならやっぱり一連のgitコマンドを直接生成させるのがいいのかなあ コマンドだと人間が実行前にレビューするのは辛いものがあるから、diff入りのコミットログみたいな形式で生成させて、resetした上でそれを反映するのがいいと思うんだけど 494 名前：デフォルトの名無しさん mailto:sage [2025/06/24(火) 07:59:57.08 ID:oSvYVpQb0.net] >>493 AI に期待し杉 今のAIはしょせん賢い検索エンジンに過ぎない 学習したことの最も多数派の意見をそれらしく繋ぎ合わせてるに過ぎない 素人が玄人の作業を真似るのには使えるけど、玄人の創造的作業の代替は無理 495 名前：デフォルトの名無しさん mailto:sage [2025/06/24(火) 08:31:50.93 ID:1VpUD11F0.net] >>492 プロトタイプであれやこれやするなら、さらにブランチ作って動くようになったら新しいブランチに Squash and Mergeして、そっちのブランチをレビュー対象にした方が楽なんじゃ？ 496 名前：デフォルトの名無しさん mailto:sage [2025/06/24(火) 10:30:20.42 ID:oSvYVpQb0.net] >>495 いやだから、色々なブランチに順不同で入ってるやつの共通部分を括りだして独立したコミットにしたり、一つのコミットを内容に合わせて複数に分割したり、ばらばらのを分かり易く統合したり やるべきこっとはいっぱいあるだろ merge も squash も amend も全部 rebase -i を使ってやる、rebase -i を何だと思ってるんだ？ 497 名前：デフォルトの名無しさん mailto:sage [2025/06/26(木) 10:59:58.77 ID:JcQLzuh60.net] amendやsquashを一般人が簡単にやりたいならGitHub Desktopの履歴のとこから出来るけど 使用説明が一切ないんだよなあ。圧倒的なドキュメント不足。 498 名前：デフォルトの名無しさん mailto:sage [2025/06/26(木) 12:02:10.03 ID:3juiMOaqM.net] >>496 アトミックに細かくコミットする人ならrebase -iでの整理は容易だろうけど、分割が多い場合は面倒臭すぎるでしょ resetしてやり直した方が早いわ 499 名前：デフォルトの名無しさん mailto:sage [2025/06/26(木) 14:45:21.20 ID:rhHx6Nng0.net] >>498 意味分からん 「細かくコミット」と「分割が多い」は同じじゃないの？ お前の用語での違いは何？ コミットを統合したり分割したりするのも rebase -i から始めるのに？ いくらでも変えられるのに何が問題なの？ 500 名前：デフォルトの名無しさん mailto:sage [2025/06/26(木) 17:51:44.27 ID:JcQLzuh60.net] 「細かくコミット」がバックアップ保証のつもり(で修正が動くかどうかも分からん)なら、 都度commitだけしといてpushは待っとけばいいんじゃないかなと思ったり。 501 名前：デフォルトの名無しさん mailto:sage [2025/06/27(金) 10:30:24.43 ID:KAeTyQMQ0.net] 当たり前だろ 動作確認できてないものpushすんなよ 502 名前：デフォルトの名無しさん mailto:sage [2025/06/27(金) 10:39:46.35 ID:iePZ28tO0.net] >>501 どこに push するか次第だよな 共有リポジトリや公開リポジトリに push しちゃ駄目だろうけど個人のバックアップ・リポジトリとかに push しとくのは自由 リポジトリやブランチを好きなだけ作れて高速に同期できるのが git の利点なんで限られた少数のリポジトリしか使わないのはもったいない 503 名前：デフォルトの名無しさん mailto:sage [2025/06/27(金) 10:46:55.51 ID:Vbo+wzUI0.net] GitHubでのチーム開発だと普通に共有リポジトリにpushするけどな。 ただしpush先はいわゆるfeatureブランチなど、そのタスク専用のブランチ。 draft pull requestを作っておいて他人から容易に目に見えるようにするとなお良い。 むしろ手元で長いこと留めてあいつ何やってんだろと思ったら突然クソデカpull request投げてくるような奴は嫌われるよ。まあ開発に限った話ではないが。 504 名前：デフォルトの名無しさん mailto:sage [2025/06/27(金) 14:47:42.22 ID:iePZ28tO0.net] >>503 その辺はチームの方針次第だね リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う（個人の意見 505 名前：デフォルトの名無しさん mailto:sage [2025/06/27(金) 15:24:34.92 ID:caL9+2zdM.net] >>504 本題からは逸れるんだが、企業での開発で個人リポジトリにforkする運用ってなんかメリットあるのかな？ 自分はこれまで共有リポジトリ運用しか見たことがない なお、新卒がいきなりforkして怒られてるのは何度か見た forkして複数の共有リポジトリを使うのは複数の会社がいてそれぞれガバナンスが違うケースなんかで珍しくないけど 506 名前：デフォルトの名無しさん mailto:sage [2025/06/27(金) 17:03:03.14 ID:iePZ28tO0.net] >>505 github みたいに fork って呼ぶから混乱するんじゃないかな？ オープンソースじゃないから単なる clone だろ 開発用の clone はいくつあっても良い、個人用でもデスクトップとノートPCとサーバと複数の場所にリポジトリもってて定期的に同期させたりしながら、移動中とか自宅とか会議中(笑)に開発したりできる もちろん会社の情報統制や社外秘情報の漏出防止のためにコピー禁止とか部屋外に持ち出し禁止とか決まりあれば従わないと駄目だが 507 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 00:10:08.26 ID:Nhn9wgjX0.net] Gitむずかしい… Pythonよりむずかしい… 508 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 11:34:58.63 ID:WNSkpT1F0.net] 雑にpushするブランチを作ってあるので ホイホイプッシュしてる 509 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 14:23:18.12 ID:ps+a9/JT0.net] いやPythonの方が難しいでしょ 510 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 15:15:53.19 ID:Nhn9wgjX0.net] 初心者なんですが、 branch1とbranch2があって、 branch1にcheckout後に、>git merge branch2　と、 branch2にcheckout後に、>git merge branch1　って、 結果は同じ？ 511 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 15:31:34.65 ID:XJ1OnLan0.net] >>510 ソースコードの内容は同じになる ログは違う形になる ログはどのようにソースを扱ってきたかの履歴書や歴史書のようなものなので複雑で大規模なプロジェクトほど価値が出る 512 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 15:47:58.18 ID:Nhn9wgjX0.net] >>511 あ、 今やってみましたが、 mergeコマンド実行するときの自分がいるブランチのほうが、引き続き残るって感じですかね？ 513 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 16:06:18.63 ID:XJ1OnLan0.net] >>512 ブランチ自体はどちらも残る 自分がいる方のブランチはマージ結果を指す形で歴史が一方進む そうじゃない方のブランチはありのまま残る 514 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 17:09:16.02 ID:GU5N/G5Q0.net] 「自分が今いるブランチに指定したブランチの「内容」を混ぜ（merge）する」というのがコマンドの意味 当然 ・今いるブランチは書き換わってコミットが進む ・指定したブランチには変化なし 515 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 18:17:50.37 ID:Nhn9wgjX0.net] >>513 あ、 自分がいたほうじゃない方のブランチは、 branch3とかにつなげられますね… 516 名前：デフォルトの名無しさん mailto:sage [2025/06/28(土) 18:19:22.53 ID:Nhn9wgjX0.net] >>514 ですね わからない理由は、日本語のまともな解説が無いからですね… 海外の解説で、ようやく理解できました… 517 名前：デフォルトの名無しさん [2025/07/01(火) 20:11:53.56 ID:HVBtOzc60.net] 混じるからマージる 518 名前：デフォルトの名無しさん mailto:sage [2025/07/01(火) 22:46:34.19 ID:BgB6BrdO0.net] 去年のリリースの記憶をタグる 519 名前：デフォルトの名無しさん mailto:sage [2025/07/02(水) 21:57:57.01 ID:xYSFlqIW0.net] 頭悪い人って自分が理解できないのを説明する人のせいにしがちだよね 説明が悪いならなんでお前以外の人は理解できてるのかと 520 名前：デフォルトの名無しさん mailto:sage [2025/07/03(木) 03:33:50.65 ID:ZlHu/VzU0.net] 能力不足故に検索の仕方や聞き方が下手で自らが望む解説に効率的にアクセスできない ダニングクルーガー効果のような認知バイアス 元から他責的、依存的なせいで残り少しの努力を怠り多方面で理解不足に陥りがち この中のどれかか、複合要因ではないかな 521 名前：デフォルトの名無しさん mailto:sage [2025/07/05(土) 16:41:53.58 ID:Jt1MZnHo0.net] >>519 それは、 運良くいい説明を見れたからでしょ お前には無理そうだが 522 名前：デフォルトの名無しさん mailto:sage [2025/07/05(土) 17:28:57.77 ID:99i/fp2o0.net] 大丈夫だよ プログラム書いたらビッとコミットしてギュッとプッシュしてギャンよ 523 名前：デフォルトの名無しさん [2025/07/06(日) 09:39:11.50 ID:AHvPqc/80.net] コミッとコミットする 524 名前：デフォルトの名無しさん mailto:age [2025/07/09(水) 16:29:53.53 ID:NiP9rW7K0.net] Git v2.50.1 525 名前：デフォルトの名無しさん mailto:sage [2025/07/09(水) 20:54:58.43 ID:5nTmkCkK0.net] 初心者の質問ですが、 Linux（サーバー的なもの）に、GitHubのレポジトリをクローンして来て、 それをWindowsパソコンからSSH接続して、 Gitの履歴の図（Gitグラフ？）って見る方法ありますか？ 526 名前：デフォルトの名無しさん [2025/07/09(水) 22:47:25.77 ID:OQriWW8/0.net] ありますね 527 名前：デフォルトの名無しさん mailto:sage [2025/07/10(木) 12:47:26.79 ID:+1gidKVl0.net] >>526 会話を広げる癖をつけろ童貞 528 名前：デフォルトの名無しさん mailto:sage [2025/07/10(木) 20:49:27.62 ID:tN4eS5FO0.net] >>527 なら会話広げればいいじゃん。 529 名前：デフォルトの名無しさん mailto:sage [2025/07/13(日) 17:29:18.40 ID:QlUonva10.net] >>525 sshで git log --graph で履歴取ってきて、mermaid変換してmarkdown埋め込みにすればいいんじゃね？ 530 名前：デフォルトの名無しさん mailto:sage [2025/08/06(水) 12:13:19.02 ID:48BfQKJO0.net] >>527 あると信じて検索すれば報われますよというありがたい情報だぞ 531 名前：デフォルトの名無しさん mailto:sage [2025/08/13(水) 06:18:19.45 ID:YOB+IZc5r.net] やりますね 532 名前：デフォルトの名無しさん mailto:sage [2025/10/22(水) 09:23:57.49 ID:pnMMn99c0.net] https://forest.watch.impress.co.jp/docs/news/2056148.html 次のバージョンからgit svnが廃止されると書いてあるけど、 これはSubversionからの変換もできなくなるということでしょうか 533 名前：デフォルトの名無しさん [2025/10/22(水) 13:20:45.27 ID:2nDvyZJf0.net] Git for Windowsの次回メジャーリリースでの話をしてるならそうだよ 旧バージョンや本家を使うとか、svn2gitだとか別VCS経由とか手作業での移行だとかは出来るでしょう 534 名前：デフォルトの名無しさん mailto:sage [2025/10/22(水) 13:52:16.21 ID:Nfi7SE1t0.net] もうシンプルに使われてる機能だけをブラッシュアップすればいい思う。 互換性とか古いものをメンテし続けるのは大変だよ。 535 名前：デフォルトの名無しさん [2025/10/24(金) 14:37:23.45 ID:nAYKU6CIa.net] いまだに新規プロジェクトでSubversionからっていうのはもう洗脳されてるから放置で良いし Subversionから変換する気があるならもうとっくにやってるだろうし 536 名前：デフォルトの名無しさん mailto:sage [2025/10/24(金) 15:02:05.38 ID:ZcyI5XOE0.net] Windowsユーザーだと、業務でSVNを使わざるを得ないがGitコマンド経由で使うことで辛うじて自己の尊厳を保っていた人もいそうだな 電車止まりそう 537 名前：デフォルトの名無しさん mailto:sage [2025/10/24(金) 18:33:25.65 ID:J3E6mCG+0.net] >>536 そんなプロジェクトやだなぁ 538 名前：デフォルトの名無しさん mailto:sage [2025/10/24(金) 20:17:02.32 ID:NslM5AvMr.net] 令和なのにまだSVNで消耗してる人いるんだ 絶滅危惧種かな 539 名前：デフォルトの名無しさん mailto:sage [2025/10/24(金) 23:30:36.26 ID:vJAYr0tv0.net] >>536 Gitって、開発速度は遅くなるよね コードレビューとか丁寧にやると遅くなるよね… 540 名前：デフォルトの名無しさん mailto:sage [2025/10/25(土) 00:27:30.86 ID:a9lDbV800.net] >>539 規模（参加人数、開発期間、コードサイズ）次第。大きくなれば git 使った方が早い 541 名前：デフォルトの名無しさん mailto:sage [2025/10/25(土) 04:23:36.31 ID:kofX/eP60.net] >>539 gitだからコードレビューが必要って認識？ アホじゃね？ 542 名前：デフォルトの名無しさん mailto:sage [2025/10/25(土) 08:42:34.81 ID:/eT+OdROH.net] SVNと比較しての話なら、Gitはコミットやブランチの操作が遥かに軽量だからこそ、 チームが必要以上に面倒なワークフローを作り込みがちな面があることは否定できないな 非機能要件でちゃんとバージョン管理しろと書かれているからという理由だけでVCS使ってるような典型的な業務系でSVN使い続けてるようなとこだと、 レビュー済みまたはリリース済みのコードをコミットするだけみたいな運用は珍しくないからな そういった意味で、VCSの運用という点だけ見ればGitの方が複雑になる傾向があるとは思う 543 名前：デフォルトの名無しさん mailto:sage [2025/10/25(土) 12:06:31.87 ID:lNU8C84m0.net] >>540 まあ、 大規模だと、ちゃんと管理が必要ですね…

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef