Git 20 (530ﾚｽ)
上下前次1-新
483: (ﾜｯﾁｮｲ 8d95-gfuD) 06/22(日)06:56 ID:APGUbecj0(1) AAS
CUI でもハッシュを手打ちすることなんてほぼないだろ
ブランチもタグも検索も使ってないんだろうか？
484: (ﾜｯﾁｮｲ 2302-ES++) 06/22(日)18:51 ID:4jZfNTw30(1) AAS
>>481
んー
でも、他のGitクライアントも似たもんじゃないの？
485(1): (ﾜｯﾁｮｲ ed7c-jK4x) 06/23(月)11:27 ID:KosRMA640(1/2) AAS
似たような、がどの辺を指してるかにもよる。
rebaseかstash簡単にしたい、tag打ちたい、ブランチ作りたいならだいたいどれでも出来る。
ただ現場で初心者多くて教育面倒だし日本語じゃなきゃだめとかいうなら、SourceTreeか
非公式多言語版GitHub Desktopしかないと思う。
486: (ﾜｯﾁｮｲ 2302-ES++) 06/23(月)12:06 ID:9uUr9jSA0(1) AAS
>>485
で、ベストは？
英語でも有料でも、なんでもいいので
487: (ﾜｯﾁｮｲ 9b68-FTUu) 06/23(月)12:11 ID:qqxmiRlS0(1) AAS
interactiveなrebaseをサポートできてないやつ多いでしょ
488: (ﾜｯﾁｮｲ ed7c-jK4x) 06/23(月)17:00 ID:KosRMA640(2/2) AAS
基本は好きなの使えばいいよ。
対面レビューで追加コミット後に「レビューOKだからコミットひとつにまとめといて」って言われたり
「ウチは協力会社に外資いるから日本語コメントだめなんだ、英語にしといて」って言われない限り
rebase(やsquash)やamend使うこともないだろうし。
489: (ﾜｯﾁｮｲ 4bbb-gfuD) 06/23(月)18:37 ID:MPl++Mur0(1/2) AAS
いや rebase -i も --amend も使いまくりだろ
何なら一番多く使うコマンドまでありえる
一発で完璧な記録できて後は触らないみたいな超人じゃなきゃ、普通に多用するだろ
490: (ﾜｯﾁｮｲ 2303-FL2f) 06/23(月)19:49 ID:Z8z+4HFt0(1) AAS
といっても元のコミットがある程度ちゃんと作られてることが前提じゃない？
単に作業のチェックポイントとして気軽にコミットしてると、いざコードレビュー前に整理しようとしたときには元のコミットを無理に再利用するより
resetして作り直した方が早いことが個人的には多い
書いてて思ったけど、元のコミットがすでに整理されている上で修正を入れる状況としては、コードレビューの中での修正があるね
もしチームのポリシーとして瑣末な指摘反映をログに残さないことにしているなら、レビュー後マージ前にrebase -iするのは便利かもしれない
491(1): (ﾜｯﾁｮｲ 4bbb-gfuD) 06/23(月)21:20 ID:MPl++Mur0(2/2) AAS
そっちじゃなくて手元で色々作り散らかしたコミット履歴を綺麗に読み易く整理してから、レビューに出す。
順番入れ替えたり、コミットメッセージを分かり易くしたり、不要な履歴を消したり、コミットを意味に合わせて分割したり、統合したり
その整理に活躍するコマンドが rebase -i、慣れると手放せない
読み易く整理されてれば他人の時間の節約になる、試行錯誤とかタイポ修正とかの痕跡を他人に見せて時間を奪わなくてすむ
492(1): (ﾜｯﾁｮｲ 5559-FL2f) 06/23(月)22:25 ID:YcF93ZoT0(1) AAS
そんなの方法を議論する以前にもうAIにやらせたらいいんじゃないかという気もするが、
AIにやらせるならやっぱり一連のgitコマンドを直接生成させるのがいいのかなあ
コマンドだと人間が実行前にレビューするのは辛いものがあるから、diff入りのコミットログみたいな形式で生成させて、resetした上でそれを反映するのがいいと思うんだけど
493: (ﾜｯﾁｮｲ 4bbb-gfuD) 06/24(火)07:59 ID:oSvYVpQb0(1/2) AAS
>>492
AI に期待し杉
今のAIはしょせん賢い検索エンジンに過ぎない
学習したことの最も多数派の意見をそれらしく繋ぎ合わせてるに過ぎない
素人が玄人の作業を真似るのには使えるけど、玄人の創造的作業の代替は無理
494(1): (ﾜｯﾁｮｲ ed7c-jK4x) 06/24(火)08:31 ID:1VpUD11F0(1) AAS
>>491
プロトタイプであれやこれやするなら、さらにブランチ作って動くようになったら新しいブランチに
Squash and Mergeして、そっちのブランチをレビュー対象にした方が楽なんじゃ？
495(1): (ﾜｯﾁｮｲ 4bbb-gfuD) 06/24(火)10:30 ID:oSvYVpQb0(2/2) AAS
>>494
いやだから、色々なブランチに順不同で入ってるやつの共通部分を括りだして独立したコミットにしたり、一つのコミットを内容に合わせて複数に分割したり、ばらばらのを分かり易く統合したり
やるべきこっとはいっぱいあるだろ
merge も squash も amend も全部 rebase -i を使ってやる、rebase -i を何だと思ってるんだ？
496: (ﾜｯﾁｮｲ ed7c-jK4x) 06/26(木)10:59 ID:JcQLzuh60(1/2) AAS
amendやsquashを一般人が簡単にやりたいならGitHub Desktopの履歴のとこから出来るけど
使用説明が一切ないんだよなあ。圧倒的なドキュメント不足。
497(1): (ﾍﾞｰｲﾓ MMab-FL2f) 06/26(木)12:02 ID:3juiMOaqM(1) AAS
>>495
アトミックに細かくコミットする人ならrebase -iでの整理は容易だろうけど、分割が多い場合は面倒臭すぎるでしょ
resetしてやり直した方が早いわ
498: (ﾜｯﾁｮｲ 4bbb-gfuD) 06/26(木)14:45 ID:rhHx6Nng0(1) AAS
>>497
意味分からん
「細かくコミット」と「分割が多い」は同じじゃないの？ お前の用語での違いは何？
コミットを統合したり分割したりするのも rebase -i から始めるのに？
いくらでも変えられるのに何が問題なの？
499: (ﾜｯﾁｮｲ ed7c-jK4x) 06/26(木)17:51 ID:JcQLzuh60(2/2) AAS
「細かくコミット」がバックアップ保証のつもり(で修正が動くかどうかも分からん)なら、
都度commitだけしといてpushは待っとけばいいんじゃないかなと思ったり。
500(1): (ﾜｯﾁｮｲ 9b8c-FTUu) 06/27(金)10:30 ID:KAeTyQMQ0(1) AAS
当たり前だろ
動作確認できてないものpushすんなよ
501: (ﾜｯﾁｮｲ 4bbb-gfuD) 06/27(金)10:39 ID:iePZ28tO0(1/3) AAS
>>500
どこに push するか次第だよな
共有リポジトリや公開リポジトリに push しちゃ駄目だろうけど個人のバックアップ・リポジトリとかに push しとくのは自由
リポジトリやブランチを好きなだけ作れて高速に同期できるのが git の利点なんで限られた少数のリポジトリしか使わないのはもったいない
502(1): (ﾜｯﾁｮｲ e31b-FL2f) 06/27(金)10:46 ID:Vbo+wzUI0(1) AAS
GitHubでのチーム開発だと普通に共有リポジトリにpushするけどな。
ただしpush先はいわゆるfeatureブランチなど、そのタスク専用のブランチ。
draft pull requestを作っておいて他人から容易に目に見えるようにするとなお良い。
むしろ手元で長いこと留めてあいつ何やってんだろと思ったら突然クソデカpull request投げてくるような奴は嫌われるよ。まあ開発に限った話ではないが。
503(1): (ﾜｯﾁｮｲ 4bbb-gfuD) 06/27(金)14:47 ID:iePZ28tO0(2/3) AAS
>>502
その辺はチームの方針次第だね
リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか
マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う（個人の意見
504(1): (ﾍﾞｰｲﾓ MMab-FL2f) 06/27(金)15:24 ID:caL9+2zdM(1) AAS
>>503
本題からは逸れるんだが、企業での開発で個人リポジトリにforkする運用ってなんかメリットあるのかな？
自分はこれまで共有リポジトリ運用しか見たことがない
なお、新卒がいきなりforkして怒られてるのは何度か見た
forkして複数の共有リポジトリを使うのは複数の会社がいてそれぞれガバナンスが違うケースなんかで珍しくないけど
505: (ﾜｯﾁｮｲ 4bbb-gfuD) 06/27(金)17:03 ID:iePZ28tO0(3/3) AAS
>>504
github みたいに fork って呼ぶから混乱するんじゃないかな？ オープンソースじゃないから単なる clone だろ
開発用の clone はいくつあっても良い、個人用でもデスクトップとノートPCとサーバと複数の場所にリポジトリもってて定期的に同期させたりしながら、移動中とか自宅とか会議中(笑)に開発したりできる
もちろん会社の情報統制や社外秘情報の漏出防止のためにコピー禁止とか部屋外に持ち出し禁止とか決まりあれば従わないと駄目だが
506: (ﾜｯﾁｮｲ 2302-ES++) 06/28(土)00:10 ID:Nhn9wgjX0(1/5) AAS
Gitむずかしい…
Pythonよりむずかしい…
507: (ﾜｯﾁｮｲ ddb0-kTDo) 06/28(土)11:34 ID:WNSkpT1F0(1) AAS
雑にpushするブランチを作ってあるので
ホイホイプッシュしてる
508: (ﾜｯﾁｮｲ dd9c-uoUG) 06/28(土)14:23 ID:ps+a9/JT0(1) AAS
いやPythonの方が難しいでしょ
509(1): (ﾜｯﾁｮｲ 2302-ES++) 06/28(土)15:15 ID:Nhn9wgjX0(2/5) AAS
初心者なんですが、
branch1とbranch2があって、
branch1にcheckout後に、>git merge branch2 と、
branch2にcheckout後に、>git merge branch1 って、
結果は同じ？
510(1): (ﾜｯﾁｮｲ e3d9-CRrD) 06/28(土)15:31 ID:XJ1OnLan0(1/2) AAS
>>509
ソースコードの内容は同じになる
ログは違う形になる
ログはどのようにソースを扱ってきたかの履歴書や歴史書のようなものなので複雑で大規模なプロジェクトほど価値が出る
511(1): (ﾜｯﾁｮｲ 2302-ES++) 06/28(土)15:47 ID:Nhn9wgjX0(3/5) AAS
>>510
あ、
今やってみましたが、
mergeコマンド実行するときの自分がいるブランチのほうが、引き続き残るって感じですかね？
512(1): (ﾜｯﾁｮｲ e3d9-CRrD) 06/28(土)16:06 ID:XJ1OnLan0(2/2) AAS
>>511
ブランチ自体はどちらも残る
自分がいる方のブランチはマージ結果を指す形で歴史が一方進む
そうじゃない方のブランチはありのまま残る
上下前次1-新書関写板覧索設栞歴
あと 18 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.022s