Git 20

2024/12/17(火) 07:53:20.59ID:n6Rf+SXX0
>>221
ありがとうございます
Sourcetree独自の機能か分かりませんが
チェリーピック元のコミットIDをコメントに付与しているため
もう辿ることもないコミットならコメントから余計な情報は
省いた方がよさそうですね
2024/12/17(火) 09:46:53.70ID:Np7JyJBV0
>>222
それは git cherry-pick -x で付く情報だと思う
公開されないコミットへの参照は残さないほうがいいね
2024/12/17(火) 12:10:27.20ID:Mk8ZrsM80
残ってても邪魔にはならないだろうけど cherry-pick 元がすぐ消える予定なら、付けないのが普通ですね
225デフォルトの名無しさん (ﾜｯﾁｮｲ 8fb9-/rN0)
垢版 |
2024/12/17(火) 13:07:22.36ID:bMW/7Xg20
チェリーピックって童貞狩りじゃねえのか？
2024/12/17(火) 13:48:26.81ID:8t1OBzHLM
つまんな
2024/12/17(火) 14:02:58.22ID:Mk8ZrsM80
cherry pick
1. 都合の良いものだけを (恣意的に) 選び出す
2. 慎重に必要なものを選別する
2. 好きなもののみを摘み食いする
4. バーゲン品から掘り出しものを漁る
5. 木から熟したサクランボだけをもぎ取る

5が本来の使われ方、1の意味で使われることが多い
2024/12/17(火) 22:22:58.48ID:uhdhcEFf0
コミットする内容を複数に分けたい場合、必要な部分だけステージングすると読んだのですが、
この機能を使っても作業フォルダの内容は変化しないので、
一緒にコミットするべきだったところを入れ忘れてしまい、
プルしても正しく動かない状態のものを上げてしまっていたということがあります

この一発勝負みたいなステージングの機能をみんな使いこなしているのでしょうか？
2024/12/17(火) 23:11:14.06ID:Np7JyJBV0
>>228
一発勝負っていう感覚はおかしいでしょう
一度ステージングした後やコミットした後でプッシュするまでもいくらでも再確認とやり直しのチャンスがある
危うい操作をしたのに十分に確認していない内容をプッシュしてしまう習慣のほうがどちらかというと諸悪の根源だと思う
SVNだってローカルの変更を部分的にコミットしようと思えば同じようなリスクがあるので、ステージングという考え方自体のリスクではない
分割してコミットはビルドの通らないコミットを作ってしまうリスクは増すから不慣れで自信のないオペレーションになったときはstashやswitchを活用して疎通確認しておくとか、要らん変更と意図的に残した変更と漏れた変更を混同しないようにassume-unchangedやskip-worktreeなんかを活用してもいい
2024/12/17(火) 23:14:08.08ID:QjcMYSDT0
>>228
複数のコミットで一つの修正になるならrebase してまとめたら？
2024/12/17(火) 23:25:32.69ID:Np7JyJBV0
>>228
問に回答してなかった
ステージングの機能を使いこなしているかはNoです
差分確認からコミットまでの流れはGUIのほうが好きなのでステージングは全然活用できてない
2024/12/17(火) 23:33:17.82ID:Mk8ZrsM80
>>229
git status とかを頻繁に打つくせをつけた方が良いぞ、それでコミットし忘れ防げる（ついでによく使うオプションは alias にするとさらに良いぞ）
あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ
2024/12/17(火) 23:34:08.72ID:Mk8ZrsM80
>>232
アンカミス >>228 あて
2024/12/18(水) 09:25:32.99ID:IhQ3pKwU0
Git v2.48.0-rc0
2024/12/18(水) 11:41:14.09ID:pGa0ZLUBM
>>228
もうでてるけど
いれないものはstashして動確してcommit
stagingの存在理由わかってくる
2024/12/19(木) 21:05:36.88ID:KU+lpcLj0
>>218
言うほど同じか？
rebaseを好む派閥がrebase使う最大のモチベーションはログの直線化
そういう神経質な連中がcherry-pickによる重複コミットの大量発生を許容するとは思えないのだが
237デフォルトの名無しさん (ﾜｯﾁｮｲ 2303-AYc0)
垢版 |
2024/12/19(木) 21:38:31.24ID:QSrQ7dPA0
やってることの内容は似てるけど用途が全然違うからなあ
かのPro Gitもリベースの章はベタ褒めでahhとかthe bliss of rebasingなどと顔もやや恍惚気味の御様子だが
チェリーピックとなると淡々とした説明で真顔だよ
2024/12/19(木) 23:45:56.41ID:b251oEg00
>>236
目的じゃなくて動き(実装)の話
rebase で cherry-pick できるし
cherry-pick で rebase できる
どっちもコミットの再利用(付け先の変更)を目的とするコマンド
あと直線化にしか rebase 使わないと思ってるうちは git の実力が認識できてない
2024/12/20(金) 01:21:38.28ID:+bubGwJY0
リポジトリを分けるか、モノでやるか
統合度合いが微妙な場合にものすごく悩む
2024/12/20(金) 09:56:06.03ID:PANCPXf30
そんなところで悩んでいる段階なら分けなくていいよ。最初から細かく分けようとするのは基本的に時間の無駄。
成功している組織はだいたいクソデカリポジトリなのも事実。それについては戦略としてモノレポが優れているというよりは結果的にそうなっただけだろうけど。
2024/12/20(金) 11:20:48.46ID:Vt9p1L/d0
>>239
一般論にはメンバーで分けるとうまくいく事が多い
将来的に人が増えたり入れ替わっても同じ1つのグループで開発を続ける予定なら一緒にする、
対応するグループが分割されて片方だけに関わる人が出てきそう、もしくは不明なら別にしておく
2024/12/20(金) 12:26:56.43ID:PANCPXf30
「うまくいく」の定義によるかなあ
分かれている方が良いという前提のもとで失敗の可能性を下げるという意味では>>241に同意するが、
個人的には不適切な分割による失敗は幾度も見たことがあるが、逆に一緒であることの直接的な実害にはあまり遭遇した経験がない
巨大なモノリスへと誘導されやすいみたいなアーキテクチャに対する影響は否定しないが、そのへんは日常的なコーディング作業というより
もっと大きな視点で恣意的に判断すべきことかと思う
そして、その判断を今すべきか、そもそも可能なのかは冷静に考えた方がいい
2024/12/20(金) 12:53:34.97ID:Vt9p1L/d0
>>242
・分かれてるものを一緒にするのはとても簡単だが、1つのものを分割するのはかなり手間がかかる
・単純なものどうしを組合わせるのは単純作業だが、複雑なものを組合わせるのは不可能な場合がある

という一般原則による、悩んだ時は原則に従うのがたいてい正しい
2024/12/21(土) 08:12:17.24ID:/IqCjkFy0
>>243
同様に、下記も言える
- 共通化されているものを個別化するのは簡単だが、個別化されているものを共通化するのは難しい
世の中そんなに単純じゃないんだわ
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
難しくてわからない質問されて見下された気がしてイラッとしたからとりあえず煽っとくまで読んだ
2025/02/27(木) 18:59:01.12ID:8vSp/RjD0
おかしな人を一人見ただけで最近の子は～とか言い出しちゃうのって老化現象なのでは
347デフォルトの名無しさん (ﾜｯﾁｮｲ 7a75-08Wt)
垢版 |
2025/02/28(金) 01:35:09.82ID:1HSOHgVq0
>>337
ターミナルも仕様がよくわからないのによく使うな
比較的、新しいものを使うなら古い方を知ったうえで使わないと
2025/02/28(金) 02:45:09.17ID:anIDZvfV0
ここ老人ばかりだし老化現象ではと言われてもあんまり効かないよね
2025/02/28(金) 08:41:15.61ID:rekq6zs60
>>336 に礼くらいしろ。
感謝すらできないタダメシ寄生虫かよ。
2025/02/28(金) 09:19:01.12ID:f1y1aNyV0
礼を求めるのはムリだろー
素直に教えを請うのではなく怒り散らすことで回りが俺様を助けてくれることを期待する駄々っ子タイプなのは最初の発言からわかってる
2025/02/28(金) 09:30:18.88ID:f1y1aNyV0
今回の場合、Gitのダメなところをぶちまけて憂さ晴らししようとす来たら反論で恥かかされてさらに怒ってるまである
352デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-c/TO)
垢版 |
2025/03/01(土) 11:36:53.90ID:dZ2eBKvGa
久々に落ちて来た餌に群がる深海魚のようでつね
2025/03/01(土) 12:39:20.26ID:uxtJasyd0
よく言われる
顔が深海魚みたいだって
354デフォルトの名無しさん (ﾜｯﾁｮｲ 7986-3FuH)
垢版 |
2025/03/05(水) 20:27:54.18ID:k4iH0qBY0
masterからbranch切ってコミットして、VSCodeにSyncronizeってボタンでたからそれ押したらmasterブランチで？に？pushされた
これってコマンドだとどういうコマンド使ったことになるの？

