Git 20

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

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

Git
http://git-scm.com/

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

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/
Git 19
https://mevius.5ch.net/test/read.cgi/tech/1667720427/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
2024/12/21(土) 10:33:21.60ID:Hifil6s+0
>>244
俺の書いた2つは、お前が書いた共通化の手間より断然難しいというのが一般的だと思うが、お前にとっては同レベルなんだろうなあ
まあ頑張れ
2024/12/21(土) 11:20:34.07ID:w/Sbt61U0
>>245
誤解させたようで申し訳ないが、単なるリポジトリの統合じゃなくてコードの共通化の話な
一般論として、集中管理は密結合を、分散管理は重複を招く
共通部分を介して密結合しているモジュール同士を切り離すには最悪共通部分をコピペすればよい
一方、分散管理され各所で個別化された重複を後から共通化する作業には、それほど自明な移行パスは存在しない
コードスタイルや設計の問題といえばそれだけだが、それはモノレポだって同じことだ
2024/12/21(土) 12:43:49.34ID:Hifil6s+0
>>246
一般論だけどコードの共通化は難しくない
というのは必須ではないし時間の制限がないから
バラバラのまま結合して共通化できるところから時間をかけてゆっくり丁寧に共通部品に切り替えていけば良い

linux kernel とか部品の共通化に3年とか5年とかかけてゆっくりやってることも多い、共通化しないこともある
（手間だけの問題と技術的難易度の問題という本質的な部分の優先度を分けて考えると理解できると思うよ）
2024/12/21(土) 14:07:45.37ID:w/Sbt61U0
うーん、難しいと感じるかどうかはあなたの感性の問題だから、比較対象と根拠を示してね
2024/12/21(土) 17:31:11.06ID:Hifil6s+0
>>248
感性の議論はしてないよ、お前がそう思ってるだけ

技術的にすぐに必要なものもと、条件によって無くてもすむし後回しにもできるものとを同次元で語るなって指摘なだけ
（後回しにして良いなら簡単、やらなくて済むのが一番簡単、という当たり前の指摘、感性の余地とかない）
2024/12/21(土) 18:23:30.51ID:Bjr5M2i00
>>249
読み返してみたけど>>244のツッコミがまとも
お前は自分の意見が一般的と言い張ってるだけ
2024/12/22(日) 11:25:46.33ID:KQFeVRO70
>>229-235
みなさんご意見どうもです

SVNを使っていた頃や、ステージングを使ってみる前は、
変更ファイルをいったんどこかに逃がして、作業フォルダを綺麗な状態に戻して、
今回コミットしたいところだけくっつけ直して、動作確認できたらそれらをすべてコミットして、
逃がしておいたものを元の場所に戻して作業再開、みたいな操作をしてました

結局プッシュする前にステージングし忘れなどを確認する必要があるとなると、
コミット時に確実に確認できる上記の方法もそんなに悪くはないってことですかね
2024/12/22(日) 14:58:34.96ID:1vLY5nWA0
>>251
それで良いんじゃないかな？
私だと2つに分けたのを両方先にコミットしておいて、両方別々にチェックアウトしてテストを走らせるけど
問題があれば巻き戻してやり直し
問題がなけば push

push 前ならローカルでいくらでもやり直しが効くのが git の利点なので個人的に分かりやすいやり方でやれば良い
慣れたらテストの自動化とか検討すると捗る
2025/01/01(水) 05:03:32.91ID:RPjVgyjf0
Git v2.48.0-rc1
2025/01/07(火) 09:45:36.95ID:DbV6+6Xe0
Git v2.48.0-rc2
2025/01/11(土) 11:00:17.95ID:tzzUwbv+0
Git v2.48.0
2025/01/12(日) 11:20:09.87ID:L3maUoeD0
サル先生でGitの学習を始めました
そこで質問です！
下記コマンドの中に dewfr という記述が存在するのですが、これは何を意味するのでしょうか？

