[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2ch.scのread.cgiへ]
Update time : 10/25 18:23 / Filesize : 168 KB / Number-of Response : 544
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 20



1 名前:デフォルトの名無しさん mailto:age [2024/02/15(木) 09:50:09.07 ID:En27mXas0.net]

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

Git
git-scm.com/

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

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
mevius.5ch.net/test/read.cgi/tech/1650651945/
Git 19
https://mevius.5ch.net/test/read.cgi/tech/1667720427/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

492 名前:デフォルトの名無しさん mailto:sage [2025/06/23(月) 21:20:02.74 ID:MPl++Mur0.net]
そっちじゃなくて手元で色々作り散らかしたコミット履歴を綺麗に読み易く整理してから、レビューに出す。
順番入れ替えたり、コミットメッセージを分かり易くしたり、不要な履歴を消したり、コミットを意味に合わせて分割したり、統合したり
その整理に活躍するコマンドが rebase -i、慣れると手放せない

読み易く整理されてれば他人の時間の節約になる、試行錯誤とかタイポ修正とかの痕跡を他人に見せて時間を奪わなくてすむ

493 名前:デフォルトの名無しさん mailto:sage [2025/06/23(月) 22:25:23.37 ID:YcF93ZoT0.net]
そんなの方法を議論する以前にもうAIにやらせたらいいんじゃないかという気もするが、
AIにやらせるならやっぱり一連のgitコマンドを直接生成させるのがいいのかなあ
コマンドだと人間が実行前にレビューするのは辛いものがあるから、diff入りのコミットログみたいな形式で生成させて、resetした上でそれを反映するのがいいと思うんだけど

494 名前:デフォルトの名無しさん mailto:sage [2025/06/24(火) 07:59:57.08 ID:oSvYVpQb0.net]
>>493
AI に期待し杉
今のAIはしょせん賢い検索エンジンに過ぎない
学習したことの最も多数派の意見をそれらしく繋ぎ合わせてるに過ぎない
素人が玄人の作業を真似るのには使えるけど、玄人の創造的作業の代替は無理

495 名前:デフォルトの名無しさん mailto:sage [2025/06/24(火) 08:31:50.93 ID:1VpUD11F0.net]
>>492
プロトタイプであれやこれやするなら、さらにブランチ作って動くようになったら新しいブランチに
Squash and Mergeして、そっちのブランチをレビュー対象にした方が楽なんじゃ?

496 名前:デフォルトの名無しさん mailto:sage [2025/06/24(火) 10:30:20.42 ID:oSvYVpQb0.net]
>>495
いやだから、色々なブランチに順不同で入ってるやつの共通部分を括りだして独立したコミットにしたり、一つのコミットを内容に合わせて複数に分割したり、ばらばらのを分かり易く統合したり
やるべきこっとはいっぱいあるだろ
merge も squash も amend も全部 rebase -i を使ってやる、rebase -i を何だと思ってるんだ?

497 名前:デフォルトの名無しさん mailto:sage [2025/06/26(木) 10:59:58.77 ID:JcQLzuh60.net]
amendやsquashを一般人が簡単にやりたいならGitHub Desktopの履歴のとこから出来るけど
使用説明が一切ないんだよなあ。圧倒的なドキュメント不足。

498 名前:デフォルトの名無しさん mailto:sage [2025/06/26(木) 12:02:10.03 ID:3juiMOaqM.net]
>>496
アトミックに細かくコミットする人ならrebase -iでの整理は容易だろうけど、分割が多い場合は面倒臭すぎるでしょ
resetしてやり直した方が早いわ

499 名前:デフォルトの名無しさん mailto:sage [2025/06/26(木) 14:45:21.20 ID:rhHx6Nng0.net]
>>498
意味分からん
「細かくコミット」と「分割が多い」は同じじゃないの? お前の用語での違いは何?

コミットを統合したり分割したりするのも rebase -i から始めるのに?
いくらでも変えられるのに何が問題なの?