何か嫌だったからmasterブランチの方はpullしてrevertして、masterと新しく切ったbranchをpushしなおした
2025/03/05(水) 20:32:53.30ID:DnMeoT1g0
GitはCLIの方が圧倒的に使いやすいわ
GUIやとでけへんことが多すぎるし逆に面倒やからな
ニワカどもがSourcetreeとかGithub Desktopとかを初心者にすすめんのやめーや
最初が肝心なんやからどうせ教えるならしっかり手取り足取りCLIで教えたれ
2025/03/06(木) 02:17:50.54ID:X0p8pnT00
コミット履歴見ながらあれこれやるときはcliはやってられんでしょ
357デフォルトの名無しさん (ﾜｯﾁｮｲ 79ab-kaVN)
垢版 |
2025/03/06(木) 08:13:14.54ID:SoBTsc5U0
サーバ側のログ見たけどエラーログしか吐いてなくて、アクセスログ的なログは無かった
2025/03/06(木) 08:37:02.92ID:TZy25+2E0
>>356
why?
CLI しか使ったことないけど
359デフォルトの名無しさん (ﾌﾞｰｲﾓ MMeb-tbEw)
垢版 |
2025/03/06(木) 13:33:57.70ID:SW3gTDW+M
>>355
コマンドはネット上に嘘が大量に書かれているからなあ
2025/03/06(木) 14:56:33.55ID:hrpDJRUa0
>>359
マジで？
困った時しか調べないので気付いてない。
2025/03/06(木) 15:07:24.98ID:X0p8pnT00
>>358
マウスなら数手で済むところをハッシュ見て打ち込んでスクロールアウトしたから見直してとか非効率
何事も向き不向きがある
2025/03/06(木) 16:54:30.08ID:TZy25+2E0
>>361
意味わからん
普通キーボードから手を離してマウスに手を持っていく暇があれば、その時間にコマンド打ち終わって実行結果の確認まで終わって次の作業始めれるけど？
CLI使うかエディタのショートカット使うかの2択だろ、マウスの出る幕はない
2025/03/06(木) 17:47:20.86ID:X0p8pnT00
>>362
それいうならおれはトラックポイント使ってるから持ち替えるなんて無駄はとっくの昔に排除してるっての
おれはCLIでも使える
環境変えた時に困るからな
で比較した上で言ってる
2025/03/06(木) 18:43:44.49ID:TZy25+2E0
>>363
何が言いたいか分からん、俺は無能なのでGUIで十分って言ってるの？
「CLIだとやってられない」の根拠をまるで示せてないけど？