> git config --global core.editor "\"[使用するエディタのパス]\""dewfr

参照：https://backlog.com/ja/git-tutorial/intro/06/
2025/01/12(日) 12:11:34.88ID:hjmuezNa0
先生が個人的に使っているエディタのファイル名なのでは？
直前がパス区切り文字で終わってるし
2025/01/12(日) 12:24:19.20ID:L3maUoeD0
あ〜なるほど！謎が解けました！
ありがとうございます！
2025/01/12(日) 17:53:29.03ID:6ooBodrm0
Git用GUIがなまじっか日本語化されていると、
求めているコマンドを探すときに面倒くさい
260デフォルトの名無しさん (ｽｯｯﾌﾟ Sdea-6XWm)
垢版 |
2025/01/12(日) 18:29:09.15ID:ORJFqn4Yd
>>259
わかる
261デフォルトの名無しさん (ｽｯｯﾌﾟ Sdea-6XWm)
垢版 |
2025/01/12(日) 18:29:16.18ID:ORJFqn4Yd
>>259
わかる
2025/01/15(水) 09:29:23.33ID:3C2APGzS0
Git v2.48.1
2025/01/15(水) 14:32:20.61ID:gq5bJ2fy0
Git for Windows 2.47.1(2)Latest
2025/01/15(水) 14:42:56.61ID:gq5bJ2fy0
Git Credential Managerの脆弱性で
Git for Windows 2.47.1、2.46.2、2.45.2の各バージョンで差し替え
（日本時間2025-01-15 03:11）
2025/01/23(木) 09:18:49.62ID:vFJWSuXb0
ローカル上の作業ブランチで複数回コミットして、まだマージやプッシュをしたくない状態のとき、
ここでPCやSSDが壊れたら痛いのでローカルの内容をバックアップしておきたいとなったら、
どうやるのが常套手段なんでしょうか
2025/01/23(木) 09:22:23.44ID:5LAJlDxM0
個人作業用のブランチにpushすりゃいいじゃん
2025/01/23(木) 10:01:54.42ID:RFmrvYtC0
常套手段は知らんけど壊れることまで心配するならクラウドバックアップとRAIDじゃないの
手軽な手段ならpushとpush -fだな
-fで困る人いないでしょ
2025/01/23(木) 10:05:22.41ID:RFmrvYtC0
汚すことができないやむを得ない事情があるなら自由になる別のリモートを増やしてブランチをミラーリングしておく
2025/01/23(木) 10:42:03.41ID:JYmON0LL0
>>265
・ディスクをレイドとかにして耐障害性を上げる
・ディスク／ファイルシステムのバックアップを取る
・バックアップ用の別のリモート・リポジトリにプッシュする
・共用リポジトリに別のブランチ名でプッシュしておく
どれでも好きなのをどうぞ
全部やれば完璧

（最後のなら簡単、運用ルール的にかぶらないブランチ名の付け方決めとくだけでOK、個人名_ブランチ名 とか
2025/01/23(木) 12:27:44.30ID:vFJWSuXb0
>>266-269
参考になりました、ありがとうございます
.gitフォルダだけを圧縮して逃がしたりしていましたが、
自分しか使わない前提のブランチなら、リモートにプッシュしてしまってもよいものなのですね
2025/01/23(木) 12:36:39.07ID:5LAJlDxM0
>>270
チームでやってるならチームのルールを確認
2025/01/23(木) 12:54:07.03ID:JYmON0LL0
>>270
git のブランチなんていくら push しても容量がそんなに増えるようなもんじゃないし、邪魔にもならないんで駄目って言われることはほぼないよ
フィルターしやすくしたり、名前かぶるの避けるためにブランチの命名規則だけは決めておくと良い
（方針によってはバックアップは別のリポジトリがあるからそっち使えって言われることはあるかもしれない
2025/01/23(木) 18:26:22.96ID:ZEFHCs1J0
>>265
ローカルにスタッシュする or 専用ブランにコミットした上で、.git以下を適当にバックアップするんじゃないの？