500 名前:デフォルトの名無しさん mailto:sage [2025/06/26(木) 17:51:44.27 ID:JcQLzuh60.net]
「細かくコミット」がバックアップ保証のつもり(で修正が動くかどうかも分からん)なら、
都度commitだけしといてpushは待っとけばいいんじゃないかなと思ったり。



501 名前:デフォルトの名無しさん mailto:sage [2025/06/27(金) 10:30:24.43 ID:KAeTyQMQ0.net]
当たり前だろ
動作確認できてないものpushすんなよ

502 名前:デフォルトの名無しさん mailto:sage [2025/06/27(金) 10:39:46.35 ID:iePZ28tO0.net]
>>501
どこに push するか次第だよな

共有リポジトリや公開リポジトリに push しちゃ駄目だろうけど個人のバックアップ・リポジトリとかに push しとくのは自由
リポジトリやブランチを好きなだけ作れて高速に同期できるのが git の利点なんで限られた少数のリポジトリしか使わないのはもったいない

503 名前:デフォルトの名無しさん mailto:sage [2025/06/27(金) 10:46:55.51 ID:Vbo+wzUI0.net]
GitHubでのチーム開発だと普通に共有リポジトリにpushするけどな。
ただしpush先はいわゆるfeatureブランチなど、そのタスク専用のブランチ。
draft pull requestを作っておいて他人から容易に目に見えるようにするとなお良い。
むしろ手元で長いこと留めてあいつ何やってんだろと思ったら突然クソデカpull request投げてくるような奴は嫌われるよ。まあ開発に限った話ではないが。

504 名前:デフォルトの名無しさん mailto:sage [2025/06/27(金) 14:47:42.22 ID:iePZ28tO0.net]
>>503
その辺はチームの方針次第だね
リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか
マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う(個人の意見

505 名前:デフォルトの名無しさん mailto:sage [2025/06/27(金) 15:24:34.92 ID:caL9+2zdM.net]
>>504
本題からは逸れるんだが、企業での開発で個人リポジトリにforkする運用ってなんかメリットあるのかな?
自分はこれまで共有リポジトリ運用しか見たことがない
なお、新卒がいきなりforkして怒られてるのは何度か見た
forkして複数の共有リポジトリを使うのは複数の会社がいてそれぞれガバナンスが違うケースなんかで珍しくないけど

506 名前:デフォルトの名無しさん mailto:sage [2025/06/27(金) 17:03:03.14 ID:iePZ28tO0.net]
>>505
github みたいに fork って呼ぶから混乱するんじゃないかな? オープンソースじゃないから単なる clone だろ
開発用の clone はいくつあっても良い、個人用でもデスクトップとノートPCとサーバと複数の場所にリポジトリもってて定期的に同期させたりしながら、移動中とか自宅とか会議中(笑)に開発したりできる
もちろん会社の情報統制や社外秘情報の漏出防止のためにコピー禁止とか部屋外に持ち出し禁止とか決まりあれば従わないと駄目だが

507 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 00:10:08.26 ID:Nhn9wgjX0.net]
Gitむずかしい…
Pythonよりむずかしい…

508 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 11:34:58.63 ID:WNSkpT1F0.net]
雑にpushするブランチを作ってあるので
ホイホイプッシュしてる

509 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 14:23:18.12 ID:ps+a9/JT0.net]
いやPythonの方が難しいでしょ

510 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 15:15:53.19 ID:Nhn9wgjX0.net]
初心者なんですが、
branch1とbranch2があって、
branch1にcheckout後に、>git merge branch2 と、
branch2にcheckout後に、>git merge branch1 って、
結果は同じ?



511 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 15:31:34.65 ID:XJ1OnLan0.net]
>>510
ソースコードの内容は同じになる
ログは違う形になる
ログはどのようにソースを扱ってきたかの履歴書や歴史書のようなものなので複雑で大規模なプロジェクトほど価値が出る

512 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 15:47:58.18 ID:Nhn9wgjX0.net]
>>511
あ、
今やってみましたが、
mergeコマンド実行するときの自分がいるブランチのほうが、引き続き残るって感じですかね?