command のオプションとか使いこなせてないだろうことは何となく察せられる。例えば履歴見る時に git log に -G とか --grep とか使ったことある？ この違いって即答できる？
2025/03/06(木) 19:00:28.81ID:/b+y/+WW0
いやGitは明らかにGUIよりCLIの方が使いやすいんやがwww
いやちゃうなCLIが使いやすいんやなくてGUIがどれもクソすぎるんや
唯一マシなGitKrakenはクソ高いサブスクやしな
2025/03/06(木) 19:10:55.39ID:EYycW5pS0
CLI派はステージする行を取捨選択したいときどうするの？
煽りたいわけじゃなくて興味がある
なお俺は普段VSCodeとlazygitを使っていて込み入った操作のときだけCLI使っている
2025/03/06(木) 20:03:56.86ID:TZy25+2E0
>>366
git add -e でエディタで選択
git add -i でCLIメニューで選択
個人的には前者を多用してる
2025/03/06(木) 23:00:54.80ID:FATO06L/0
マウスに一切持ち替えないCLI過激派の人ってハッシュは目視確認して手で打ってるの？
HEAD~~とかHEAD~4とかでだいたい済むから手打ちするにしても稀な感じなのかな
2025/03/06(木) 23:23:19.37ID:54POgzsF0
過激派じゃないからやったことないけど、マウス使わずにCLI単体で目的のハッシュ検索→コピー→ペースト出来んじゃないの？
2025/03/07(金) 00:54:33.86ID:t6N/68bn0
CLI で hash値を入れることなんてまずないだろ
直近のは HEAD やブランチ名からたどるし、古いのはタグ打ってたり、検索条件で特定する
どうしても hash値で特定したい時は先頭の4文字とか打つだけでいけるので全部入れる必要はないよ、そんな機会はめったにないが
あとやろうと思えばCLIでもエディタ操作でマウス以上に高速にコピペできるけど
2025/03/07(金) 02:01:32.04ID:hA31zhIA0
GUIでポトペタばっかしとる奴らの前提が空で覚えるの前提なん草
そもそもTerminalもGitbashもインテリセンス効くことを知らんの無知すぎてクソワロタ
372デフォルトの名無しさん (ﾜｯﾁｮｲ 5312-tbEw)
垢版 |
2025/03/07(金) 02:20:38.51ID:DC3oMiFw0
自分がやっていることを説明しない、説明できないタイプは、コマンドに逃げる傾向があるんだよな。
2025/03/07(金) 05:10:53.94ID:rO0CBAe5d
>>372
というより、そうする必要があるかどうか次第だな
>>367からも分かる通り、メクラコミット中心ならCLIで十分、コミット内容の細かな編集が多いならCLIの範疇だけでは難しい
2025/03/07(金) 08:46:11.25ID:t6N/68bn0
>>373
難しくないだろ git add -e で完璧制御できる
パッチをそのまま目視できて編集できるんだから、もっとも確実
どんな細かい変更でも自由、なんらら一行に複数の変更がある場合に一部だけとか、実際にソースにない変更も可能
2025/03/07(金) 09:59:34.81ID:qPWIu0Mm0
エディタ使ったらそれもうCLIじゃないでしょ
TUIではあるけど、それを広義のCLIと認めるならlazygitやtigのような実質GUIと変わらんようなTUIクライアントもCLIになってしまうがそれでよいか
376デフォルトの名無しさん (ﾜｯﾁｮｲ 5312-tbEw)
垢版 |
2025/03/07(金) 10:28:55.57ID:DC3oMiFw0
Gitを使っておきながら、他人にはわからないコマンドだけの手順を書くやつは必ずいるしな
377デフォルトの名無しさん (ﾜｯﾁｮｲ 79d3-3FuH)
垢版 |
2025/03/07(金) 10:52:06.81ID:i3TW8fQU0
>>375
こんなの暴論だろ
どうやってコード書くんだよ
2025/03/07(金) 11:15:57.74ID:TL3VpnxxM
コーディングとは違ってステージ時のパッチ編集はGitのために行う操作なんだから、GUIクライアントとの比較の文脈ではGitの操作の一部と見做すべきでしょ
git guiはCLIか？git add -eでVSCodeを開くのはCLIか？
エディタを呼び出した時点でもはや純粋にCLIと呼べない以上、程度問題でしかないってことだよ
2025/03/07(金) 11:23:23.99ID:t6N/68bn0
>>378
CLI といにはもともとがスクリプト書いたり、エディターから呼び出すパーツを想定してあって、毎回直接打たないといけないって意味じゃないぞ、あくまでも git にアクセスするインターフェイスの種類
自分用にカスタマイズして使うのは当然
2025/03/07(金) 11:35:48.56ID:TL3VpnxxM
そう。そしてGUIクライアントも同様にCLIを呼び出すインターフェースに過ぎない。
だから変な差別意識持たずに仲良くしような。
2025/03/07(金) 11:44:27.31ID:t6N/68bn0
>>380
インターフェイスというのは「呼び出し側が理解して制御してる部分」と「制御していないブラックボクスとして扱う部分」の境界のことだ
UI ならユーザとアプリの境界、その動作が内部でどのコマンドに展開されるか想定してばスクリプトやエディタから呼んでもCLI
一方でボタン押すだけで中でどのコマンドに変わるのか全然理解できてなければCLIではない
2025/03/07(金) 11:49:35.66ID:t6N/68bn0
ユーザーが制御できてるか簡易に見分ける方法は「自由に変更できるか」だ
呼び出すコマンドを理解する必要があって自由に変更できるならボタンからだろうショートカットからだろうとCLIでいい
自由に扱えないならそれはインターフェイスの向こう側だ
383デフォルトの名無しさん (ﾜｯﾁｮｲ 79d3-3FuH)
垢版 |
2025/03/07(金) 12:50:44.02ID:i3TW8fQU0
正直そんな事どうでもいいから>>354教えてほしいです
2025/03/07(金) 13:45:02.36ID:hv4T53nE0
>>370
それ都合のいいようにCLIの不利なケースを排除してるだけだろ
お前みたいなやつは死ぬほど見てきた
CLIで曲芸してるだけ
適材適所で使うってだけの話を受け入れられない
2025/03/07(金) 13:58:21.86ID:t6N/68bn0
>>384
そもそもCLIで使う前提でコミットログ書くし、ブランチ切るし、タグ打つし、git のUIは最初からそういう設計になってつんだよ
全部のハッシュ打たなくて確定できるまでの文字打てばすむのもそう
git は CLI を使うプログラマによって設計開発発展してきた履歴があるので CLI で困ることはない
「CLIではやってられない」とか言い出すのはそいつが未熟で git に慣れてないだけの妄想
まあ全員が git に慣れてる必要はないので口を閉じて「馬鹿でも使えるものは馬鹿しか使わない」という世界に閉じこもってろ
2025/03/07(金) 14:16:08.04ID:hv4T53nE0
>>385
マウスの持ち替え気にするくせにハッシュを目視で確認して打ち込む非効率さは目をつぶる
インタフェースやビジュアライズの大切さを無視するエンジニアとは仕事したくないね
ちなデバッガももしかしてCLIかい？w
2025/03/07(金) 14:28:05.14ID:0jIQFjkxH
>>385
君の意見を否定するつもりはないが、事実としてGitの公式ディストリビューションにはGUIが付属しているし、git gui コマンドも存在するし、公式サイトで非常に目立つ形で非公式のGUIクライアントを紹介している
こんなところでヘイト撒いてる暇があったら削除するようリクエストしてきた方がいいぞ
2025/03/07(金) 14:58:36.90ID:xU3go4h6a
CUIって自分の操作の履歴辿れるけど
GUIは何やったか覚えてないとか
意図しない変化があったときに今何した？ってなるのが嫌
389デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1d-8P30)
垢版 |
2025/03/07(金) 15:02:30.73ID:xU3go4h6a
>>354 の感じてる「なんか嫌」も >>388 と同じ理由だと思う
2025/03/07(金) 15:36:27.72ID:t6N/68bn0
>>387
別にGUI使っちゃ駄目とは一言もいってないぞ、GUI使いたいやつだけ勝手に使ってれば良い、それで苦労しようが失敗しようが知ったこっちゃない
「CLIではやってられない」という虚言を否定してるだけ、俺はCLIで十分
2025/03/07(金) 15:40:54.21ID:t6N/68bn0
>>386
キーボードで16進数4文字打つのが非効率なの？ マウス操作の方が早いの？
俺とは違う技術で生きてるみたいだな

デバッガやプロファイラは自作スクリプト経由のことが多いな、スクリプトなしで簡易にやるならエディタのマクロ
2025/03/07(金) 17:31:19.43ID:hv4T53nE0
>>391
タイピングの問題でなく目視でハッシュを確認ってのが非人間的で非効率って言ってんの
そういう受け取り方をするってことはやっぱりUI/UXの視点が欠如してるんだよお前は

でデバッガをスクリプトで使うとは恐れ入った
全く別世界に生きてるのは同意
2025/03/07(金) 18:54:27.19ID:t6N/68bn0
>>392
良く分からんが目が悪いの？
普通はタグとか検索結果からの相対指定で使うんだよ
何らかで間違ってタグを消したとかごく稀にどうしてもハッシュ値で指定したい時に、年に1回くらい目視確認で4桁の数字打つだけだよ
簡単なんだけどなあ
2025/03/07(金) 19:04:16.99ID:bYeAoHPJ0
チーム開発だと、かなり前の特定のコミットをrevertしたりcherry-pickしたりは全然珍しくないけどなあ
395デフォルトの名無しさん (ｱｳｱｳｳｰ Sa1d-8P30)
垢版 |
2025/03/07(金) 20:04:21.73ID:xU3go4h6a
GUIならHash目視しないのかな
2025/03/07(金) 20:40:14.65ID:ZrsdmfZ80
仕事でチーム作業してたらハッシュは4桁では足りないからやっぱ手打ちはヤダな
バグトラッカーやクラウドのツールと交互に使うからマウスに持ち替えずにキーボードだけであらゆるGit操作を駆使！スゴイ腕前！とはならないかなあ
やっぱり達人は5chもcurlで書き込んでんのかな
2025/03/07(金) 20:58:11.36ID:t6N/68bn0
>>394
そもそもそういうのはref検索とかで指定しない？
ログを目視しながらハッシュ値を探したりしないと思うんだが
ハッシュ値で指定することなんてめっにないんだから気にする時点で何か効率の悪いことしてる気がする
2025/03/07(金) 21:01:27.92ID:qVctmwDB0
GUIやCUIの原理主義者じゃない限り
どっちでも使いやすいところで使い分ければ済む話だろ
ただ、GUIに関しては、CUIのコマンドオプションの何を行うコマンドかが分かる程度に表記してほしい
英語表記でも微妙、日本語ならばなおさら困惑する
できればCUIのコマンドオプションを併記してほしい
2025/03/08(土) 00:55:57.26ID:f1gAdLsE0
ハッシュ値指定しない人は多分GitHub使ったことないんだと思う
2025/03/08(土) 11:24:47.06ID:lsvDMVeL0
Git v2.49.0-rc1
2025/03/08(土) 11:29:06.73ID:lsvDMVeL0
>>400
ChangeLogに以下の説明があり、Git3.0にむけてbreaking changeがある模様