リモートに個人的なブランチをpushするのは抵抗感があるなぁ。
2025/01/23(木) 18:36:02.43ID:vFJWSuXb0
>>273
>>270で書いたような、今自分がやっている方法と同じですね
Gitの使い方としてどうかと思っていたのですが、それも間違いではないのですか
2025/01/23(木) 19:41:26.62ID:ZEFHCs1J0
>>274
大丈夫じゃない？
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
2025/01/24(金) 14:03:41.62ID:/oFMYy+rM
仕事でやってるならそれは個人的な作業ではないのだから堂々とリモートにpushすればよい
OSSならそもそもforkしてるだろうからリモートは元々自分専用
2025/01/25(土) 15:00:31.31ID:i3NO8nb7M
道具として異常

知恵遅れがしがみつく道具がgit
2025/01/25(土) 17:08:54.33ID:i1hyUUYx0
じゃあ天才は何使ってんの
2025/01/25(土) 17:22:25.79ID:W3I6NstP0
未だにsvnから移行できないじじいはいたな
2025/01/25(土) 17:57:50.21ID:aP269JYO0
better cvs として使ってます。本当にすみません。 ブランチとか良く使わないです
281デフォルトの名無しさん (JP 0Hb6-dNed)
垢版 |
2025/01/26(日) 13:26:52.01ID:uiy/DQQ3H
やっぱりVisual Source Safeが一番わかりやすくていいよね
2025/01/26(日) 16:30:13.37ID:h32xfORHM
Better CVSではないGitならではのやり方と言えるのなんて、
複数のリモートリポジトリ間でpullし合うような真に分散管理された伝統的なOSS開発スタイルくらいだろ
基本的に大半の人の使い方はBetter CVSの域を出ない
ローカルリポジトリがリモートリポジトリへの反映前のバッファとして使えて便利だな、という程度
2025/01/26(日) 16:51:43.41ID:v8RHgYNZ0
↑中途半端にわかった気になってるじじい
2025/01/26(日) 17:14:21.11ID:OHuPDl3g0
>>282
もうちょっと上手に煽んないと乗れないぞ

そもそもこのスレに cvs 使ったことあるやつがどれだけいると思ってんだ
30年前のアプリ比較に出しても自分が年寄りと表明することにしか
まちもに cvs 使ってたやつなら、恥ずかしくこの書き込みできないんで、きちんと使ったことないのまでは分かるけど
2025/01/26(日) 22:56:56.08ID:Im+l/vn00
CVSなら知ってるよ
コンビニのことでしょ
286デフォルトの名無しさん (ﾜｯﾁｮｲ 7a86-Uu4E)
垢版 |
2025/01/27(月) 23:35:25.04ID:5zVfH4ct0
>>284
40歳以上なら知っている
2025/01/28(火) 00:30:38.67ID:knz0Jl8ca
RCSの話をしたくなるね
288デフォルトの名無しさん (ﾜｯﾁｮｲ 7a86-Uu4E)
垢版 |
2025/01/28(火) 06:16:26.21ID:OdcIn15O0
VSSもかなりあとまで使っていたけどな
35歳以上なら知っていることが多い
2025/01/28(火) 12:37:10.14ID:bnD9cEyX0
いまでもVisualStudioのソースコード管理はVSSライクなのあるよね。
Gitも使えるけど。

開発の中心じゃないメンバーも使う仕様書管理とかだとそっちの方が
評判高いというか、Gitは使わないよなw
290デフォルトの名無しさん (ｱｳｱｳｴｰ Sa52-FFa5)
垢版 |
2025/01/28(火) 13:19:48.30ID:dqvH8r5Ca
SVNも忘れないで
2025/01/28(火) 20:38:47.97ID:n6IrqaQHa
Gitを知ろう！昔のソース管理とGit