513 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 16:06:18.63 ID:XJ1OnLan0.net]
>>512
ブランチ自体はどちらも残る
自分がいる方のブランチはマージ結果を指す形で歴史が一方進む
そうじゃない方のブランチはありのまま残る

514 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 17:09:16.02 ID:GU5N/G5Q0.net]
「自分が今いるブランチに指定したブランチの「内容」を混ぜ(merge)する」というのがコマンドの意味

当然
・今いるブランチは書き換わってコミットが進む
・指定したブランチには変化なし

515 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 18:17:50.37 ID:Nhn9wgjX0.net]
>>513
あ、
自分がいたほうじゃない方のブランチは、
branch3とかにつなげられますね…

516 名前:デフォルトの名無しさん mailto:sage [2025/06/28(土) 18:19:22.53 ID:Nhn9wgjX0.net]
>>514
ですね

わからない理由は、日本語のまともな解説が無いからですね…
海外の解説で、ようやく理解できました…

517 名前:デフォルトの名無しさん [2025/07/01(火) 20:11:53.56 ID:HVBtOzc60.net]
混じるからマージる

518 名前:デフォルトの名無しさん mailto:sage [2025/07/01(火) 22:46:34.19 ID:BgB6BrdO0.net]
去年のリリースの記憶をタグる

519 名前:デフォルトの名無しさん mailto:sage [2025/07/02(水) 21:57:57.01 ID:xYSFlqIW0.net]
頭悪い人って自分が理解できないのを説明する人のせいにしがちだよね
説明が悪いならなんでお前以外の人は理解できてるのかと

520 名前:デフォルトの名無しさん mailto:sage [2025/07/03(木) 03:33:50.65 ID:ZlHu/VzU0.net]
能力不足故に検索の仕方や聞き方が下手で自らが望む解説に効率的にアクセスできない
ダニングクルーガー効果のような認知バイアス
元から他責的、依存的なせいで残り少しの努力を怠り多方面で理解不足に陥りがち
この中のどれかか、複合要因ではないかな



521 名前:デフォルトの名無しさん mailto:sage [2025/07/05(土) 16:41:53.58 ID:Jt1MZnHo0.net]
>>519
それは、
運良くいい説明を見れたからでしょ

お前には無理そうだが

522 名前:デフォルトの名無しさん mailto:sage [2025/07/05(土) 17:28:57.77 ID:99i/fp2o0.net]
大丈夫だよ
プログラム書いたらビッとコミットしてギュッとプッシュしてギャンよ

523 名前:デフォルトの名無しさん [2025/07/06(日) 09:39:11.50 ID:AHvPqc/80.net]
コミッとコミットする

524 名前:デフォルトの名無しさん mailto:age [2025/07/09(水) 16:29:53.53 ID:NiP9rW7K0.net]
Git v2.50.1

525 名前:デフォルトの名無しさん mailto:sage [2025/07/09(水) 20:54:58.43 ID:5nTmkCkK0.net]
初心者の質問ですが、
Linux(サーバー的なもの)に、GitHubのレポジトリをクローンして来て、
それをWindowsパソコンからSSH接続して、
Gitの履歴の図(Gitグラフ?)って見る方法ありますか?

526 名前:デフォルトの名無しさん [2025/07/09(水) 22:47:25.77 ID:OQriWW8/0.net]
ありますね

527 名前:デフォルトの名無しさん mailto:sage [2025/07/10(木) 12:47:26.79 ID:+1gidKVl0.net]
>>526
会話を広げる癖をつけろ童貞

528 名前:デフォルトの名無しさん mailto:sage [2025/07/10(木) 20:49:27.62 ID:tN4eS5FO0.net]
>>527
なら会話広げればいいじゃん。

529 名前:デフォルトの名無しさん mailto:sage [2025/07/13(日) 17:29:18.40 ID:QlUonva10.net]
>>525
sshで git log --graph で履歴取ってきて、mermaid変換してmarkdown埋め込みにすればいいんじゃね?