* Following the procedure we established to introduce breaking
changes for Git 3.0, allow an early opt-in for removing support of
$GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure
remotes.
2025/03/08(土) 12:22:24.00ID:kCgnTDtk0
githubで全然草生やせないんだけど
2025/03/09(日) 18:13:33.28ID:fe3LNf260
>>356
gitk 見ながら CLI 操作ってのが個人的には最強
2025/03/11(火) 10:16:27.19ID:gbyV8IdY0
Git v2.49.0-rc2
2025/03/15(土) 12:09:57.15ID:PGLL/72K0
Git v2.49.0
2025/04/08(火) 16:01:12.91ID:3wE3gtcN0
「Git」誕生から20周年を記念してリーナス・トーバルズ氏が開発初期の裏事情や使用頻度の高いコマンドなどを明かす
https://gigazine.net/news/20250408-git-20-years-linus-torvalds/
2025/04/09(水) 16:03:54.93ID:IrWwI/nb0
複数ファイル名を入力するときはGUIでポチポチ選択したい
2025/04/18(金) 20:54:17.74ID:pzk2UeIY0
10日で開発したL・トーバルズ氏も想定外？--「Git」誕生から20年、定番VCSの軌跡とその影響
ps://japan.zdnet.com/article/35231917/
409デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8f-utm5)
垢版 |
2025/04/27(日) 17:55:28.09ID:sTr1luuSM
このスレッドはLinux開発のGitの世界を語りだす気持ち悪い人間がいるから困る
2025/05/15(木) 13:14:12.18ID:UmAf9vRJ0
最新版で行ったバグ修正の部分だけを旧バージョンにも適用したい場合、チェリーピックを行うことになりますか？
その場合、ログの樹形図には、このコミットを持ってきたよという線は作られずに、別々の作業という表現になってしまいますか？
2025/05/15(木) 13:54:33.66ID:F0izL13m0
>>410
それであってるよ

直接 cherry-pick せずにバグ修正だけ入ったブランチを作ってそっちをマージという形にするやり方も一応あるけど大した違いはない
系統樹にはならないのでコミットログにどこから cherry-pick したかを残しておく（変なオプション使わなければ勝手に残るよ）
2025/05/15(木) 17:08:27.77ID:UmAf9vRJ0
>>411
ありがとうございます
旧バージョンのこういうメンテナンスは、チェリーピックを使っていくことになるのですね
2025/05/15(木) 17:42:53.69ID:F0izL13m0
>>412
親子関係にない（できない）間でのパッチの流用は cherry-pick でやるのが基本
git のコードの移動は（特殊なの除くと）merge, rebase, cherry-pick の3つだけ
逆に言うと cherry-pick は最重要3役のひとつ
2025/05/15(木) 18:00:11.34ID:eepuMYHW0
rebaseってcherry-pickの繰り返しと同じじゃねーの？
2025/05/15(木) 20:13:23.49ID:F0izL13m0
>>414
似てるけど違うよ、オプションにもよるけど
●rebase は今いるブランチを移動させる
○cherry-pick はよそのブランチからコピーしてくる
コピーとムーブの違い、方向も逆なので注意
あと cherry-pick も範囲指定で複数一度にコピーできるよ
2025/05/15(木) 20:20:09.57ID:eepuMYHW0
>>415
rebaseしても元のコミットは残ってるからmoveじゃないし
2025/05/15(木) 20:35:51.71ID:F0izL13m0
>>416
何言ってるわからん
ブランチを移動させたらもとのブランチはなくなる（ブランチに所属しなくなったコミットは後からガベコレで消される）
もちろん別の名前でブランチが残っていればそっちは移動してないのでコミットは消されない
2025/05/15(木) 21:36:14.90ID:eepuMYHW0
>>417
gitにコミットのmoveなんて概念ないでしょってこと
2025/05/15(木) 21:39:50.81ID:F0izL13m0
>>418
概念はある
実装が移動先にコピーして後から削除になってるだけ（主に undo 用にしばらく残してる
2025/05/15(木) 21:48:52.03ID:6KG6JIoe0
mergeもcherry-pickもrebaseも普通に新しいコミットを作る
そのコミットの作り方がユースケースに応じて3種類あるってだけのこと
421デフォルトの名無しさん (ﾜｯﾁｮｲ 7f63-3auX)
垢版 |
2025/05/15(木) 22:25:09.18ID:AuSI2AJ/0
>>414
同じだよ
2025/05/15(木) 22:42:29.15ID:eepuMYHW0
>>419
だからハッシュ番号変わるんだからmoveじゃないって
自分でも元が残ってるって言ってんじゃん
その理解大丈夫？
2025/05/15(木) 23:05:28.17ID:F0izL13m0
>>422
コンピュータ技術ではコピーして元のを消すのもムーブいうんだよ IDとかアドレスが変わってもムーブって呼ぶの
知らなかったの？ 勉強になって良かったな
2025/05/16(金) 00:59:49.81ID:9SpA05Ma0
円錐を横から見た人が三角だといい下から見た人が丸だというような構図ですね
人は争いをやめられないので滅ぼすしかないですね
2025/05/16(金) 01:36:29.34ID:b2vWvm610
>>423
そもそもコピーじゃないからな
コミットの内容は元とは完全に別物であり、差分だけが再現されている
勉強になって良かったな
2025/05/16(金) 08:05:25.71ID:D2sZkK900
>>425
幼稚園児か？
完全一致じゃないとコピーじゃないとか言いだしたらファイルコピーとかも所有者とか日付とかいろいろ変わるのコピーじゃなくなるぞ
git のは日付とか作者は変わらないのでまだ保存性高いぞ

cherry-pick と rebase が一緒なんて恥ずかしいこと言ったの話をそらしてごまかしたいんだろうけど無理がありすぎる
cherry-pick は元のが消えない、rebase は元のが消える、方向も逆、べつもの、あきらめろ
2025/05/16(金) 09:43:07.63ID:L+lmGGRS0
>>426
分かって言ってるのかどうか知らないけど、日付が変わるとかのレベルじゃなく、そもそも差分箇所以外は原理上全くの別物よ
変更内容のムーブというならまだしもコミットのムーブは流石に意味不明
2025/05/16(金) 10:35:41.49ID:D2sZkK900
>>427
誤魔化すな rebase と cherry-pick は別物、元が消える(ムーブ)のと、消えない(コピー)の違い
ここで言ってるのは元が消えるかどうか、完全一致とかの話題ではない
2025/05/16(金) 10:46:52.99ID:FmZiuEdw0
rebaseで元は消えないでしょおじいちゃん
2025/05/16(金) 10:57:16.90ID:D2sZkK900
>>429
もしかして誤魔化してるじゃなくて本当に分かってないの？ マジ？
431デフォルトの名無しさん (ｽｯﾌﾟ Sd1f-/14X)
垢版 |
2025/05/16(金) 10:59:28.32ID:iN5covy8d
まあ公式が同じだって言ってるしなあ
2025/05/16(金) 11:09:39.47ID:D2sZkK900
0┳A━B
┗X━Y
を
0━A━B━X━Y
にする時に使うのが rebase
0┳A━B━X━Y
┗X━Y
にする時に使うのが cherry-pick
基本中の基本
2025/05/16(金) 11:30:53.42ID:9SpA05Ma0
いやどう考えてもそのレベルの話は全員わかってるやろ
この一連のやり取りに足りないのは知識でもIQでもなくEQ
お前ら小学生からリベースしろ
2025/05/16(金) 11:33:59.63ID:epkpTq3tM
>>430
rebaseはcherry-pickで新しいコミットが作られてそっちに単なるポインタであるブランチが移動したのと同等
コミット消すとか移動とかいう動作は含まれない
どこからも参照されなくなったらいずれgcで消えるってだけ
435デフォルトの名無しさん (ﾜｯﾁｮｲ ffd6-Zxmy)
垢版 |
2025/05/16(金) 13:50:52.44ID:BDyQbzP90
英語が下手でコミットメッセージを書くのが苦手だったんだけど、AIで自動化したら快適になったぜ
2025/05/16(金) 14:44:19.53ID:x3RHmTCL0
>>435
そうなるともう、ログなんか書かなくていいんじゃないのとなってくるな
2025/05/16(金) 14:58:50.14ID:D2sZkK900
>>434
cherry-pick と rebase は別物って納得したんだな
2025/05/16(金) 15:09:24.62ID:D2sZkK900
rebase の内部動作の話するんなら
1. 分岐点を自動で探し出す
2. 分岐点からヘッドまでを対象の場所へ cherry-pick する
3. 元の場所のブランチ名を消す
4. 新しい場所にブランチ名をつける
5. ガベコレで古いブランチのコミットが消える
これを cherry-pick を繰り返すのと同じだと主張してる時点で何も分かってない
2025/05/16(金) 15:11:49.54ID:FmZiuEdw0
moveなんてアホな説明しなけりゃよかったのにね
2025/05/16(金) 15:18:53.26ID:D2sZkK900
>>439
移動してるだろ 432 見たら一目瞭然
コレが基本概念
内部実装の話しして誤魔化そうとしてても、お前が間抜けなこと言った時事は消えない
2025/05/16(金) 16:07:30.58ID:Jf7EmrNva
>>435
英語で直感的にヤバい時のメッセージに気付く訓練もいるから、AIは使えばいいけど読み書きの練習はしておけよ、と思った。
442デフォルトの名無しさん (ﾜｯﾁｮｲ 7fc2-3auX)
垢版 |
2025/05/16(金) 18:15:56.05ID:Mw5Je42+0
とりあえずDt80は一度公式読んできなよ
たかが間違って覚えてたところで誰も煽りやしないよ
あと描いてたツリーで、XだのYだのをリベースなりチェリーピックなりしたやつはXダッシュとかYダッシュとかにしよう
そこだけ流石に同じ文字じゃ読んでてちょっと気持ち悪すぎる
2025/05/16(金) 18:36:45.50ID:D2sZkK900
>>442
今でも「rebase は cherry-pick を繰り返しただけ」と主張してるの？
そんな覚え違いしてるのお前だけだろ、この通りの文言があったらポインタ示してみろ