の絵を見るとGitって難しい事してるな、って思う。
逆に古いツールは複雑なマージ出来るんだっけ？と不安になる。
2025/01/29(水) 13:05:47.15ID:iK+g/tdh0
Gitはオープンソースのプロジェクトを分散管理するのが目的だろうから、
社内のソース管理とかに使うと、なんか前より面倒くさくなったなと感じる
2025/01/29(水) 13:38:14.63ID:vsr4sfYf0
>>292
git は world wide にユニークな名前で管理して無限（おおげさな表現）にスケールすることが利点の1つなので
少人数のプロジェクトだとこの利点は感じ難いのは仕方ない、あらゆる利点は逆からみれば欠点なわけだし
2025/01/29(水) 13:41:47.19ID:vsr4sfYf0
git の他の利点、例えばブランチを切ったり繋いだりするのが早くて操作も簡単
みたいなのに慣れてくると個人利用のみでも手放せなくなる
2025/01/29(水) 15:51:35.40ID:O2q9bD9Z0
正直、ローカルリポジトリを持たずに直接GitHubにコミットできるオプションがあったら便利だと思う
クライアントとサーバーが等価なのがアーキテクチャとして美しいのはわかるけど、
安定したネットワーク環境とリモートへの反映が前提なら実用的にはあまり意味ないのよね
余計な手間が増えるだけだし、作業者マインドの人(情シスとか情シスとか)に理解させるのに苦労する
296デフォルトの名無しさん (ﾜｯﾁｮｲ 7a8e-0HiR)
垢版 |
2025/01/29(水) 16:45:51.30ID:NEN1+s6c0
なるほど、必要なら作ってくれ
2025/01/29(水) 17:08:05.77ID:j23j/EVS0
最近のGitHubはweb上で編集してプルリク投げまで完結できたよね？
あんまし使ったことないけど
2025/01/29(水) 17:26:33.12ID:wXwWo4Yf0
会社ではプッシュばっかり使っててプルリクの概念がいまだによくわかってない

このブランチをプルしてマージしてください ってお願いするのがプルリクなんだよね？
会社でこれをやるなら、ソース管理者みたいな人を立ててその人に依頼すんの？
2025/01/29(水) 18:19:19.91ID:u4GPoyB40
君のチームのワークフローに合わせればいい。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の機能を使って実装するだけだ。
2025/01/29(水) 19:20:58.17ID:vsr4sfYf0
>>298
ワークフロー次第だが、もともと想定されてるのは
個人用公開リポジトリ ←push― 個人用ローカルリポジトリ ←commit― 作業ディレクトリ
という環境を全員が持ってる前提で

プルリクエストというのは、「俺の公開リポジトリに push したので、そこからお前のリポジトリに pull してくれ」という要求

これを責任者宛に出せば
チームリーダーとかリリース・マネージャーとかの責任者がチェックして問題なければ、それを彼の個人ローカル・リポジトリでマージする（その後に彼の公開リポジトリに push して公開する）
2025/01/29(水) 21:57:23.24ID:u4GPoyB40
企業での開発においては共通のリポジトリを皆で触るのが一般的であり、”pull” requestは実際には同一リポジトリ内でのマージのみに使用する
forkはガバナンスを困難にし情報漏洩につながるリスクがあるため、そもそもorganizationまたはenterpriseのポリシーで一律禁止するのがベストプラクティス
2025/01/30(木) 01:09:50.68ID:o8nH7UIQ0
GitLabだとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ
2025/01/30(木) 01:12:38.22ID:sgBWR4v+0
プルだと向こうが主語だもんな
引っ張ってぇ、的な
2025/01/30(木) 08:03:04.92ID:yzi2OnyQ0
リクエストだから向こうが主語だよ
何いってんのさ