530 名前:デフォルトの名無しさん mailto:sage [2025/08/06(水) 12:13:19.02 ID:48BfQKJO0.net]
>>527
あると信じて検索すれば報われますよというありがたい情報だぞ



531 名前:デフォルトの名無しさん mailto:sage [2025/08/13(水) 06:18:19.45 ID:YOB+IZc5r.net]
やりますね

532 名前:デフォルトの名無しさん mailto:sage [2025/10/22(水) 09:23:57.49 ID:pnMMn99c0.net]
https://forest.watch.impress.co.jp/docs/news/2056148.html
次のバージョンからgit svnが廃止されると書いてあるけど、
これはSubversionからの変換もできなくなるということでしょうか

533 名前:デフォルトの名無しさん [2025/10/22(水) 13:20:45.27 ID:2nDvyZJf0.net]
Git for Windowsの次回メジャーリリースでの話をしてるならそうだよ
旧バージョンや本家を使うとか、svn2gitだとか別VCS経由とか手作業での移行だとかは出来るでしょう

534 名前:デフォルトの名無しさん mailto:sage [2025/10/22(水) 13:52:16.21 ID:Nfi7SE1t0.net]
もうシンプルに使われてる機能だけをブラッシュアップすればいい思う。
互換性とか古いものをメンテし続けるのは大変だよ。

535 名前:デフォルトの名無しさん [2025/10/24(金) 14:37:23.45 ID:nAYKU6CIa.net]
いまだに新規プロジェクトでSubversionからっていうのはもう洗脳されてるから放置で良いし
Subversionから変換する気があるならもうとっくにやってるだろうし

536 名前:デフォルトの名無しさん mailto:sage [2025/10/24(金) 15:02:05.38 ID:ZcyI5XOE0.net]
Windowsユーザーだと、業務でSVNを使わざるを得ないがGitコマンド経由で使うことで辛うじて自己の尊厳を保っていた人もいそうだな
電車止まりそう

537 名前:デフォルトの名無しさん mailto:sage [2025/10/24(金) 18:33:25.65 ID:J3E6mCG+0.net]
>>536
そんなプロジェクトやだなぁ

538 名前:デフォルトの名無しさん mailto:sage [2025/10/24(金) 20:17:02.32 ID:NslM5AvMr.net]
令和なのにまだSVNで消耗してる人いるんだ
絶滅危惧種かな

539 名前:デフォルトの名無しさん mailto:sage [2025/10/24(金) 23:30:36.26 ID:vJAYr0tv0.net]
>>536
Gitって、開発速度は遅くなるよね
コードレビューとか丁寧にやると遅くなるよね…

540 名前:デフォルトの名無しさん mailto:sage [2025/10/25(土) 00:27:30.86 ID:a9lDbV800.net]
>>539
規模(参加人数、開発期間、コードサイズ)次第。大きくなれば git 使った方が早い



541 名前:デフォルトの名無しさん mailto:sage [2025/10/25(土) 04:23:36.31 ID:kofX/eP60.net]
>>539
gitだからコードレビューが必要って認識?
アホじゃね?

542 名前:デフォルトの名無しさん mailto:sage [2025/10/25(土) 08:42:34.81 ID:/eT+OdROH.net]
SVNと比較しての話なら、Gitはコミットやブランチの操作が遥かに軽量だからこそ、
チームが必要以上に面倒なワークフローを作り込みがちな面があることは否定できないな
非機能要件でちゃんとバージョン管理しろと書かれているからという理由だけでVCS使ってるような典型的な業務系でSVN使い続けてるようなとこだと、
レビュー済みまたはリリース済みのコードをコミットするだけみたいな運用は珍しくないからな
そういった意味で、VCSの運用という点だけ見ればGitの方が複雑になる傾向があるとは思う

543 名前:デフォルトの名無しさん mailto:sage [2025/10/25(土) 12:06:31.87 ID:lNU8C84m0.net]
>>540
まあ、
大規模だと、ちゃんと管理が必要ですね…






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<168KB

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