どっかの変なサイトが誤訳してるのなら知らんが rebase は cherry-pick してるだけじゃないことはお前も完全に理解できてるだろ
444デフォルトの名無しさん (ｽｯﾌﾟ Sd1f-/14X)
垢版 |
2025/05/16(金) 21:29:57.00ID:iN5covy8d
このページのgit rebaseの項に書いてあるよ
https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Patching
2025/05/16(金) 23:12:54.87ID:D2sZkK900
>>444

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

エスパーしてみると
違うからこそ basically ってわざわざ明確に書かれてるに、もしかして basically て単語知らなかったとか？
native のつかうbasically は「基本部分では、だいたいにおいて」みたいなニュアンスで、本当に同じ時には使わない
「だいたい同じ」を「同じ」って覚えてたんじゃないの？
2025/05/16(金) 23:28:45.03ID:CtDSSAzzH
>>445
さすがに苦しいぞ
2025/05/16(金) 23:33:35.97ID:D2sZkK900
>>446
でどう訳したの？
2025/05/17(土) 08:56:34.42ID:TogutASM0
方向の違いとかコピーとムーブの違いが「同じ」と「だいたい同じ」の違いというわけか。
2025/05/17(土) 09:18:39.88ID:S33C25YC0
間違いを絶対認めたくないマン
公式まで否定
2025/05/17(土) 17:33:51.01ID:t4AM4T1l0
>>449
あー、どう訳したか説明しないとこ見るとエスパーが図星なのか
公式が初心者向けに「ほぼ同じです、でもこういう点が違います。詳しい説明はこちらって」って書いてるのの最初のとこだけ見て「ほぼ」も見ないで、後に続く説明もリンク先の詳細も無視して同じって言い張ってただけか
それはお前の読解力が足りてないだけ、公式のせいじゃないぞ
451デフォルトの名無しさん (ﾜｯﾁｮｲ 7f5e-3auX)
垢版 |
2025/05/17(土) 17:48:34.70ID:C8ddlcHs0
>>450
訳というかそもそもそのドキュメントは色んな言語版が用意されてて日本語のものもあるよ
訳が気になるなら読んでみよう
2025/05/17(土) 18:11:19.00ID:t4AM4T1l0
>>451
誤魔化してないで「お前が」同じだと主張する部分を説明してみろ
少なくともリンク先の英語の初心者向けの紹介には書いてないぞ
本当に同じならお前が cherry-pick で rebase 実装してみろ、そうすればみんな納得するだろう、技術者なら実際にやれば同じか別物か分かるだろう
git のソースコード読んだことないやつには想像もつかんだろうが rebase はかなり複雑なことをやってる、初心者向けのページすらまともに読み解けないお前には最初の1歩目の分岐点を探し出す作業ですら絶対に無理と予言しよう
2025/05/17(土) 20:46:35.58ID:S33C25YC0
そこで何か違うか端的に説明できたらよかったねおじいちゃん
何がmoveしてんですかぁ？
commitじゃなくてbranchのことですかぁ？
じゃcopyってどうゆうことですかぁ？
2025/05/17(土) 23:11:17.26ID:t4AM4T1l0
>>453
話逸らさずに同じとういうことを証明してみろ
細かい事いえば山程違いがあるけど、違うというのは 432 で素人にも一目瞭然なのに覆せるわけないだろう
間違えた恥ずかしい事実はごまかせないぞ
2025/05/17(土) 23:17:53.88ID:pDSuIsUc0
違いがあるというなら、あなたがコミットのコピー/ムーブと呼ぶものはどちらも実際には全く異なるコミットを作り出すでしょう
そういうのをダブスタという
2025/05/18(日) 00:30:50.11ID:t1q8u3yl0
>>455
読解力ないの日本語のなんだな
2025/05/18(日) 03:09:09.55ID:G2loPi6x0
なんて？
2025/05/19(月) 09:09:53.56ID:E91ALV1Y0
>>432
XY両方ではなく、XやYのみを取り込むのがcherry-pickというイメージだが
2025/05/19(月) 21:35:49.68ID:LwAOa5bv0
>>458
普通の範囲指定が効くので
その図なら git cherry-pick ..Y みたいに指定すれば X と Y の両方 cherry-pick できるよ
2025/05/20(火) 08:32:54.32ID:IobDhVYO0
会話が噛み合わないコントみたいなスレで草
みんな文意文脈にももっと気を配ろうぜ
2025/05/20(火) 15:48:18.98ID:iWs/HqBfa
「エクスプローラー」の「Git」統合などが実現へ ～Microsoftが開発者向け新機能
ps://forest.watch.impress.co.jp/docs/news/2015419.html
2025/05/20(火) 16:58:09.70ID:lxraH8Xn0
亀の出番がなくなるのか？
2025/05/21(水) 08:05:21.38ID:oZBirtTV0
エクスプローラーなんて、Windows7のときに使わなくなったな
2025/05/21(水) 10:18:53.96ID:va6/rMbaa
MSアカウントにログインしないとExoplorer使えないとか
もうWindows要らんな
2025/05/25(日) 03:59:20.13ID:5SaResX20
わざわざExplorerからコミットとかプッシュする奴おるんかw
2025/05/25(日) 07:06:19.26ID:EfROU4yga
OSのSystem領域も含めて全部がリモートリポジトリの運用かな。
2025/05/25(日) 08:49:46.44ID:JDhr0Ivk0
>>465
申し訳ありません、今でもTortoiseGitでやってます
2025/05/25(日) 09:13:50.01ID:TXvAFiBF0
Windowsだと、手取り足取り指示してあげないと自分で何もできない「開発者」をExcel方眼紙の手順書で「プログラミング」してあげるような仕事も多いから、
そういう場合に「開発者」の手元にいちいちGitクライアントを導入させるという頭悪い手順を記載する必要がなくなるなら便利かもしれない
2025/05/29(木) 02:32:23.75ID:oHIdrLSz0
Git v2.50.0-rc0
2025/06/04(水) 13:13:31.34ID:nhmcxHVz0
Git v2.50.0-rc1
471デフォルトの名無しさん (ｽｯｯﾌﾟ Sda2-in7m)
垢版 |
2025/06/06(金) 01:08:14.98ID:45aWa19td
gitもはや20年か
2025/06/07(土) 08:05:32.65ID:tgCEw1aU0
gitアレルギー
2025/06/10(火) 09:49:47.00ID:DFb9gzxN0
Git v2.50.0-rc2
2025/06/17(火) 08:04:33.42ID:JQTnqwjt0
Git v2.50.0
2025/06/18(水) 00:48:41.95ID:zWpFFB0D0
オススメのgitクライアント教えて
source treeはなんかuiの一つ一つがデカくて肌に合わなかった
2025/06/18(水) 02:39:03.14ID:QsB71xf70
自分はlazygitとVSCodeだな
2025/06/18(水) 08:16:55.75ID:6RiwAFGc0
うちではSourceTreeというやつを使ってるよ
2025/06/18(水) 09:02:23.67ID:7Ghn3yO50
使いにくいやつね
2025/06/18(水) 18:04:24.45ID:c2eS9NyS0
lazygitかSourcetreeだな。
2025/06/19(木) 20:10:05.29ID:dNWjhAfr0
わかばちゃんの中の人
ps://x.com/llminatoll/status/1935310637196095988?t=KJizsM3DHuYlJSyTCzcZcg&s=19
2025/06/21(土) 23:55:27.59ID:Rsg0aBc50
VSCodeの拡張機能で提供されてる Git Graphが 使いやすいね
2025/06/22(日) 00:39:02.97ID:L6Wg3CMhM
あれいいよね、見やすい
ハッシュ手打ちの人がんばってw
2025/06/22(日) 06:56:54.23ID:APGUbecj0
CUI でもハッシュを手打ちすることなんてほぼないだろ
ブランチもタグも検索も使ってないんだろうか？
2025/06/22(日) 18:51:38.68ID:4jZfNTw30
>>481
んー