どちらも依頼だけど取り込む段階に着目するかマージする段階に着目するかの違いだよ
2025/01/30(木) 08:48:49.49ID:5L7oVd850
pull ってのは 「fetch して merge 」の省略形なので当然 merge もリクエストしてる
分散リポジトリなら先に merge の前に fetch してもらう必要があるので pull リクエストを出す
共用リポジトリとかなら fetch する必要がないので単なる merge リクエストを出す

この違いが分かって使い分けできないやつが git 使ってるの爆笑ものなんだが
ここは分かってないやつ多そうだな
2025/01/30(木) 10:31:13.18ID:Be3+/jiBM
企業内での開発の場合、pull(merge) requestは要請というよりレビューと承認を求める意味合いが強い。
結局マージを行うのも同じ人(別の人間かもしれないが基本的には同一の責任主体と見做せる)であることがほとんどだから。
その意味ではシンプルに review request
2025/01/30(木) 10:47:11.99ID:sLaRrBQRM
企業内での開発の場合、pull(merge) requestはコードレビューと承認を得ることを目的に作成され、その上でマージを誰が行うかは重要ではないんだよね。
というか多くのチームでは作成した本人がマージしている。
このへんの用語は実際初心者に教えてると理解しづらいようで、pullじゃなくてmergeにしたら解決というものでもない。
まあ、だからってもっと良い呼称は俺は思いつかないが。
2025/01/30(木) 10:52:20.88ID:sLaRrBQRM
すまん、>>306は誤って書き込んだ。
2025/01/30(木) 11:21:31.02ID:aXMNWhD7r
>>305
じゃあなんでGitLabはプルリクエストじゃなくてマージリクエストなの？
GitLabユーザーはfetchなんてしないのかしら？
2025/01/30(木) 15:36:37.44ID:yII0bm57d
しない。したとしても極めて稀。
OSS開発者のためのソーシャルコーディングサービスとして開発されたGitHubと異なり、
GitLabは当初からエンタープライズでのクローズドな開発を前提としており、>>301の通り基本的に共有リポジトリを使うから。
2025/01/30(木) 16:07:15.77ID:5L7oVd850
>>307
それはちょっと違う
本来は review とかが全部終わった完成したものについて出すのが merge/pull リクエスト
review する人と merge する人が一緒の時に手抜きで一回で済ますだけでワークフロー上は完全に別物
2025/01/30(木) 16:38:36.48ID:NcQM/92I0
>>311
使ったことがあるとは思えん
pull requestに対するレビュー結果の追加とマージの実行は別の操作だぞ
2025/01/30(木) 16:53:48.01ID:sgBWR4v+0
盛り上がってまいりました
2025/01/30(木) 17:25:50.04ID:5L7oVd850
>>309
>>311
github は分散リポジトリを念頭にサーバ上の統合作業の用語を選択した
gitlab は共用リポジトリを念頭にサーバ上の統合作業の用語を選択した

これは本来の git の意図とはズレてるのでリーナスが切れた（サーバ上では統合作業 merge/pull しない、それらは手元のローカル・リポジトリでやるのが git 本来の流儀）

git で pull request はもともと相手のローカル・リポジトリへの pull を要求するというそのままの意味（github は用語を変に流用しただけ、本来の使い方ではない

linux kernel だと subsystem maintainer とかが subsystem の開発リポジトリから完成した分をリーナスの個人リポジトリに取り込んでリリースに含めるよう最終的な要求するのが pull request の意味
コードのレビューとかはもっとずっと前に ML とかで多くの人が議論し尽くしてる、そういうのが全部終わって次のバージョンのリリースに含めて良くなったら pull request 出す
2025/01/30(木) 21:25:55.92ID:yzi2OnyQ0
fetchしないってかなり語弊があるよな
2025/01/31(金) 09:01:26.86ID:fWRcePGc0
>>314
で、あんたは>>298が会社でGitHubのpull requestを活用するにあたってLinuxカーネルと同様のMLベースのプロセスを導入すべきだと言いたいのか？
でないならその情報は質問者にとってたんなるのいずだ
2025/01/31(金) 09:31:32.44ID:uF0JLDg90
>>316
ここは GitHub スレではなくて git スレだ
git 本来の用法と用語があるんだ
GitHub の勝手用語を前提にしていない
2025/01/31(金) 10:15:03.05ID:9dfMKsJi0
>>316
> あんたはGitHubのpull requestを活用するにあって

