25/01/23 10:42:03.41 JYmON0LL0.net
>>266
・ディスクをレイドとかにして耐障害性を上げる
・ディスク／ファイルシステムのバックアップを取る
・バックアップ用の別のリモート・リポジトリにプッシュする
・共用リポジトリに別のブランチ名でプッシュしておく
どれでも好きなのをどうぞ
全部やれば完璧
（最後のなら簡単、運用ルール的にかぶらないブランチ名の付け方決めとくだけでOK、個人名_ブランチ名 とか
271:デフォルトの名無しさん
25/01/23 12:27:44.30 vFJWSuXb0.net
>>267-270
参考になりました、ありがとうございます
.gitフォルダだけを圧縮して逃がしたりしていましたが、
自分しか使わない前提のブランチなら、リモートにプッシュしてしまってもよいものなのですね
272:デフォルトの名無しさん
25/01/23 12:36:39.07 5LAJlDxM0.net
>>271
チームでやってるならチームのルールを確認
273:デフォルトの名無しさん
25/01/23 12:54:07.03 JYmON0LL0.net
>>271
git のブランチなんていくら push しても容量がそんなに増えるようなもんじゃないし、邪魔にもならないんで駄目って言われることはほぼないよ
フィルターしやすくしたり、名前かぶるの避けるためにブランチの命名規則だけは決めておくと良い
（方針によってはバックアップは別のリポジトリがあるからそっち使えって言われることはあるかもしれない
274:デフォルトの名無しさん
25/01/23 18:26:22.96 ZEFHCs1J0.net
>>266
ローカルにスタッシュする or 専用ブランにコミットした上で、.git以下を適当にバックアップするんじゃないの？
リモートに個人的なブランチをpushするのは抵抗感があるなぁ。
275:デフォルトの名無しさん
25/01/23 18:36:02.43 vFJWSuXb0.net
>>274
>>271で書いたような、今自分がやっている方法と同じですね
Gitの使い方としてどうかと思っていたのですが、それも間違いではないのですか
276:デフォルトの名無しさん
25/01/23 19:41:26.62 ZEFHCs1J0.net
>>275
大丈夫じゃない？
URLﾘﾝｸ(git-scm.com)
277:デフォルトの名無しさん
25/01/24 14:03:41.62 /oFMYy+rM.net
仕事でやってるならそれは個人的な作業ではないのだから堂々とリモートにpushすればよい
OSSならそもそもforkしてるだろうからリモートは元々自分専用
278:デフォルトの名無しさん
25/01/25 15:00:31.31 i3NO8nb7M.net
道具として異常
知恵遅れがしがみつく道具がgit
279:30
25/01/25 17:08:54.33 i1hyUUYx0.net
じゃあ天才は何使ってんの
280:デフォルトの名無しさん
25/01/25 17:22:25.79 W3I6NstP0.net
未だにsvnから移行できないじじいはいたな
281:デフォルトの名無しさん
25/01/25 17:57:50.21 aP269JYO0.net
better cvs として使ってます。本当にすみません。 ブランチとか良く使わないです
282:デフォルトの名無しさん
25/01/26 13:26:52.01 uiy/DQQ3H.net
やっぱりVisual Source Safeが一番わかりやすくていいよね
283:デフォルトの名無しさん
25/01/26 16:30:13.37 h32xfORHM.net
Better CVSではないGitならではのやり方と言えるのなんて、
複数のリモートリポジトリ間でpullし合うような真に分散管理された伝統的なOSS開発スタイルくらいだろ
基本的に大半の人の使い方はBetter CVSの域を出ない
ローカルリポジトリがリモートリポジトリへの反映前のバッファとして使えて便利だな、という程度
284:デフォルトの名無しさん
25/01/26 16:51:43.41 v8RHgYNZ0.net
↑中途半端にわかった気になってるじじい
285:デフォルトの名無しさん
25/01/26 17:14:21.11 OHuPDl3g0.net
>>283
もうちょっと上手に煽んないと乗れないぞ
そもそもこのスレに cvs 使ったことあるやつがどれだけいると思ってんだ
30年前のアプリ比較に出しても自分が年寄りと表明することにしか
まちもに cvs 使ってたやつなら、恥ずかしくこの書き込みできないんで、きちんと使ったことないのまでは分かるけど
286:30
25/01/26 22:56:56.08 Im+l/vn00.net
CVSなら知ってるよ
コンビニのことでしょ
287:デフォルトの名無しさん
25/01/27 23:35:25.04 5zVfH4ct0.net
>>285
40歳以上なら知っている
288:デフォルトの名無しさん
25/01/28 00:30:38.67 knz0Jl8ca.net
RCSの話をしたくなるね
289:デフォルトの名無しさん
25/01/28 06:16:26.21 OdcIn15O0.net
VSSもかなりあとまで使っていたけどな
35歳以上なら知っていることが多い
290:デフォルトの名無しさん
25/01/28 12:37:10.14 bnD9cEyX0.net
いまでもVisualStudioのソースコード管理はVSSライクなのあるよね。
Gitも使えるけど。
開発の中心じゃないメンバーも使う仕様書管理とかだとそっちの方が
評判高いというか、Gitは使わないよなw
291:デフォルトの名無しさん
25/01/28 13:19:48.30 dqvH8r5Ca.net
SVNも忘れないで
292:デフォルトの名無しさん
25/01/28 20:38:47.97 n6IrqaQHa.net
Gitを知ろう！昔のソース管理とGit
の絵を見るとGitって難しい事してるな、って思う。
逆に古いツールは複雑なマージ出来るんだっけ？と不安になる。
293:デフォルトの名無しさん
25/01/29 13:05:47.15 iK+g/tdh0.net
Gitはオープンソースのプロジェクトを分散管理するのが目的だろうから、
社内のソース管理とかに使うと、なんか前より面倒くさくなったなと感じる
294:デフォルトの名無しさん
25/01/29 13:38:14.63 vsr4sfYf0.net
>>293
git は world wide にユニークな名前で管理して無限（おおげさな表現）にスケールすることが利点の1つなので
少人数のプロジェクトだとこの利点は感じ難いのは仕方ない、あらゆる利点は逆からみれば欠点なわけだし
295:デフォルトの名無しさん
25/01/29 13:41:47.19 vsr4sfYf0.net
git の他の利点、例えばブランチを切ったり繋いだりするのが早くて操作も簡単
みたいなのに慣れてくると個人利用のみでも手放せなくなる
296:デフォルトの名無しさん
25/01/29 15:51:35.40 O2q9bD9Z0.net
正直、ローカルリポジトリを持たずに直接GitHubにコミットできるオプションがあったら便利だと思う
クライアントとサーバーが等価なのがアーキテクチャとして美しいのはわかるけど、
安定したネットワーク環境とリモートへの反映が前提なら実用的にはあまり意味ないのよね
余計な手間が増えるだけだし、作業者マインドの人(情シスとか情シスとか)に理解させるのに苦労する
297:デフォルトの名無しさん
25/01/29 16:45:51.30 NEN1+s6c0.net
なるほど、必要なら作ってくれ
298:デフォルトの名無しさん
25/01/29 17:08:05.77 j23j/EVS0.net
最近のGitHubはweb上で編集してプルリク投げまで完結できたよね？
あんまし使ったことないけど
299:デフォルトの名無しさん
25/01/29 17:26:33.12 wXwWo4Yf0.net
会社ではプッシュばっかり使っててプルリクの概念がいまだによくわかってない
このブランチをプルしてマージしてください ってお願いするのがプルリクなんだよね？
会社でこれをやるなら、ソース管理者みたいな人を立ててその人に依頼すんの？
300:デフォルトの名無しさん
25/01/29 18:19:19.91 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:デフォルトの名無しさん
25/01/29 19:20:58.17 vsr4sfYf0.net
>>299
ワークフロー次第だが、もともと想定されてるのは
個人用公開リポジトリ ←push― 個人用ローカルリポジトリ ←commit― 作業ディレクトリ
という環境を全員が持ってる前提で
プルリクエストというのは、「俺の公開リポジトリに push したので、そこからお前のリポジトリに pull してくれ」という要求
これを責任者宛に出せば
チームリーダーとかリリース・マネージャーとかの責任者がチェックして問題なければ、それを彼の個人ローカル・リポジトリでマージする（その後に彼の公開リポジトリに push して公開する）
302:デフォルトの名無しさん
25/01/29 21:57:23.24 u4GPoyB40.net
企業での開発においては共通のリポジトリを皆で触るのが一般的であり、”pull” requestは実際には同一リポジトリ内でのマージのみに使用する
forkはガバナンスを困難にし情報漏洩につながるリスクがあるため、そもそもorganizationまたはenterpriseのポリシーで一律禁止するのがベストプラクティス
303:デフォルトの名無しさん
25/01/30 01:09:50.68 o8nH7UIQ0.net
GitLabだとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ
304:デフォルトの名無しさん
25/01/30 01:12:38.22 sgBWR4v+0.net
プルだと向こうが主語だもんな
引っ張ってぇ、的な
305:デフォルトの名無しさん
25/01/30 08:03:04.92 yzi2OnyQ0.net
リクエストだから向こうが主語だよ
何いってんのさ
どちらも依頼だけど取り込む段階に着目するかマージする段階に着目するかの違いだよ
306:デフォルトの名無しさん
25/01/30 08:48:49.49 5L7oVd850.net
pull ってのは 「fetch して merge 」の省略形なので当然 merge もリクエストしてる
分散リポジトリなら先に merge の前に fetch してもらう必要があるので pull リクエストを出す
共用リポジトリとかなら fetch する必要がないので単なる merge リクエストを出す
この違いが分かって使い分けできないやつが git 使ってるの爆笑ものなんだが
ここは分かってないやつ多そうだな
307:デフォルトの名無しさん
25/01/30 10:31:13.18 Be3+/jiBM.net
企業内での開発の場合、pull(merge) requestは要請というよりレビューと承認を求める意味合いが強い。
結局マージを行うのも同じ人(別の人間かもしれないが基本的には同一の責任主体と見做せる)であることがほとんどだから。
その意味ではシンプルに review request
308:デフォルトの名無しさん
25/01/30 10:47:11.99 sLaRrBQRM.net
企業内での開発の場合、pull(merge) requestはコードレビューと承認を得ることを目的に作成され、その上でマージを誰が行うかは重要ではないんだよね。
というか多くのチームでは作成した本人がマージしている。
このへんの用語は実際初心者に教えてると理解しづらいようで、pullじゃなくてmergeにしたら解決というものでもない。
まあ、だからってもっと良い呼称は俺は思いつかないが。
309:307
25/01/30 10:52:20.88 sLaRrBQRM.net
すまん、>>307は誤って書き込んだ。
310:デフォルトの名無しさん
25/01/30 11:21:31.02 aXMNWhD7r.net
>>306
じゃあなんでGitLabはプルリクエストじゃなくてマージリクエストなの？
GitLabユーザーはfetchなんてしないのかしら？
311:デフォルトの名無しさん
25/01/30 15:36:37.44 yII0bm57d.net
しない。したとしても極めて稀。
OSS開発者のためのソーシャルコーディングサービスとして開発されたGitHubと異なり、
GitLabは当初からエンタープライズでのクローズドな開発を前提としており、>>302の通り基本的に共有リポジトリを使うから。
312:デフォルトの名無しさん
25/01/30 16:07:15.77 5L7oVd850.net
>>308
それはちょっと違う
本来は review とかが全部終わった完成したものについて出すのが merge/pull リクエスト
review する人と merge する人が一緒の時に手抜きで一回で済ますだけでワークフロー上は完全に別物
313:デフォルトの名無しさん
25/01/30 16:38:36.48 NcQM/92I0.net
>>312
使ったことがあるとは思えん
pull requestに対するレビュー結果の追加とマージの実行は別の操作だぞ
314:デフォルトの名無しさん
25/01/30 16:53:48.01 sgBWR4v+0.net
盛り上がってまいりました
315:デフォルトの名無しさん
25/01/30 17:25:50.04 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:デフォルトの名無しさん
25/01/30 21:25:55.92 yzi2OnyQ0.net
fetchしないってかなり語弊があるよな
317:デフォルトの名無しさん
25/01/31 09:01:26.86 fWRcePGc0.net
>>315
で、あんたは>>299が会社でGitHubのpull requestを活用するにあたってLinuxカーネルと同様のMLベースのプロセスを導入すべきだと言いたいのか？
でないならその情報は質問者にとってたんなるのいずだ
318:デフォルトの名無しさん
25/01/31 09:31:32.44 uF0JLDg90.net
>>317
ここは GitHub スレではなくて git スレだ
git 本来の用法と用語があるんだ
GitHub の勝手用語を前提にしていない
319:デフォルトの名無しさん
25/01/31 10:15:03.05 9dfMKsJi0.net
>>317
> あんたはGitHubのpull requestを活用するにあって
俺に聞いてる？ 俺のアドバイスなら
git 本来の pull request は業務フローによって必要だったり不要だったりする、参考に知っておくと良い
Github の pull request は使う必要も学ぶ必要もないゴミ、そのまま忘れてしまって良い、周りで使おうとするやついたら全力で止めるレベル
320:デフォルトの名無しさん
25/02/05 14:37:49.09 RWIQAOlpa.net
fork して勝手に成長させて fork 側が立派に育ったら
pull request なんてしなくても勝手に pull してくれるのが理想
321:デフォルトの名無しさん
25/02/06 01:42:29.43 3KBUKtr20.net
>>320
いつ、誰が、何のために、どこから、どこへ pull すべきか指定するのが pull request なんだが
超絶AIでも開発してタイミングや理由を説明するのか？ 誰がはどうする？ 人間が AI から命令を受け取るのか？ 責任者不明のコミットができる GitHub状態なのか？
楽し過ぎるな。それやるくらいなら多分AIに全部のプログラム書かせた方が早いと思うぞ
322:デフォルトの名無しさん
25/02/08 21:27:04.90 yVxtkiH10.net
また説教おじさん
323:デフォルトの名無しさん
25/02/12 02:05:12.31 3tQGE9a70.net
git stashで、新規のファイルも一時退避したいのですが、デフォだと無視されるようですね
何か方法はないでしょうか
ま、新規ファイルはgitに未登録だから放置プレイせよ、ということなのかもしれませんが
なんとなくスッキリしないというか
324:デフォルトの名無しさん
25/02/12 02:14:56.55 W9y8zQE70.net
git add -A してから git stash
325:デフォルトの名無しさん
25/02/12 02:20:20.50 J/UI6pYQ0.net
-u
こんなとこ書き込む暇あったらググるかAIに聞け
326:デフォルトの名無しさん
25/02/13 23:46:41.27 hYbijExcr.net
スレ過疎ってるんだからええやん別に
327:デフォルトの名無しさん
25/02/14 12:09:29.98 wNm1lBEt0.net
2月寒いなあ、まだ冬型続くのかな？
みたいな質問するのは挨拶、話題作り、ネタ提供で雑談のきっかけにしたいだけなのに
「そんなのはググって気象庁のサイトを調べろ」とか言われちゃう感じだよねw
328:デフォルトの名無しさん
25/02/14 12:41:44.04 cflAAi0P0.net
>>327
みんなの集まる会議の席上で天気の質問とか始めたら、「さっさと始めろ、他人の時間を無駄にするな」って怒られるだろ
個人の雑談と、多数が集まる場所での発言は違うんじゃないかな？
他人の時間を無駄にしないために自分で調べられることは調べた上で、分からない部分があったら質問するのが人としての礼儀
329:デフォルトの名無しさん
25/02/14 12:57:41.89 b+7l3s230.net
はたから見た感想
質問者の「ま、～というか」っていう余計なくだりを書かなければ余計な苦言も返されなかったかもと思った
330:デフォルトの名無しさん
25/02/15 00:32:15.20 6v957rAir.net
>>328
このスレに多数の人が集まってるって言えるの？
331:デフォルトの名無しさん
25/02/15 01:49:01.01 ueLeU4Nj0.net
>>330
俺とお前の二人きりでないのは確実だ
332:デフォルトの名無しさん
25/02/15 05:04:09.56 0wMi8etC0.net
>>331
俺とお前と大五郎
333:デフォルトの名無しさん
25/02/16 12:05:30.15 rAQQ2/+ca.net
点呼始めると急に人減るからな
334:デフォルトの名無しさん
25/02/26 19:03:01.07 dyHUusCc0.net
GitはConflictの修正で強制的にVim使わせんのやめてほしいんだが
WindowsユーザーがVimなんて日常的に使ってるわけねーんだが想像力ねーのかよ馬鹿が
みんなしち面倒だから極力競合しないように気を使ってて競合修正すること自体も少ないから
たまに競合すると修正するのだけでも怠いのにそれに輪を加えてVim使わされるから調べ物が二倍になんだよハゲが
さっさと競合の修正をVSCodeのエディタでできるようにしろボケ
335:デフォルトの名無しさん
25/02/26 21:59:35.09 tc9QKrsR0.net
>>334
お前のって変更できないの？
何をつかってるんだろう
336:デフォルトの名無しさん
25/02/26 22:20:46.32 uVlYXScm0.net
Vimの使い方を必死で調べる癖に、Gitの使い方は調べないのか
おかしいよな、やっぱり釣りかな
337:デフォルトの名無しさん
25/02/26 22:22:24.99 ZoHclDk+0.net
キレてんね～
URLﾘﾝｸ(docs.github.com)
338:デフォルトの名無しさん
25/02/26 22:24:39.42 dyHUusCc0.net
>>335
開発環境はVisual Studio 2022かVScodeなんだがGitはTerminalのPowerShellのCLIでコマンド入力して使ってんだわ
だからTerminalからbarnchをmergeしたときに競合が起きると強制的にVimになってただでさえ競合でマズっ！て動揺しとんのlにブチギレそうになるんよ
TerminalからGitを使って競合したときにVSCodeでDiffする機能がググってもみつからねーんだよ
339:デフォルトの名無しさん
25/02/27 06:49:34.86 CZtmiDI/M.net
まあ、ぐーぐるが蔓延ってからフリーソフトはダメになったよな
マイクロソフトを使ってるやつらが雪崩れ込んできてからさらに異質になってきた
340:デフォルトの名無しさん
25/02/27 07:25:35.18 1tEOde+m0.net
どういう意味？
341:デフォルトの名無しさん
25/02/27 08:17:38.02 3+Px+dpt0.net
ドキュメント読まない、考えない奴が増えたということでは？
342:デフォルトの名無しさん
25/02/27 09:10:37.13 8vSp/RjD0.net
この流れでフリーソフトがダメになったとか言い出すの謎
初心者の不満に優しい回答者が解決してあげただけで、不満はお門違いなもので必要な機能は完全な形で提供されてた
343:デフォルトの名無しさん
25/02/27 09:36:53.23 XU/twqEe0.net
git は機能が多過ぎてマニュアル読んでもどこに書いてあるんだか見つけれないというのはあるんだと思う
けなしたりせずに最初から丁寧に質問すれば良いのに、質問者が悪い
344:デフォルトの名無しさん
25/02/27 12:49:05.52 VQNvJTxha.net
>>338
だっさ
345:デフォルトの名無しさん
25/02/27 13:38:03.41 XU/twqEe0.net
個人的には
unix/linux屋の感性だとエディタとか特定のやつ強制されたら、もう宣戦布告扱いなんで絶対に変更できるようになってる
EDITOR環境変数とかに追従しないならチュートリアルの先頭あたりで説明がある
とういの感覚なんだけど Windows みたいにお仕着せに甘んじるのに慣れさせられた子羊ちゃんたちには厳しい世界に見えるんだろうか？
346:デフォルトの名無しさん
25/02/27 15:26:47.55 epdZy57f0.net
>>343
難しくてわからない質問されて見下された気がしてイラッとしたからとりあえず煽っとくまで読んだ
347:デフォルトの名無しさん
25/02/27 18:59:01.12 8vSp/RjD0.net
おかしな人を一人見ただけで最近の子は～とか言い出しちゃうのって老化現象なのでは
348:デフォルトの名無しさん
25/02/28 01:35:09.82 1HSOHgVq0.net
>>338
ターミナルも仕様がよくわからないのによく使うな
比較的、新しいものを使うなら古い方を知ったうえで使わないと
349:デフォルトの名無しさん
25/02/28 02:45:09.17 anIDZvfV0.net
ここ老人ばかりだし老化現象ではと言われてもあんまり効かないよね
350:デフォルトの名無しさん
25/02/28 08:41:15.61 rekq6zs60.net
>>337 に礼くらいしろ。
感謝すらできないタダメシ寄生虫かよ。
351:デフォルトの名無しさん
25/02/28 09:19:01.12 f1y1aNyV0.net
礼を求めるのはムリだろー
素直に教えを請うのではなく怒り散らすことで回りが俺様を助けてくれることを期待する駄々っ子タイプなのは最初の発言からわかってる
352:デフォルトの名無しさん
25/02/28 09:30:18.88 f1y1aNyV0.net
今回の場合、Gitのダメなところをぶちまけて憂さ晴らししようとす来たら反論で恥かかされてさらに怒ってるまである
353:デフォルトの名無しさん
25/03/01 11:36:53.90 dZ2eBKvGa.net
久々に落ちて来た餌に群がる深海魚のようでつね
354:デフォルトの名無しさん
25/03/01 12:39:20.26 uxtJasyd0.net
よく言われる
顔が深海魚みたいだって
355:デフォルトの名無しさん
25/03/05 20:27:54.18 k4iH0qBY0.net
masterからbranch切ってコミットして、VSCodeにSyncronizeってボタンでたからそれ押したらmasterブランチで？に？pushされた
これってコマンドだとどういうコマンド使ったことになるの？
何か嫌だったからmasterブランチの方はpullしてrevertして、masterと新しく切ったbranchをpushしなおした
356:デフォルトの名無しさん
25/03/05 20:32:53.30 DnMeoT1g0.net
GitはCLIの方が圧倒的に使いやすいわ
GUIやとでけへんことが多すぎるし逆に面倒やからな
ニワカどもがSourcetreeとかGithub Desktopとかを初心者にすすめんのやめーや
最初が肝心なんやからどうせ教えるならしっかり手取り足取りCLIで教えたれ
357:デフォルトの名無しさん
25/03/06 02:17:50.54 X0p8pnT00.net
コミット履歴見ながらあれこれやるときはcliはやってられんでしょ
358:デフォルトの名無しさん
25/03/06 08:13:14.54 SoBTsc5U0.net
サーバ側のログ見たけどエラーログしか吐いてなくて、アクセスログ的なログは無かった
359:デフォルトの名無しさん
25/03/06 08:37:02.92 TZy25+2E0.net
>>357
why?
CLI しか使ったことないけど
360:デフォルトの名無しさん
25/03/06 13:33:57.70 SW3gTDW+M.net
>>356
コマンドはネット上に嘘が大量に書かれているからなあ
361:デフォルトの名無しさん
25/03/06 14:56:33.55 hrpDJRUa0.net
>>360
マジで？
困った時しか調べないので気付いてない。
362:デフォルトの名無しさん
25/03/06 15:07:24.98 X0p8pnT00.net
>>359
マウスなら数手で済むところをハッシュ見て打ち込んでスクロールアウトしたから見直してとか非効率
何事も向き不向きがある
363:デフォルトの名無しさん
25/03/06 16:54:30.08 TZy25+2E0.net
>>362
意味わからん
普通キーボードから手を離してマウスに手を持っていく暇があれば、その時間にコマンド打ち終わって実行結果の確認まで終わって次の作業始めれるけど？
CLI使うかエディタのショートカット使うかの2択だろ、マウスの出る幕はない
364:デフォルトの名無しさん
25/03/06 17:47:20.86 X0p8pnT00.net
>>363
それいうならおれはトラックポイント使ってるから持ち替えるなんて無駄はとっくの昔に排除してるっての
おれはCLIでも使える
環境変えた時に困るからな
で比較した上で言ってる
365:デフォルトの名無しさん
25/03/06 18:43:44.49 TZy25+2E0.net
>>364
何が言いたいか分からん、俺は無能なのでGUIで十分って言ってるの？
「CLIだとやってられない」の根拠をまるで示せてないけど？
command のオプションとか使いこなせてないだろうことは何となく察せられる。例えば履歴見る時に git log に -G とか --grep とか使ったことある？ この違いって即答できる？
366:デフォルトの名無しさん
25/03/06 19:00:28.81 /b+y/+WW0.net
いやGitは明らかにGUIよりCLIの方が使いやすいんやがwww
いやちゃうなCLIが使いやすいんやなくてGUIがどれもクソすぎるんや
唯一マシなGitKrakenはクソ高いサブスクやしな
367:デフォルトの名無しさん
25/03/06 19:10:55.39 EYycW5pS0.net
CLI派はステージする行を取捨選択したいときどうするの？
煽りたいわけじゃなくて興味がある
なお俺は普段VSCodeとlazygitを使っていて込み入った操作のときだけCLI使っている
368:デフォルトの名無しさん
25/03/06 20:03:56.86 TZy25+2E0.net
>>367
git add -e でエディタで選択
git add -i でCLIメニューで選択
個人的には前者を多用してる
369:デフォルトの名無しさん
25/03/06 23:00:54.80 FATO06L/0.net
マウスに一切持ち替えないCLI過激派の人ってハッシュは目視確認して手で打ってるの？
HEAD~~とかHEAD~4とかでだいたい済むから手打ちするにしても稀な感じなのかな
370:デフォルトの名無しさん
25/03/06 23:23:19.37 54POgzsF0.net
過激派じゃないからやったことないけど、マウス使わずにCLI単体で目的のハッシュ検索→コピー→ペースト出来んじゃないの？
371:デフォルトの名無しさん
25/03/07 00:54:33.86 t6N/68bn0.net
CLI で hash値を入れることなんてまずないだろ
直近のは HEAD やブランチ名からたどるし、古いのはタグ打ってたり、検索条件で特定する
どうしても hash値で特定したい時は先頭の4文字とか打つだけでいけるので全部入れる必要はないよ、そんな機会はめったにないが
あとやろうと思えばCLIでもエディタ操作でマウス以上に高速にコピペできるけど
372:デフォルトの名無しさん
25/03/07 02:01:32.04 hA31zhIA0.net
GUIでポトペタばっかしとる奴らの前提が空で覚えるの前提なん草
そもそもTerminalもGitbashもインテリセンス効くことを知らんの無知すぎてクソワロタ
373:デフォルトの名無しさん
25/03/07 02:20:38.51 DC3oMiFw0.net
自分がやっていることを説明しない、説明できないタイプは、コマンドに逃げる傾向があるんだよな。
374:デフォルトの名無しさん
25/03/07 05:10:53.94 rO0CBAe5d.net
>>373
というより、そうする必要があるかどうか次第だな
>>368からも分かる通り、メクラコミット中心ならCLIで十分、コミット内容の細かな編集が多いならCLIの範疇だけでは難しい
375:デフォルトの名無しさん
25/03/07 08:46:11.25 t6N/68bn0.net
>>374
難しくないだろ git add -e で完璧制御できる
パッチをそのまま目視できて編集できるんだから、もっとも確実
どんな細かい変更でも自由、なんらら一行に複数の変更がある場合に一部だけとか、実際にソースにない変更も可能
376:デフォルトの名無しさん
25/03/07 09:59:34.81 qPWIu0Mm0.net
エディタ使ったらそれもうCLIじゃないでしょ
TUIではあるけど、それを広義のCLIと認めるならlazygitやtigのような実質GUIと変わらんようなTUIクライアントもCLIになってしまうがそれでよいか
377:デフォルトの名無しさん
25/03/07 10:28:55.57 DC3oMiFw0.net
Gitを使っておきながら、他人にはわからないコマンドだけの手順を書くやつは必ずいるしな
378:デフォルトの名無しさん
25/03/07 10:52:06.81 i3TW8fQU0.net
>>376
こんなの暴論だろ
どうやってコード書くんだよ
379:デフォルトの名無しさん
25/03/07 11:15:57.74 TL3VpnxxM.net
コーディングとは違ってステージ時のパッチ編集はGitのために行う操作なんだから、GUIクライアントとの比較の文脈ではGitの操作の一部と見做すべきでしょ
git guiはCLIか？git add -eでVSCodeを開くのはCLIか？
エディタを呼び出した時点でもはや純粋にCLIと呼べない以上、程度問題でしかないってことだよ
380:デフォルトの名無しさん
25/03/07 11:23:23.99 t6N/68bn0.net
>>379
CLI といにはもともとがスクリプト書いたり、エディターから呼び出すパーツを想定してあって、毎回直接打たないといけないって意味じゃないぞ、あくまでも git にアクセスするインターフェイスの種類
自分用にカスタマイズして使うのは当然
381:デフォルトの名無しさん
25/03/07 11:35:48.56 TL3VpnxxM.net
そう。そしてGUIクライアントも同様にCLIを呼び出すインターフェースに過ぎない。
だから変な差別意識持たずに仲良くしような。
382:デフォルトの名無しさん
25/03/07 11:44:27.31 t6N/68bn0.net
>>381
インターフェイスというのは「呼び出し側が理解して制御してる部分」と「制御していないブラックボクスとして扱う部分」の境界のことだ
UI ならユーザとアプリの境界、その動作が内部でどのコマンドに展開されるか想定してばスクリプトやエディタから呼んでもCLI
一方でボタン押すだけで中でどのコマンドに変わるのか全然理解できてなければCLIではない
383:デフォルトの名無しさん
25/03/07 11:49:35.66 t6N/68bn0.net
ユーザーが制御できてるか簡易に見分ける方法は「自由に変更できるか」だ
呼び出すコマンドを理解する必要があって自由に変更できるならボタンからだろうショートカットからだろうとCLIでいい
自由に扱えないならそれはインターフェイスの向こう側だ
384:デフォルトの名無しさん
25/03/07 12:50:44.02 i3TW8fQU0.net
正直そんな事どうでもいいから>>355教えてほしいです
385:デフォルトの名無しさん
25/03/07 13:45:02.36 hv4T53nE0.net
>>371
それ都合のいいようにCLIの不利なケースを排除してるだけだろ
お前みたいなやつは死ぬほど見てきた
CLIで曲芸してるだけ
適材適所で使うってだけの話を受け入れられない
386:デフォルトの名無しさん
25/03/07 13:58:21.86 t6N/68bn0.net
>>385
そもそもCLIで使う前提でコミットログ書くし、ブランチ切るし、タグ打つし、git のUIは最初からそういう設計になってつんだよ
全部のハッシュ打たなくて確定できるまでの文字打てばすむのもそう
git は CLI を使うプログラマによって設計開発発展してきた履歴があるので CLI で困ることはない
「CLIではやってられない」とか言い出すのはそいつが未熟で git に慣れてないだけの妄想
まあ全員が git に慣れてる必要はないので口を閉じて「馬鹿でも使えるものは馬鹿しか使わない」という世界に閉じこもってろ
387:デフォルトの名無しさん
25/03/07 14:16:08.04 hv4T53nE0.net
>>386
マウスの持ち替え気にするくせにハッシュを目視で確認して打ち込む非効率さは目をつぶる
インタフェースやビジュアライズの大切さを無視するエンジニアとは仕事したくないね
ちなデバッガももしかしてCLIかい？w
388:デフォルトの名無しさん
25/03/07 14:28:05.14 0jIQFjkxH.net
>>386
君の意見を否定するつもりはないが、事実としてGitの公式ディストリビューションにはGUIが付属しているし、git gui コマンドも存在するし、公式サイトで非常に目立つ形で非公式のGUIクライアントを紹介している
こんなところでヘイト撒いてる暇があったら削除するようリクエストしてきた方がいいぞ
389:デフォルトの名無しさん
25/03/07 14:58:36.90 xU3go4h6a.net
CUIって自分の操作の履歴辿れるけど
GUIは何やったか覚えてないとか
意図しない変化があったときに今何した？ってなるのが嫌
390:デフォルトの名無しさん
25/03/07 15:02:30.73 xU3go4h6a.net
>>355 の感じてる「なんか嫌」も >>389 と同じ理由だと思う
391:デフォルトの名無しさん
25/03/07 15:36:27.72 t6N/68bn0.net
>>388
別にGUI使っちゃ駄目とは一言もいってないぞ、GUI使いたいやつだけ勝手に使ってれば良い、それで苦労しようが失敗しようが知ったこっちゃない
「CLIではやってられない」という虚言を否定してるだけ、俺はCLIで十分
392:デフォルトの名無しさん
25/03/07 15:40:54.21 t6N/68bn0.net
>>387
キーボードで16進数4文字打つのが非効率なの？ マウス操作の方が早いの？
俺とは違う技術で生きてるみたいだな
デバッガやプロファイラは自作スクリプト経由のことが多いな、スクリプトなしで簡易にやるならエディタのマクロ
393:デフォルトの名無しさん
25/03/07 17:31:19.43 hv4T53nE0.net
>>392
タイピングの問題でなく目視でハッシュを確認ってのが非人間的で非効率って言ってんの
そういう受け取り方をするってことはやっぱりUI/UXの視点が欠如してるんだよお前は
でデバッガをスクリプトで使うとは恐れ入った
全く別世界に生きてるのは同意
394:デフォルトの名無しさん
25/03/07 18:54:27.19 t6N/68bn0.net
>>393
良く分からんが目が悪いの？
普通はタグとか検索結果からの相対指定で使うんだよ
何らかで間違ってタグを消したとかごく稀にどうしてもハッシュ値で指定したい時に、年に1回くらい目視確認で4桁の数字打つだけだよ
簡単なんだけどなあ
395:デフォルトの名無しさん
25/03/07 19:04:16.99 bYeAoHPJ0.net
チーム開発だと、かなり前の特定のコミットをrevertしたりcherry-pickしたりは全然珍しくないけどなあ
396:デフォルトの名無しさん
25/03/07 20:04:21.73 xU3go4h6a.net
GUIならHash目視しないのかな
397:デフォルトの名無しさん
25/03/07 20:40:14.65 ZrsdmfZ80.net
仕事でチーム作業してたらハッシュは4桁では足りないからやっぱ手打ちはヤダな
バグトラッカーやクラウドのツールと交互に使うからマウスに持ち替えずにキーボードだけであらゆるGit操作を駆使！スゴイ腕前！とはならないかなあ
やっぱり達人は5chもcurlで書き込んでんのかな
398:デフォルトの名無しさん
25/03/07 20:58:11.36 t6N/68bn0.net
>>395
そもそもそういうのはref検索とかで指定しない？
ログを目視しながらハッシュ値を探したりしないと思うんだが
ハッシュ値で指定することなんてめっにないんだから気にする時点で何か効率の悪いことしてる気がする
399:デフォルトの名無しさん
25/03/07 21:01:27.92 qVctmwDB0.net
GUIやCUIの原理主義者じゃない限り
どっちでも使いやすいところで使い分ければ済む話だろ
ただ、GUIに関しては、CUIのコマンドオプションの何を行うコマンドかが分かる程度に表記してほしい
英語表記でも微妙、日本語ならばなおさら困惑する
できればCUIのコマンドオプションを併記してほしい
400:デフォルトの名無しさん
25/03/08 00:55:57.26 f1gAdLsE0.net
ハッシュ値指定しない人は多分GitHub使ったことないんだと思う
401:デフォルトの名無しさん
25/03/08 11:24:47.06 lsvDMVeL0.net
Git v2.49.0-rc1
402:デフォルトの名無しさん
25/03/08 11:29:06.73 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:デフォルトの名無しさん
25/03/08 12:22:24.00 kCgnTDtk0.net
githubで全然草生やせないんだけど
404:デフォルトの名無しさん
25/03/09 18:13:33.28 fe3LNf260.net
>>357
gitk 見ながら CLI 操作ってのが個人的には最強
405:デフォルトの名無しさん
25/03/11 10:16:27.19 gbyV8IdY0.net
Git v2.49.0-rc2
406:デフォルトの名無しさん
25/03/15 12:09:57.15 PGLL/72K0.net
Git v2.49.0
407:デフォルトの名無しさん
25/04/08 16:01:12.91 3wE3gtcN0.net
「Git」誕生から20周年を記念してリーナス・トーバルズ氏が開発初期の裏事情や使用頻度の高いコマンドなどを明かす
URLﾘﾝｸ(gigazine.net)
408:デフォルトの名無しさん
25/04/09 16:03:54.93 IrWwI/nb0.net
複数ファイル名を入力するときはGUIでポチポチ選択したい
409:デフォルトの名無しさん
25/04/18 20:54:17.74 pzk2UeIY0.net
10日で開発したL・トーバルズ氏も想定外？--「Git」誕生から20年、定番VCSの軌跡とその影響
ps://japan.zdnet.com/article/35231917/
410:デフォルトの名無しさん
25/04/27 17:55:28.09 sTr1luuSM.net
このスレッドはLinux開発のGitの世界を語りだす気持ち悪い人間がいるから困る
411:デフォルトの名無しさん
25/05/15 13:14:12.18 UmAf9vRJ0.net
最新版で行ったバグ修正の部分だけを旧バージョンにも適用したい場合、チェリーピックを行うことになりますか？
その場合、ログの樹形図には、このコミットを持ってきたよという線は作られずに、別々の作業という表現になってしまいますか？
412:デフォルトの名無しさん
25/05/15 13:54:33.66 F0izL13m0.net
>>411
それであってるよ
直接 cherry-pick せずにバグ修正だけ入ったブランチを作ってそっちをマージという形にするやり方も一応あるけど大した違いはない
系統樹にはならないのでコミットログにどこから cherry-pick したかを残しておく（変なオプション使わなければ勝手に残るよ）
413:デフォルトの名無しさん
25/05/15 17:08:27.77 UmAf9vRJ0.net
>>412
ありがとうございます
旧バージョンのこういうメンテナンスは、チェリーピックを使っていくことになるのですね
414:デフォルトの名無しさん
25/05/15 17:42:53.69 F0izL13m0.net
>>413
親子関係にない（できない）間でのパッチの流用は cherry-pick でやるのが基本
git のコードの移動は（特殊なの除くと）merge, rebase, cherry-pick の3つだけ
逆に言うと cherry-pick は最重要3役のひとつ
415:デフォルトの名無しさん
25/05/15 18:00:11.34 eepuMYHW0.net
rebaseってcherry-pickの繰り返しと同じじゃねーの？
416:デフォルトの名無しさん
25/05/15 20:13:23.49 F0izL13m0.net
>>415
似てるけど違うよ、オプションにもよるけど
●rebase は今いるブランチを移動させる
○cherry-pick はよそのブランチからコピーしてくる
コピーとムーブの違い、方向も逆なので注意
あと cherry-pick も範囲指定で複数一度にコピーできるよ
417:デフォルトの名無しさん
25/05/15 20:20:09.57 eepuMYHW0.net
>>416
rebaseしても元のコミットは残ってるからmoveじゃないし
418:デフォルトの名無しさん
25/05/15 20:35:51.71 F0izL13m0.net
>>417
何言ってるわからん
ブランチを移動させたらもとのブランチはなくなる（ブランチに所属しなくなったコミットは後からガベコレで消される）
もちろん別の名前でブランチが残っていればそっちは移動してないのでコミットは消されない
419:デフォルトの名無しさん
25/05/15 21:36:14.90 eepuMYHW0.net
>>418
gitにコミットのmoveなんて概念ないでしょってこと
420:デフォルトの名無しさん
25/05/15 21:39:50.81 F0izL13m0.net
>>419
概念はある
実装が移動先にコピーして後から削除になってるだけ（主に undo 用にしばらく残してる
421:デフォルトの名無しさん
25/05/15 21:48:52.03 6KG6JIoe0.net
mergeもcherry-pickもrebaseも普通に新しいコミットを作る
そのコミットの作り方がユースケースに応じて3種類あるってだけのこと
422:デフォルトの名無しさん
25/05/15 22:25:09.18 AuSI2AJ/0.net
>>415
同じだよ
423:デフォルトの名無しさん
25/05/15 22:42:29.15 eepuMYHW0.net
>>420
だからハッシュ番号変わるんだからmoveじゃないって
自分でも元が残ってるって言ってんじゃん
その理解大丈夫？
424:デフォルトの名無しさん
25/05/15 23:05:28.17 F0izL13m0.net
>>423
コンピュータ技術ではコピーして元のを消すのもムーブいうんだよ IDとかアドレスが変わってもムーブって呼ぶの
知らなかったの？ 勉強になって良かったな
425:デフォルトの名無しさん
25/05/16 00:59:49.81 9SpA05Ma0.net
円錐を横から見た人が三角だといい下から見た人が丸だというような構図ですね
人は争いをやめられないので滅ぼすしかないですね
426:デフォルトの名無しさん
25/05/16 01:36:29.34 b2vWvm610.net
>>424
そもそもコピーじゃないからな
コミットの内容は元とは完全に別物であり、差分だけが再現されている
勉強になって良かったな
427:デフォルトの名無しさん
25/05/16 08:05:25.71 D2sZkK900.net
>>426
幼稚園児か？
完全一致じゃないとコピーじゃないとか言いだしたらファイルコピーとかも所有者とか日付とかいろいろ変わるのコピーじゃなくなるぞ
git のは日付とか作者は変わらないのでまだ保存性高いぞ
cherry-pick と rebase が一緒なんて恥ずかしいこと言ったの話をそらしてごまかしたいんだろうけど無理がありすぎる
cherry-pick は元のが消えない、rebase は元のが消える、方向も逆、べつもの、あきらめろ
428:デフォルトの名無しさん
25/05/16 09:43:07.63 L+lmGGRS0.net
>>427
分かって言ってるのかどうか知らないけど、日付が変わるとかのレベルじゃなく、そもそも差分箇所以外は原理上全くの別物よ
変更内容のムーブというならまだしもコミットのムーブは流石に意味不明
429:デフォルトの名無しさん
25/05/16 10:35:41.49 D2sZkK900.net
>>428
誤魔化すな rebase と cherry-pick は別物、元が消える(ムーブ)のと、消えない(コピー)の違い
ここで言ってるのは元が消えるかどうか、完全一致とかの話題ではない
430:デフォルトの名無しさん
25/05/16 10:46:52.99 FmZiuEdw0.net
rebaseで元は消えないでしょおじいちゃん
431:デフォルトの名無しさん
25/05/16 10:57:16.90 D2sZkK900.net
>>430
もしかして誤魔化してるじゃなくて本当に分かってないの？ マジ？
432:デフォルトの名無しさん
25/05/16 10:59:28.32 iN5covy8d.net
まあ公式が同じだって言ってるしなあ
433:デフォルトの名無しさん
25/05/16 11:09:39.47 D2sZkK900.net
0┳A━B
┗X━Y
を
0━A━B━X━Y
にする時に使うのが rebase
0┳A━B━X━Y
┗X━Y
にする時に使うのが cherry-pick
基本中の基本
434:デフォルトの名無しさん
25/05/16 11:30:53.42 9SpA05Ma0.net
いやどう考えてもそのレベルの話は全員わかってるやろ
この一連のやり取りに足りないのは知識でもIQでもなくEQ
お前ら小学生からリベースしろ
435:デフォルトの名無しさん
25/05/16 11:33:59.63 epkpTq3tM.net
>>431
rebaseはcherry-pickで新しいコミットが作られてそっちに単なるポインタであるブランチが移動したのと同等
コミット消すとか移動とかいう動作は含まれない
どこからも参照されなくなったらいずれgcで消えるってだけ
436:デフォルトの名無しさん
25/05/16 13:50:52.44 BDyQbzP90.net
英語が下手でコミットメッセージを書くのが苦手だったんだけど、AIで自動化したら快適になったぜ
437:デフォルトの名無しさん
25/05/16 14:44:19.53 x3RHmTCL0.net
>>436
そうなるともう、ログなんか書かなくていいんじゃないのとなってくるな
438:デフォルトの名無しさん
25/05/16 14:58:50.14 D2sZkK900.net
>>435
cherry-pick と rebase は別物って納得したんだな
439:デフォルトの名無しさん
25/05/16 15:09:24.62 D2sZkK900.net
rebase の内部動作の話するんなら
1. 分岐点を自動で探し出す
2. 分岐点からヘッドまでを対象の場所へ cherry-pick する
3. 元の場所のブランチ名を消す
4. 新しい場所にブランチ名をつける
5. ガベコレで古いブランチのコミットが消える
これを cherry-pick を繰り返すのと同じだと主張してる時点で何も分かってない
440:デフォルトの名無しさん
25/05/16 15:11:49.54 FmZiuEdw0.net
moveなんてアホな説明しなけりゃよかったのにね
441:デフォルトの名無しさん
25/05/16 15:18:53.26 D2sZkK900.net
>>440
移動してるだろ 432 見たら一目瞭然
コレが基本概念
内部実装の話しして誤魔化そうとしてても、お前が間抜けなこと言った時事は消えない
442:デフォルトの名無しさん
25/05/16 16:07:30.58 Jf7EmrNva.net
>>436
英語で直感的にヤバい時のメッセージに気付く訓練もいるから、AIは使えばいいけど読み書きの練習はしておけよ、と思った。
443:デフォルトの名無しさん
25/05/16 18:15:56.05 Mw5Je42+0.net
とりあえずDt80は一度公式読んできなよ
たかが間違って覚えてたところで誰も煽りやしないよ
あと描いてたツリーで、XだのYだのをリベースなりチェリーピックなりしたやつはXダッシュとかYダッシュとかにしよう
そこだけ流石に同じ文字じゃ読んでてちょっと気持ち悪すぎる
444:デフォルトの名無しさん
25/05/16 18:36:45.50 D2sZkK900.net
>>443
今でも「rebase は cherry-pick を繰り返しただけ」と主張してるの？
そんな覚え違いしてるのお前だけだろ、この通りの文言があったらポインタ示してみろ
どっかの変なサイトが誤訳してるのなら知らんが rebase は cherry-pick してるだけじゃないことはお前も完全に理解できてるだろ
445:デフォルトの名無しさん
25/05/16 21:29:57.00 iN5covy8d.net
このページのgit rebaseの項に書いてあるよ
URLﾘﾝｸ(git-scm.com)
446:デフォルトの名無しさん
25/05/16 23:12:54.87 D2sZkK900.net
>>445
どう訳したらそう誤解するんだ？ 別物だというのは文章から明らかだろう
エスパーしてみると
違うからこそ basically ってわざわざ明確に書かれてるに、もしかして basically て単語知らなかったとか？
native のつかうbasically は「基本部分では、だいたいにおいて」みたいなニュアンスで、本当に同じ時には使わない
「だいたい同じ」を「同じ」って覚えてたんじゃないの？
447:デフォルトの名無しさん
25/05/16 23:28:45.03 CtDSSAzzH.net
>>446
さすがに苦しいぞ
448:デフォルトの名無しさん
25/05/16 23:33:35.97 D2sZkK900.net
>>447
でどう訳したの？
449:デフォルトの名無しさん
25/05/17 08:56:34.42 TogutASM0.net
方向の違いとかコピーとムーブの違いが「同じ」と「だいたい同じ」の違いというわけか。
450:デフォルトの名無しさん
25/05/17 09:18:39.88 S33C25YC0.net
間違いを絶対認めたくないマン
公式まで否定
451:デフォルトの名無しさん
25/05/17 17:33:51.01 t4AM4T1l0.net
>>450
あー、どう訳したか説明しないとこ見るとエスパーが図星なのか
公式が初心者向けに「ほぼ同じです、でもこういう点が違います。詳しい説明はこちらって」って書いてるのの最初のとこだけ見て「ほぼ」も見ないで、後に続く説明もリンク先の詳細も無視して同じって言い張ってただけか
それはお前の読解力が足りてないだけ、公式のせいじゃないぞ
452:デフォルトの名無しさん
25/05/17 17:48:34.70 C8ddlcHs0.net
>>451
訳というかそもそもそのドキュメントは色んな言語版が用意されてて日本語のものもあるよ
訳が気になるなら読んでみよう
453:デフォルトの名無しさん
25/05/17 18:11:19.00 t4AM4T1l0.net
>>452
誤魔化してないで「お前が」同じだと主張する部分を説明してみろ
少なくともリンク先の英語の初心者向けの紹介には書いてないぞ
本当に同じならお前が cherry-pick で rebase 実装してみろ、そうすればみんな納得するだろう、技術者なら実際にやれば同じか別物か分かるだろう
git のソースコード読んだことないやつには想像もつかんだろうが rebase はかなり複雑なことをやってる、初心者向けのページすらまともに読み解けないお前には最初の1歩目の分岐点を探し出す作業ですら絶対に無理と予言しよう
454:デフォルトの名無しさん
25/05/17 20:46:35.58 S33C25YC0.net
そこで何か違うか端的に説明できたらよかったねおじいちゃん
何がmoveしてんですかぁ？
commitじゃなくてbranchのことですかぁ？
じゃcopyってどうゆうことですかぁ？
455:デフォルトの名無しさん
25/05/17 23:11:17.26 t4AM4T1l0.net
>>454
話逸らさずに同じとういうことを証明してみろ
細かい事いえば山程違いがあるけど、違うというのは 432 で素人にも一目瞭然なのに覆せるわけないだろう
間違えた恥ずかしい事実はごまかせないぞ
456:デフォルトの名無しさん
25/05/17 23:17:53.88 pDSuIsUc0.net
違いがあるというなら、あなたがコミットのコピー/ムーブと呼ぶものはどちらも実際には全く異なるコミットを作り出すでしょう
そういうのをダブスタという
457:デフォルトの名無しさん
25/05/18 00:30:50.11 t1q8u3yl0.net
>>456
読解力ないの日本語のなんだな
458:デフォルトの名無しさん
25/05/18 03:09:09.55 G2loPi6x0.net
なんて？
459:デフォルトの名無しさん
25/05/19 09:09:53.56 E91ALV1Y0.net
>>433
XY両方ではなく、XやYのみを取り込むのがcherry-pickというイメージだが
460:デフォルトの名無しさん
25/05/19 21:35:49.68 LwAOa5bv0.net
>>459
普通の範囲指定が効くので
その図なら git cherry-pick ..Y みたいに指定すれば X と Y の両方 cherry-pick できるよ
461:デフォルトの名無しさん
25/05/20 08:32:54.32 IobDhVYO0.net
会話が噛み合わないコントみたいなスレで草
みんな文意文脈にももっと気を配ろうぜ
462:デフォルトの名無しさん
25/05/20 15:48:18.98 iWs/HqBfa.net
「エクスプローラー」の「Git」統合などが実現へ ～Microsoftが開発者向け新機能
ps://forest.watch.impress.co.jp/docs/news/2015419.html
463:デフォルトの名無しさん
25/05/20 16:58:09.70 lxraH8Xn0.net
亀の出番がなくなるのか？
464:デフォルトの名無しさん
25/05/21 08:05:21.38 oZBirtTV0.net
エクスプローラーなんて、Windows7のときに使わなくなったな
465:デフォルトの名無しさん
25/05/21 10:18:53.96 va6/rMbaa.net
MSアカウントにログインしないとExoplorer使えないとか
もうWindows要らんな
466:デフォルトの名無しさん
25/05/25 03:59:20.13 5SaResX20.net
わざわざExplorerからコミットとかプッシュする奴おるんかw
467:デフォルトの名無しさん
25/05/25 07:06:19.26 EfROU4yga.net
OSのSystem領域も含めて全部がリモートリポジトリの運用かな。
468:デフォルトの名無しさん
25/05/25 08:49:46.44 JDhr0Ivk0.net
>>466
申し訳ありません、今でもTortoiseGitでやってます
469:デフォルトの名無しさん
25/05/25 09:13:50.01 TXvAFiBF0.net
Windowsだと、手取り足取り指示してあげないと自分で何もできない「開発者」をExcel方眼紙の手順書で「プログラミング」してあげるような仕事も多いから、
そういう場合に「開発者」の手元にいちいちGitクライアントを導入させるという頭悪い手順を記載する必要がなくなるなら便利かもしれない
470:デフォルトの名無しさん
25/05/29 02:32:23.75 oHIdrLSz0.net
Git v2.50.0-rc0
471:デフォルトの名無しさん
25/06/04 13:13:31.34 nhmcxHVz0.net
Git v2.50.0-rc1
472:デフォルトの名無しさん
25/06/06 01:08:14.98 45aWa19td.net
gitもはや20年か
473:デフォルトの名無しさん
25/06/07 08:05:32.65 tgCEw1aU0.net
gitアレルギー
474:デフォルトの名無しさん
25/06/10 09:49:47.00 DFb9gzxN0.net
Git v2.50.0-rc2
475:デフォルトの名無しさん
25/06/17 08:04:33.42 JQTnqwjt0.net
Git v2.50.0
476:デフォルトの名無しさん
25/06/18 00:48:41.95 zWpFFB0D0.net
オススメのgitクライアント教えて
source treeはなんかuiの一つ一つがデカくて肌に合わなかった
477:デフォルトの名無しさん
25/06/18 02:39:03.14 QsB71xf70.net
自分はlazygitとVSCodeだな
478:デフォルトの名無しさん
25/06/18 08:16:55.75 6RiwAFGc0.net
うちではSourceTreeというやつを使ってるよ
479:デフォルトの名無しさん
25/06/18 09:02:23.67 7Ghn3yO50.net
使いにくいやつね
480:デフォルトの名無しさん
25/06/18 18:04:24.45 c2eS9NyS0.net
lazygitかSourcetreeだな。
481:デフォルトの名無しさん
25/06/19 20:10:05.29 dNWjhAfr0.net
わかばちゃんの中の人
ps://x.com/llminatoll/status/1935310637196095988?t=KJizsM3DHuYlJSyTCzcZcg&s=19
482:デフォルトの名無しさん
25/06/21 23:55:27.59 Rsg0aBc50.net
VSCodeの拡張機能で提供されてる Git Graphが 使いやすいね
483:デフォルトの名無しさん
25/06/22 00:39:02.97 L6Wg3CMhM.net
あれいいよね、見やすい
ハッシュ手打ちの人がんばってw
484:デフォルトの名無しさん
25/06/22 06:56:54.23 APGUbecj0.net
CUI でもハッシュを手打ちすることなんてほぼないだろ
ブランチもタグも検索も使ってないんだろうか？
485:デフォルトの名無しさん
25/06/22 18:51:38.68 4jZfNTw30.net
>>482
んー
でも、他のGitクライアントも似たもんじゃないの？
486:デフォルトの名無しさん
25/06/23 11:27:58.47 KosRMA640.net
似たような、がどの辺を指してるかにもよる。
rebaseかstash簡単にしたい、tag打ちたい、ブランチ作りたいならだいたいどれでも出来る。
ただ現場で初心者多くて教育面倒だし日本語じゃなきゃだめとかいうなら、SourceTreeか
非公式多言語版GitHub Desktopしかないと思う。
487:デフォルトの名無しさん
25/06/23 12:06:20.95 9uUr9jSA0.net
>>486
で、ベストは？
英語でも有料でも、なんでもいいので
488:デフォルトの名無しさん
25/06/23 12:11:55.90 qqxmiRlS0.net
interactiveなrebaseをサポートできてないやつ多いでしょ
489:デフォルトの名無しさん
25/06/23 17:00:15.66 KosRMA640.net
基本は好きなの使えばいいよ。
対面レビューで追加コミット後に「レビューOKだからコミットひとつにまとめといて」って言われたり
「ウチは協力会社に外資いるから日本語コメントだめなんだ、英語にしといて」って言われない限り
rebase(やsquash)やamend使うこともないだろうし。
490:デフォルトの名無しさん
25/06/23 18:37:21.89 MPl++Mur0.net
いや rebase -i も --amend も使いまくりだろ
何なら一番多く使うコマンドまでありえる
一発で完璧な記録できて後は触らないみたいな超人じゃなきゃ、普通に多用するだろ
491:デフォルトの名無しさん
25/06/23 19:49:45.04 Z8z+4HFt0.net
といっても元のコミットがある程度ちゃんと作られてることが前提じゃない？
単に作業のチェックポイントとして気軽にコミットしてると、いざコードレビュー前に整理しようとしたときには元のコミットを無理に再利用するより
resetして作り直した方が早いことが個人的には多い
書いてて思ったけど、元のコミットがすでに整理されている上で修正を入れる状況としては、コードレビューの中での修正があるね
もしチームのポリシーとして瑣末な指摘反映をログに残さないことにしているなら、レビュー後マージ前にrebase -iするのは便利かもしれない
492:デフォルトの名無しさん
25/06/23 21:20:02.74 MPl++Mur0.net
そっちじゃなくて手元で色々作り散らかしたコミット履歴を綺麗に読み易く整理してから、レビューに出す。
順番入れ替えたり、コミットメッセージを分かり易くしたり、不要な履歴を消したり、コミットを意味に合わせて分割したり、統合したり
その整理に活躍するコマンドが rebase -i、慣れると手放せない
読み易く整理されてれば他人の時間の節約になる、試行錯誤とかタイポ修正とかの痕跡を他人に見せて時間を奪わなくてすむ
493:デフォルトの名無しさん
25/06/23 22:25:23.37 YcF93ZoT0.net
そんなの方法を議論する以前にもうAIにやらせたらいいんじゃないかという気もするが、
AIにやらせるならやっぱり一連のgitコマンドを直接生成させるのがいいのかなあ
コマンドだと人間が実行前にレビューするのは辛いものがあるから、diff入りのコミットログみたいな形式で生成させて、resetした上でそれを反映するのがいいと思うんだけど
494:デフォルトの名無しさん
25/06/24 07:59:57.08 oSvYVpQb0.net
>>493
AI に期待し杉
今のAIはしょせん賢い検索エンジンに過ぎない
学習したことの最も多数派の意見をそれらしく繋ぎ合わせてるに過ぎない
素人が玄人の作業を真似るのには使えるけど、玄人の創造的作業の代替は無理
495:デフォルトの名無しさん
25/06/24 08:31:50.93 1VpUD11F0.net
>>492
プロトタイプであれやこれやするなら、さらにブランチ作って動くようになったら新しいブランチに
Squash and Mergeして、そっちのブランチをレビュー対象にした方が楽なんじゃ？
496:デフォルトの名無しさん
25/06/24 10:30:20.42 oSvYVpQb0.net
>>495
いやだから、色々なブランチに順不同で入ってるやつの共通部分を括りだして独立したコミットにしたり、一つのコミットを内容に合わせて複数に分割したり、ばらばらのを分かり易く統合したり
やるべきこっとはいっぱいあるだろ
merge も squash も amend も全部 rebase -i を使ってやる、rebase -i を何だと思ってるんだ？
497:デフォルトの名無しさん
25/06/26 10:59:58.77 JcQLzuh60.net
amendやsquashを一般人が簡単にやりたいならGitHub Desktopの履歴のとこから出来るけど
使用説明が一切ないんだよなあ。圧倒的なドキュメント不足。
498:デフォルトの名無しさん
25/06/26 12:02:10.03 3juiMOaqM.net
>>496
アトミックに細かくコミットする人ならrebase -iでの整理は容易だろうけど、分割が多い場合は面倒臭すぎるでしょ
resetしてやり直した方が早いわ
499:デフォルトの名無しさん
25/06/26 14:45:21.20 rhHx6Nng0.net
>>498
意味分からん
「細かくコミット」と「分割が多い」は同じじゃないの？ お前の用語での違いは何？
コミットを統合したり分割したりするのも rebase -i から始めるのに？
いくらでも変えられるのに何が問題なの？
500:デフォルトの名無しさん
25/06/26 17:51:44.27 JcQLzuh60.net
「細かくコミット」がバックアップ保証のつもり(で修正が動くかどうかも分からん)なら、
都度commitだけしといてpushは待っとけばいいんじゃないかなと思ったり。
501:デフォルトの名無しさん
25/06/27 10:30:24.43 KAeTyQMQ0.net
当たり前だろ
動作確認できてないものpushすんなよ
502:デフォルトの名無しさん
25/06/27 10:39:46.35 iePZ28tO0.net
>>501
どこに push するか次第だよな
共有リポジトリや公開リポジトリに push しちゃ駄目だろうけど個人のバックアップ・リポジトリとかに push しとくのは自由
リポジトリやブランチを好きなだけ作れて高速に同期できるのが git の利点なんで限られた少数のリポジトリしか使わないのはもったいない
503:デフォルトの名無しさん
25/06/27 10:46:55.51 Vbo+wzUI0.net
GitHubでのチーム開発だと普通に共有リポジトリにpushするけどな。
ただしpush先はいわゆるfeatureブランチなど、そのタスク専用のブランチ。
draft pull requestを作っておいて他人から容易に目に見えるようにするとなお良い。
むしろ手元で長いこと留めてあいつ何やってんだろと思ったら突然クソデカpull request投げてくるような奴は嫌われるよ。まあ開発に限った話ではないが。
504:デフォルトの名無しさん
25/06/27 14:47:42.22 iePZ28tO0.net
>>503
その辺はチームの方針次第だね
リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか
マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う（個人の意見
505:デフォルトの名無しさん
25/06/27 15:24:34.92 caL9+2zdM.net
>>504
本題からは逸れるんだが、企業での開発で個人リポジトリにforkする運用ってなんかメリットあるのかな？
自分はこれまで共有リポジトリ運用しか見たことがない
なお、新卒がいきなりforkして怒られてるのは何度か見た
forkして複数の共有リポジトリを使うのは複数の会社がいてそれぞれガバナンスが違うケースなんかで珍しくないけど
506:デフォルトの名無しさん
25/06/27 17:03:03.14 iePZ28tO0.net
>>505
github みたいに fork って呼ぶから混乱するんじゃないかな？ オープンソースじゃないから単なる clone だろ
開発用の clone はいくつあっても良い、個人用でもデスクトップとノートPCとサーバと複数の場所にリポジトリもってて定期的に同期させたりしながら、移動中とか自宅とか会議中(笑)に開発したりできる
もちろん会社の情報統制や社外秘情報の漏出防止のためにコピー禁止とか部屋外に持ち出し禁止とか決まりあれば従わないと駄目だが
507:デフォルトの名無しさん
25/06/28 00:10:08.26 Nhn9wgjX0.net
Gitむずかしい…
Pythonよりむずかしい…
508:デフォルトの名無しさん
25/06/28 11:34:58.63 WNSkpT1F0.net
雑にpushするブランチを作ってあるので
ホイホイプッシュしてる
509:デフォルトの名無しさん
25/06/28 14:23:18.12 ps+a9/JT0.net
いやPythonの方が難しいでしょ
510:デフォルトの名無しさん
25/06/28 15:15:53.19 Nhn9wgjX0.net
初心者なんですが、
branch1とbranch2があって、
branch1にcheckout後に、>git merge branch2 と、
branch2にcheckout後に、>git merge branch1 って、
結果は同じ？
511:デフォルトの名無しさん
25/06/28 15:31:34.65 XJ1OnLan0.net
>>510
ソースコードの内容は同じになる
ログは違う形になる
ログはどのようにソースを扱ってきたかの履歴書や歴史書のようなものなので複雑で大規模なプロジェクトほど価値が出る
512:デフォルトの名無しさん
25/06/28 15:47:58.18 Nhn9wgjX0.net
>>511
あ、
今やってみましたが、
mergeコマンド実行するときの自分がいるブランチのほうが、引き続き残るって感じですかね？
513:デフォルトの名無しさん
25/06/28 16:06:18.63 XJ1OnLan0.net
>>512
ブランチ自体はどちらも残る
自分がいる方のブランチはマージ結果を指す形で歴史が一方進む
そうじゃない方のブランチはありのまま残る
514:デフォルトの名無しさん
25/06/28 17:09:16.02 GU5N/G5Q0.net
「自分が今いるブランチに指定したブランチの「内容」を混ぜ（merge）する」というのがコマンドの意味
当然
・今いるブランチは書き換わってコミットが進む
・指定したブランチには変化なし
515:デフォルトの名無しさん
25/06/28 18:17:50.37 Nhn9wgjX0.net
>>513
あ、
自分がいたほうじゃない方のブランチは、
branch3とかにつなげられますね…
516:デフォルトの名無しさん
25/06/28 18:19:22.53 Nhn9wgjX0.net
>>514
ですね
わからない理由は、日本語のまともな解説が無いからですね…
海外の解説で、ようやく理解できました…
517:デフォルトの名無しさん
25/07/01 20:11:53.56 HVBtOzc60.net
混じるからマージる
518:デフォルトの名無しさん
25/07/01 22:46:34.19 BgB6BrdO0.net
去年のリリースの記憶をタグる
519:デフォルトの名無しさん
25/07/02 21:57:57.01 xYSFlqIW0.net
頭悪い人って自分が理解できないのを説明する人のせいにしがちだよね
説明が悪いならなんでお前以外の人は理解できてるのかと
520:デフォルトの名無しさん
25/07/03 03:33:50.65 ZlHu/VzU0.net
能力不足故に検索の仕方や聞き方が下手で自らが望む解説に効率的にアクセスできない
ダニングクルーガー効果のような認知バイアス
元から他責的、依存的なせいで残り少しの努力を怠り多方面で理解不足に陥りがち
この中のどれかか、複合要因ではないかな
521:デフォルトの名無しさん
25/07/05 16:41:53.58 Jt1MZnHo0.net
>>519
それは、
運良くいい説明を見れたからでしょ
お前には無理そうだが
522:デフォルトの名無しさん
25/07/05 17:28:57.77 99i/fp2o0.net
大丈夫だよ
プログラム書いたらビッとコミットしてギュッとプッシュしてギャンよ
523:デフォルトの名無しさん
25/07/06 09:39:11.50 AHvPqc/80.net
コミッとコミットする
524:デフォルトの名無しさん
25/07/09 16:29:53.53 NiP9rW7K0.net
Git v2.50.1
525:デフォルトの名無しさん
25/07/09 20:54:58.43 5nTmkCkK0.net
初心者の質問ですが、
Linux（サーバー的なもの）に、GitHubのレポジトリをクローンして来て、
それをWindowsパソコンからSSH接続して、
Gitの履歴の図（Gitグラフ？）って見る方法ありますか？
526:デフォルトの名無しさん
25/07/09 22:47:25.77 OQriWW8/0.net
ありますね
527:デフォルトの名無しさん
25/07/10 12:47:26.79 +1gidKVl0.net
>>526
会話を広げる癖をつけろ童貞
528:デフォルトの名無しさん
25/07/10 20:49:27.62 tN4eS5FO0.net
>>527
なら会話広げればいいじゃん。
529:デフォルトの名無しさん
25/07/13 17:29:18.40 QlUonva10.net
>>525
sshで git log --graph で履歴取ってきて、mermaid変換してmarkdown埋め込みにすればいいんじゃね？
530:デフォルトの名無しさん
25/08/06 12:13:19.02 48BfQKJO0.net
>>527
あると信じて検索すれば報われますよというありがたい情報だぞ
531:デフォルトの名無しさん
25/08/13 06:18:19.45 YOB+IZc5r.net
やりますね
532:デフォルトの名無しさん
25/10/22 09:23:57.49 pnMMn99c0.net
URLﾘﾝｸ(forest.watch.impress.co.jp)
次のバージョンからgit svnが廃止されると書いてあるけど、
これはSubversionからの変換もできなくなるということでしょうか
533:デフォルトの名無しさん
25/10/22 13:20:45.27 2nDvyZJf0.net
Git for Windowsの次回メジャーリリースでの話をしてるならそうだよ
旧バージョンや本家を使うとか、svn2gitだとか別VCS経由とか手作業での移行だとかは出来るでしょう
534:デフォルトの名無しさん
25/10/22 13:52:16.21 Nfi7SE1t0.net
もうシンプルに使われてる機能だけをブラッシュアップすればいい思う。
互換性とか古いものをメンテし続けるのは大変だよ。
535:デフォルトの名無しさん
25/10/24 14:37:23.45 nAYKU6CIa.net
いまだに新規プロジェクトでSubversionからっていうのはもう洗脳されてるから放置で良いし
Subversionから変換する気があるならもうとっくにやってるだろうし
536:デフォルトの名無しさん
25/10/24 15:02:05.38 ZcyI5XOE0.net
Windowsユーザーだと、業務でSVNを使わざるを得ないがGitコマンド経由で使うことで辛うじて自己の尊厳を保っていた人もいそうだな
電車止まりそう
537:デフォルトの名無しさん
25/10/24 18:33:25.65 J3E6mCG+0.net
>>536
そんなプロジェクトやだなぁ
538:デフォルトの名無しさん
25/10/24 20:17:02.32 NslM5AvMr.net
令和なのにまだSVNで消耗してる人いるんだ
絶滅危惧種かな
539:デフォルトの名無しさん
25/10/24 23:30:36.26 vJAYr0tv0.net
>>536
Gitって、開発速度は遅くなるよね
コードレビューとか丁寧にやると遅くなるよね…
540:デフォルトの名無しさん
25/10/25 00:27:30.86 a9lDbV800.net
>>539
規模（参加人数、開発期間、コードサイズ）次第。大きくなれば git 使った方が早い
541:デフォルトの名無しさん
25/10/25 04:23:36.31 kofX/eP60.net
>>539
gitだからコードレビューが必要って認識？
アホじゃね？
542:デフォルトの名無しさん
25/10/25 08:42:34.81 /eT+OdROH.net
SVNと比較しての話なら、Gitはコミットやブランチの操作が遥かに軽量だからこそ、
チームが必要以上に面倒なワークフローを作り込みがちな面があることは否定できないな
非機能要件でちゃんとバージョン管理しろと書かれているからという理由だけでVCS使ってるような典型的な業務系でSVN使い続けてるようなとこだと、
レビュー済みまたはリリース済みのコードをコミットするだけみたいな運用は珍しくないからな
そういった意味で、VCSの運用という点だけ見ればGitの方が複雑になる傾向があるとは思う
543:デフォルトの名無しさん
25/10/25 12:06:31.87 lNU8C84m0.net
>>540
まあ、
大規模だと、ちゃんと管理が必要ですね…