でも、他のGitクライアントも似たもんじゃないの？
2025/06/23(月) 11:27:58.47ID:KosRMA640
似たような、がどの辺を指してるかにもよる。
rebaseかstash簡単にしたい、tag打ちたい、ブランチ作りたいならだいたいどれでも出来る。
　ただ現場で初心者多くて教育面倒だし日本語じゃなきゃだめとかいうなら、SourceTreeか
非公式多言語版GitHub Desktopしかないと思う。
2025/06/23(月) 12:06:20.95ID:9uUr9jSA0
>>485
で、ベストは？
英語でも有料でも、なんでもいいので
2025/06/23(月) 12:11:55.90ID:qqxmiRlS0
interactiveなrebaseをサポートできてないやつ多いでしょ
2025/06/23(月) 17:00:15.66ID:KosRMA640
基本は好きなの使えばいいよ。
対面レビューで追加コミット後に「レビューOKだからコミットひとつにまとめといて」って言われたり
「ウチは協力会社に外資いるから日本語コメントだめなんだ、英語にしといて」って言われない限り
rebase(やsquash)やamend使うこともないだろうし。
2025/06/23(月) 18:37:21.89ID:MPl++Mur0
いや rebase -i も --amend も使いまくりだろ
何なら一番多く使うコマンドまでありえる
一発で完璧な記録できて後は触らないみたいな超人じゃなきゃ、普通に多用するだろ
2025/06/23(月) 19:49:45.04ID:Z8z+4HFt0
といっても元のコミットがある程度ちゃんと作られてることが前提じゃない？
単に作業のチェックポイントとして気軽にコミットしてると、いざコードレビュー前に整理しようとしたときには元のコミットを無理に再利用するより
resetして作り直した方が早いことが個人的には多い
書いてて思ったけど、元のコミットがすでに整理されている上で修正を入れる状況としては、コードレビューの中での修正があるね
もしチームのポリシーとして瑣末な指摘反映をログに残さないことにしているなら、レビュー後マージ前にrebase -iするのは便利かもしれない
2025/06/23(月) 21:20:02.74ID:MPl++Mur0
そっちじゃなくて手元で色々作り散らかしたコミット履歴を綺麗に読み易く整理してから、レビューに出す。
順番入れ替えたり、コミットメッセージを分かり易くしたり、不要な履歴を消したり、コミットを意味に合わせて分割したり、統合したり
その整理に活躍するコマンドが rebase -i、慣れると手放せない

読み易く整理されてれば他人の時間の節約になる、試行錯誤とかタイポ修正とかの痕跡を他人に見せて時間を奪わなくてすむ
2025/06/23(月) 22:25:23.37ID:YcF93ZoT0
そんなの方法を議論する以前にもうAIにやらせたらいいんじゃないかという気もするが、
AIにやらせるならやっぱり一連のgitコマンドを直接生成させるのがいいのかなあ
コマンドだと人間が実行前にレビューするのは辛いものがあるから、diff入りのコミットログみたいな形式で生成させて、resetした上でそれを反映するのがいいと思うんだけど
2025/06/24(火) 07:59:57.08ID:oSvYVpQb0
>>492
AI に期待し杉
今のAIはしょせん賢い検索エンジンに過ぎない
学習したことの最も多数派の意見をそれらしく繋ぎ合わせてるに過ぎない
素人が玄人の作業を真似るのには使えるけど、玄人の創造的作業の代替は無理
2025/06/24(火) 08:31:50.93ID:1VpUD11F0
>>491
プロトタイプであれやこれやするなら、さらにブランチ作って動くようになったら新しいブランチに
Squash and Mergeして、そっちのブランチをレビュー対象にした方が楽なんじゃ？
2025/06/24(火) 10:30:20.42ID:oSvYVpQb0
>>494
いやだから、色々なブランチに順不同で入ってるやつの共通部分を括りだして独立したコミットにしたり、一つのコミットを内容に合わせて複数に分割したり、ばらばらのを分かり易く統合したり
やるべきこっとはいっぱいあるだろ
merge も squash も amend も全部 rebase -i を使ってやる、rebase -i を何だと思ってるんだ？
2025/06/26(木) 10:59:58.77ID:JcQLzuh60
amendやsquashを一般人が簡単にやりたいならGitHub Desktopの履歴のとこから出来るけど
使用説明が一切ないんだよなあ。圧倒的なドキュメント不足。
2025/06/26(木) 12:02:10.03ID:3juiMOaqM
>>495
アトミックに細かくコミットする人ならrebase -iでの整理は容易だろうけど、分割が多い場合は面倒臭すぎるでしょ
resetしてやり直した方が早いわ
2025/06/26(木) 14:45:21.20ID:rhHx6Nng0
>>497
意味分からん
「細かくコミット」と「分割が多い」は同じじゃないの？ お前の用語での違いは何？

コミットを統合したり分割したりするのも rebase -i から始めるのに？
いくらでも変えられるのに何が問題なの？
2025/06/26(木) 17:51:44.27ID:JcQLzuh60
「細かくコミット」がバックアップ保証のつもり(で修正が動くかどうかも分からん)なら、
都度commitだけしといてpushは待っとけばいいんじゃないかなと思ったり。
2025/06/27(金) 10:30:24.43ID:KAeTyQMQ0
当たり前だろ
動作確認できてないものpushすんなよ
2025/06/27(金) 10:39:46.35ID:iePZ28tO0
>>500
どこに push するか次第だよな