俺に聞いてる？ 俺のアドバイスなら
git 本来の pull request は業務フローによって必要だったり不要だったりする、参考に知っておくと良い
Github の pull request は使う必要も学ぶ必要もないゴミ、そのまま忘れてしまって良い、周りで使おうとするやついたら全力で止めるレベル
319デフォルトの名無しさん (ｱｳｱｳｴｰ Sabf-J/8e)
垢版 |
2025/02/05(水) 14:37:49.09ID:RWIQAOlpa
fork して勝手に成長させて fork 側が立派に育ったら
pull request なんてしなくても勝手に pull してくれるのが理想
2025/02/06(木) 01:42:29.43ID:3KBUKtr20
>>319
いつ、誰が、何のために、どこから、どこへ pull すべきか指定するのが pull request なんだが
超絶AIでも開発してタイミングや理由を説明するのか？ 誰がはどうする？ 人間が AI から命令を受け取るのか？ 責任者不明のコミットができる GitHub状態なのか？

楽し過ぎるな。それやるくらいなら多分AIに全部のプログラム書かせた方が早いと思うぞ
2025/02/08(土) 21:27:04.90ID:yVxtkiH10
また説教おじさん
2025/02/12(水) 02:05:12.31ID:3tQGE9a70
git stashで、新規のファイルも一時退避したいのですが、デフォだと無視されるようですね
何か方法はないでしょうか
ま、新規ファイルはgitに未登録だから放置プレイせよ、ということなのかもしれませんが
なんとなくスッキリしないというか
2025/02/12(水) 02:14:56.55ID:W9y8zQE70
git add -A してから git stash
2025/02/12(水) 02:20:20.50ID:J/UI6pYQ0
-u
こんなとこ書き込む暇あったらググるかAIに聞け
2025/02/13(木) 23:46:41.27ID:hYbijExcr
スレ過疎ってるんだからええやん別に
2025/02/14(金) 12:09:29.98ID:wNm1lBEt0
2月寒いなあ、まだ冬型続くのかな？
みたいな質問するのは挨拶、話題作り、ネタ提供で雑談のきっかけにしたいだけなのに
「そんなのはググって気象庁のサイトを調べろ」とか言われちゃう感じだよねw
2025/02/14(金) 12:41:44.04ID:cflAAi0P0
>>326
みんなの集まる会議の席上で天気の質問とか始めたら、「さっさと始めろ、他人の時間を無駄にするな」って怒られるだろ
個人の雑談と、多数が集まる場所での発言は違うんじゃないかな？
他人の時間を無駄にしないために自分で調べられることは調べた上で、分からない部分があったら質問するのが人としての礼儀
2025/02/14(金) 12:57:41.89ID:b+7l3s230
はたから見た感想
質問者の「ま、～というか」っていう余計なくだりを書かなければ余計な苦言も返されなかったかもと思った
2025/02/15(土) 00:32:15.20ID:6v957rAir
>>327
このスレに多数の人が集まってるって言えるの？
2025/02/15(土) 01:49:01.01ID:ueLeU4Nj0
>>329
俺とお前の二人きりでないのは確実だ
331デフォルトの名無しさん (ﾜｯﾁｮｲ 867e-u07z)
垢版 |
2025/02/15(土) 05:04:09.56ID:0wMi8etC0
>>330
俺とお前と大五郎
332デフォルトの名無しさん (ｱｳｱｳｴｰ Sa13-9cJ9)
垢版 |
2025/02/16(日) 12:05:30.15ID:rAQQ2/+ca
点呼始めると急に人減るからな
333デフォルトの名無しさん (ﾜｯﾁｮｲ 7a6a-3k27)
垢版 |
2025/02/26(水) 19:03:01.07ID:dyHUusCc0
GitはConflictの修正で強制的にVim使わせんのやめてほしいんだが
WindowsユーザーがVimなんて日常的に使ってるわけねーんだが想像力ねーのかよ馬鹿が
みんなしち面倒だから極力競合しないように気を使ってて競合修正すること自体も少ないから
たまに競合すると修正するのだけでも怠いのにそれに輪を加えてVim使わされるから調べ物が二倍になんだよハゲが
さっさと競合の修正をVSCodeのエディタでできるようにしろボケ
2025/02/26(水) 21:59:35.09ID:tc9QKrsR0
>>333
お前のって変更できないの？
何をつかってるんだろう
2025/02/26(水) 22:20:46.32ID:uVlYXScm0
Vimの使い方を必死で調べる癖に、Gitの使い方は調べないのか
おかしいよな、やっぱり釣りかな
2025/02/26(水) 22:22:24.99ID:ZoHclDk+0
キレてんね～