共有リポジトリや公開リポジトリに push しちゃ駄目だろうけど個人のバックアップ・リポジトリとかに push しとくのは自由
リポジトリやブランチを好きなだけ作れて高速に同期できるのが git の利点なんで限られた少数のリポジトリしか使わないのはもったいない
2025/06/27(金) 10:46:55.51ID:Vbo+wzUI0
GitHubでのチーム開発だと普通に共有リポジトリにpushするけどな。
ただしpush先はいわゆるfeatureブランチなど、そのタスク専用のブランチ。
draft pull requestを作っておいて他人から容易に目に見えるようにするとなお良い。
むしろ手元で長いこと留めてあいつ何やってんだろと思ったら突然クソデカpull request投げてくるような奴は嫌われるよ。まあ開発に限った話ではないが。
2025/06/27(金) 14:47:42.22ID:iePZ28tO0
>>502
その辺はチームの方針次第だね
リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか
マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う（個人の意見
2025/06/27(金) 15:24:34.92ID:caL9+2zdM
>>503
本題からは逸れるんだが、企業での開発で個人リポジトリにforkする運用ってなんかメリットあるのかな？
自分はこれまで共有リポジトリ運用しか見たことがない
なお、新卒がいきなりforkして怒られてるのは何度か見た
forkして複数の共有リポジトリを使うのは複数の会社がいてそれぞれガバナンスが違うケースなんかで珍しくないけど
2025/06/27(金) 17:03:03.14ID:iePZ28tO0
>>504
github みたいに fork って呼ぶから混乱するんじゃないかな？ オープンソースじゃないから単なる clone だろ
開発用の clone はいくつあっても良い、個人用でもデスクトップとノートPCとサーバと複数の場所にリポジトリもってて定期的に同期させたりしながら、移動中とか自宅とか会議中(笑)に開発したりできる
もちろん会社の情報統制や社外秘情報の漏出防止のためにコピー禁止とか部屋外に持ち出し禁止とか決まりあれば従わないと駄目だが
2025/06/28(土) 00:10:08.26ID:Nhn9wgjX0
Gitむずかしい…
Pythonよりむずかしい…
2025/06/28(土) 11:34:58.63ID:WNSkpT1F0
雑にpushするブランチを作ってあるので
ホイホイプッシュしてる
2025/06/28(土) 14:23:18.12ID:ps+a9/JT0
いやPythonの方が難しいでしょ
2025/06/28(土) 15:15:53.19ID:Nhn9wgjX0
初心者なんですが、
branch1とbranch2があって、
branch1にcheckout後に、>git merge branch2　と、
branch2にcheckout後に、>git merge branch1　って、
結果は同じ？
2025/06/28(土) 15:31:34.65ID:XJ1OnLan0
>>509
ソースコードの内容は同じになる
ログは違う形になる
ログはどのようにソースを扱ってきたかの履歴書や歴史書のようなものなので複雑で大規模なプロジェクトほど価値が出る
2025/06/28(土) 15:47:58.18ID:Nhn9wgjX0
>>510
あ、
今やってみましたが、
mergeコマンド実行するときの自分がいるブランチのほうが、引き続き残るって感じですかね？
2025/06/28(土) 16:06:18.63ID:XJ1OnLan0
>>511
ブランチ自体はどちらも残る
自分がいる方のブランチはマージ結果を指す形で歴史が一方進む
そうじゃない方のブランチはありのまま残る
2025/06/28(土) 17:09:16.02ID:GU5N/G5Q0
「自分が今いるブランチに指定したブランチの「内容」を混ぜ（merge）する」というのがコマンドの意味

当然
・今いるブランチは書き換わってコミットが進む
・指定したブランチには変化なし
2025/06/28(土) 18:17:50.37ID:Nhn9wgjX0
>>512
あ、
自分がいたほうじゃない方のブランチは、
branch3とかにつなげられますね…
2025/06/28(土) 18:19:22.53ID:Nhn9wgjX0
>>513
ですね

わからない理由は、日本語のまともな解説が無いからですね…
海外の解説で、ようやく理解できました…
516デフォルトの名無しさん (ﾜｯﾁｮｲ 6224-Ieqc)
垢版 |
2025/07/01(火) 20:11:53.56ID:HVBtOzc60
混じるからマージる
2025/07/01(火) 22:46:34.19ID:BgB6BrdO0
去年のリリースの記憶をタグる
2025/07/02(水) 21:57:57.01ID:xYSFlqIW0
頭悪い人って自分が理解できないのを説明する人のせいにしがちだよね
説明が悪いならなんでお前以外の人は理解できてるのかと
2025/07/03(木) 03:33:50.65ID:ZlHu/VzU0
能力不足故に検索の仕方や聞き方が下手で自らが望む解説に効率的にアクセスできない
ダニングクルーガー効果のような認知バイアス
元から他責的、依存的なせいで残り少しの努力を怠り多方面で理解不足に陥りがち
この中のどれかか、複合要因ではないかな
2025/07/05(土) 16:41:53.58ID:Jt1MZnHo0
>>518
それは、
運良くいい説明を見れたからでしょ

お前には無理そうだが
2025/07/05(土) 17:28:57.77ID:99i/fp2o0
大丈夫だよ
プログラム書いたらビッとコミットしてギュッとプッシュしてギャンよ
522デフォルトの名無しさん (ﾜｯﾁｮｲ 9f91-oWNB)
垢版 |
2025/07/06(日) 09:39:11.50ID:AHvPqc/80
コミッとコミットする
2025/07/09(水) 16:29:53.53ID:NiP9rW7K0
Git v2.50.1
2025/07/09(水) 20:54:58.43ID:5nTmkCkK0
初心者の質問ですが、
Linux（サーバー的なもの）に、GitHubのレポジトリをクローンして来て、
それをWindowsパソコンからSSH接続して、
Gitの履歴の図（Gitグラフ？）って見る方法ありますか？
525デフォルトの名無しさん (ﾜｯﾁｮｲ 9f85-NzCA)
垢版 |
2025/07/09(水) 22:47:25.77ID:OQriWW8/0
ありますね
2025/07/10(木) 12:47:26.79ID:+1gidKVl0
>>525
会話を広げる癖をつけろ童貞
2025/07/10(木) 20:49:27.62ID:tN4eS5FO0
>>526
なら会話広げればいいじゃん。
2025/07/13(日) 17:29:18.40ID:QlUonva10
>>524
sshで git log --graph で履歴取ってきて、mermaid変換してmarkdown埋め込みにすればいいんじゃね？
2025/08/06(水) 12:13:19.02ID:48BfQKJO0
>>526
あると信じて検索すれば報われますよというありがたい情報だぞ
2025/08/13(水) 06:18:19.45ID:YOB+IZc5r
やりますね
2025/10/22(水) 09:23:57.49ID:pnMMn99c0
https://forest.watch.impress.co.jp/docs/news/2056148.html
次のバージョンからgit svnが廃止されると書いてあるけど、
これはSubversionからの変換もできなくなるということでしょうか
532デフォルトの名無しさん (ﾜｯﾁｮｲ 1abb-Telw)
垢版 |
2025/10/22(水) 13:20:45.27ID:2nDvyZJf0
Git for Windowsの次回メジャーリリースでの話をしてるならそうだよ
旧バージョンや本家を使うとか、svn2gitだとか別VCS経由とか手作業での移行だとかは出来るでしょう
2025/10/22(水) 13:52:16.21ID:Nfi7SE1t0
もうシンプルに使われてる機能だけをブラッシュアップすればいい思う。
互換性とか古いものをメンテし続けるのは大変だよ。
534デフォルトの名無しさん (ｱｳｱｳｳｰ Sa09-6N1s)
垢版 |
2025/10/24(金) 14:37:23.45ID:nAYKU6CIa
いまだに新規プロジェクトでSubversionからっていうのはもう洗脳されてるから放置で良いし
Subversionから変換する気があるならもうとっくにやってるだろうし
2025/10/24(金) 15:02:05.38ID:ZcyI5XOE0
Windowsユーザーだと、業務でSVNを使わざるを得ないがGitコマンド経由で使うことで辛うじて自己の尊厳を保っていた人もいそうだな
電車止まりそう
2025/10/24(金) 18:33:25.65ID:J3E6mCG+0
>>535
そんなプロジェクトやだなぁ
2025/10/24(金) 20:17:02.32ID:NslM5AvMr
令和なのにまだSVNで消耗してる人いるんだ
絶滅危惧種かな
2025/10/24(金) 23:30:36.26ID:vJAYr0tv0
>>535
Gitって、開発速度は遅くなるよね
コードレビューとか丁寧にやると遅くなるよね…
2025/10/25(土) 00:27:30.86ID:a9lDbV800
>>538
規模（参加人数、開発期間、コードサイズ）次第。大きくなれば git 使った方が早い
2025/10/25(土) 04:23:36.31ID:kofX/eP60
>>538
gitだからコードレビューが必要って認識？
アホじゃね？
2025/10/25(土) 08:42:34.81ID:/eT+OdROH
SVNと比較しての話なら、Gitはコミットやブランチの操作が遥かに軽量だからこそ、
チームが必要以上に面倒なワークフローを作り込みがちな面があることは否定できないな
非機能要件でちゃんとバージョン管理しろと書かれているからという理由だけでVCS使ってるような典型的な業務系でSVN使い続けてるようなとこだと、
レビュー済みまたはリリース済みのコードをコミットするだけみたいな運用は珍しくないからな
そういった意味で、VCSの運用という点だけ見ればGitの方が複雑になる傾向があるとは思う
2025/10/25(土) 12:06:31.87ID:lNU8C84m0
>>539
まあ、
大規模だと、ちゃんと管理が必要ですね…
2025/10/25(土) 14:26:57.22ID:H78EacVr0
>>538
御社はコードレビューまともにやらんのですか？
2025/10/28(火) 13:00:39.46ID:4N3qsL5c0
>>543
それGitに関係あるって話だと思う。
Pull requestのことを言ってるのならGithubとかの話だし。
2025/10/28(火) 15:19:39.06ID:/5MDlnTO0
>>544
その辺はまちまちだろう
コードレビューの仕組みに git を組み込んでる所もあれば別の方法を取っているところもある
コードレビューの結果を git に格納している所もあれば別の仕組みで管理してるとこもある
別の仕組みで管理していても git にコミットしたら自動的にレビューやテストに連携する仕掛けを作ってるところもある

作成したコードをいったん git に入れて git に差分を出力させて、それをメールで送ってレビューやってるOSのカーネルもある
2025/10/30(木) 02:49:22.78ID:q+RoJBty0
これまで数社で目撃した光景だけどsvnからgitへの移行にはどこも苦労してた
当然gitなんて触ったことないメンバーが移行なんて上手くできないから、中途組やBPでやることになり負荷が集中
運用フローも現行の運用を把握したうえでの整備になり、ヒアリングも苦戦

何より、移行するメリットをみんなが納得してくれなくて進まないこともあった
最近だとgithub copilotのおかげで移行するメリットは説明しやすくなったと思うけど
2025/10/30(木) 13:33:16.77ID:JnQiXLC30
移行できないのは無能のおっさんだけだけとな
若い奴らは学校で使ってたし、できるやつは仕事以外などで当然git使った経験ある
2025/10/30(木) 15:54:37.40ID:zX8qdRgz0
まあ苦労を愚痴るくらいはいいだろう
けど一度両方に使い慣れるとソース管理でSVNを選ぼうとする人間はほぼいなくなる
心理的ハードルの高さを理由に未だに挑戦すらできないのは自身の経験からしか学べない愚か者か情弱か、周囲が低スキルの作業者しかいない色々諦めてる人かなと思う
2025/10/30(木) 16:29:49.89ID:c0k0xQOf0
何をしたいかによるな
ちゃんと手間暇かけて記録を残して共有したいのなら git は素晴らしい
某バケツくんのようにバックアップ取りたいだけなら svn でも過剰機能
2025/10/30(木) 17:05:22.68ID:W1lion0Ta
某バケツ/長文くん...
GitHab 他で、外部のホスティングサービスを使うのが普通になるなんて10年前には、中々考えにくかったね。
Git の力は凄いね。
2025/11/03(月) 13:15:47.38ID:r5+FjR750
オンプレや望むならローカルでもGitLabのCE版やGitBucket使えば出来るけどなあ。
VisualSVNほどお手軽ではないけど。
552デフォルトの名無しさん (ﾌﾞｰｲﾓ MM9f-Xz0w)
垢版 |
2025/11/13(木) 20:41:16.25ID:Qom0QzkiM
Gitはいろんな使い方ができてしまうことがあだとなってしまっている。
2025/11/13(木) 20:48:42.86ID:PKGW+vLo0
Gitって、
Pullして自動でソースコードをマージってできないの？
2025/11/13(木) 23:03:52.93ID:VOpdlSZF0
>>553
pull って単に「fetch して merge 」の省略形なので当然 merge されるが
何を聞きたい？
2025/11/15(土) 07:14:55.95ID:WbeS5X/70
マージ・シンプソン
2025/11/16(日) 09:33:15.00ID:FZVYRGsX0
ブランチやFork切ったやつを本流にPR通さず自動的にマージしたいってことかな。
答えは「できない以前に絶対にやるな」だけど。
557デフォルトの名無しさん (ﾜｯﾁｮｲ 3d5f-PGJ3)
垢版 |
2025/11/16(日) 10:11:35.18ID:yrwB7Ga/0
Excelファイルで更新し合ってケンカになるタイプだろ
558デフォルトの名無しさん (ｱｳｱｳｳｰ Sa85-H7iN)
垢版 |
2025/11/16(日) 13:13:38.57ID:0LN83zrSa
.xls .xlsm .xlsx は .gitignore すべし
2025/11/16(日) 13:48:39.22ID:aNRf2eDa0
>>556
puah は他リポジトリへのマージなので push 権限もってれば普通にできるが
何がしたいの？
2025/11/16(日) 13:54:18.17ID:aNRf2eDa0
git は色々柔軟な使い方ができるんだが
質問するやつも回答するやつ自分の使い方限定で詳細言わずにやり取りするせいで
何をしたいかさっぱり
2025/11/16(日) 20:37:45.50ID:22RS930U0
質問してるやつも戻ってこないし本気で解決する気ないんだろ
ほっとけ
562デフォルトの名無しさん (ﾜｯﾁｮｲ 22bc-RaAf)
垢版 |
2025/11/17(月) 20:05:10.72ID:2/K3mAIm0
>>554
ローカルに変更がある場合、
それを一回commitしてから、pullするとマージされるんですかね？
そのへんがわかりませんでした…
2025/11/17(月) 21:28:52.94ID:C8hBIp5w0
疑うぐらいなら自分の手元で試したらいいだろカス
2025/11/18(火) 02:15:32.71ID:85wp5LLm0
>>562
当然される。むしろそのためのコマンド
pull は remote のブランチを取ってきて local のブランチにマージするために使うのが基本
取ってくるだけなら fetch コマンドを使う
565デフォルトの名無しさん (ﾜｯﾁｮｲ 22eb-RaAf)
垢版 |
2025/11/18(火) 06:57:03.10ID:tB6cP1ph0
>>564
いや、そういう質問意図じゃなくて、
マージしたいけど、commitしないとマージできないんだなと…

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

現在の変更作業中のものをコミットせずに pull したい場合にはいったん stash に退避して pull した後に stash pop でワーキングツリーに再反映させるのが基本
567デフォルトの名無しさん (ﾜｯﾁｮｲ 02dc-A2v6)
垢版 |
2025/11/18(火) 09:45:22.80ID:9r4MKRAe0
マジ卍
2025/11/18(火) 11:21:49.31ID:z0Auw9920
>>565
先にコミットしないといけない理由はプルで競合したりミスを後悔したり後から気づいたときに変更が混ざってうまく戻せなくて詰むから
わざわざコミットが必要なのかと感じたならその考えが古い
Gitのコミットはプッシュするまでは単なるセーブポイントみたいなものでしかないのでコミット後に切ったり貼ったり戻したり自在にコントロールできる
リスクのある面倒事はセーブしてからやろうねという親切設計
569デフォルトの名無しさん (ﾜｯﾁｮｲ 2227-43h0)
垢版 |
2025/11/18(火) 12:43:24.98ID:ZK0HcEny0
分かるんだけど聞きたかったのは多分そういうことじゃないと思うよw
新着レスの表示
レスを投稿する

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