https://docs.github.com/ja/get-started/getting-started-with-git/associating-text-editors-with-git
337デフォルトの名無しさん (ﾜｯﾁｮｲ 7a6a-3k27)
垢版 |
2025/02/26(水) 22:24:39.42ID:dyHUusCc0
>>334
開発環境はVisual Studio 2022かVScodeなんだがGitはTerminalのPowerShellのCLIでコマンド入力して使ってんだわ
だからTerminalからbarnchをmergeしたときに競合が起きると強制的にVimになってただでさえ競合でマズっ！て動揺しとんのlにブチギレそうになるんよ
TerminalからGitを使って競合したときにVSCodeでDiffする機能がググってもみつからねーんだよ
2025/02/27(木) 06:49:34.86ID:CZtmiDI/M
まあ、ぐーぐるが蔓延ってからフリーソフトはダメになったよな

マイクロソフトを使ってるやつらが雪崩れ込んできてからさらに異質になってきた
2025/02/27(木) 07:25:35.18ID:1tEOde+m0
どういう意味？
2025/02/27(木) 08:17:38.02ID:3+Px+dpt0
ドキュメント読まない、考えない奴が増えたということでは？
2025/02/27(木) 09:10:37.13ID:8vSp/RjD0
この流れでフリーソフトがダメになったとか言い出すの謎
初心者の不満に優しい回答者が解決してあげただけで、不満はお門違いなもので必要な機能は完全な形で提供されてた
2025/02/27(木) 09:36:53.23ID:XU/twqEe0
git は機能が多過ぎてマニュアル読んでもどこに書いてあるんだか見つけれないというのはあるんだと思う
けなしたりせずに最初から丁寧に質問すれば良いのに、質問者が悪い
343デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-c/TO)
垢版 |
2025/02/27(木) 12:49:05.52ID:VQNvJTxha
>>337
だっさ
2025/02/27(木) 13:38:03.41ID:XU/twqEe0
個人的には
unix/linux屋の感性だとエディタとか特定のやつ強制されたら、もう宣戦布告扱いなんで絶対に変更できるようになってる
EDITOR環境変数とかに追従しないならチュートリアルの先頭あたりで説明がある
とういの感覚なんだけど Windows みたいにお仕着せに甘んじるのに慣れさせられた子羊ちゃんたちには厳しい世界に見えるんだろうか？
2025/02/27(木) 15:26:47.55ID:epdZy57f0
>>342
難しくてわからない質問されて見下された気がしてイラッとしたからとりあえず煽っとくまで読んだ
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況