Git 20 (530ﾚｽ)
上下前次1-新
474: (ﾜｯﾁｮｲ 595d-ZKbC) [age] 06/17(火)08:04 ID:JQTnqwjt0(1) AAS
Git v2.50.0
475: (ﾜｯﾁｮｲ 8101-vdhk) 06/18(水)00:48 ID:zWpFFB0D0(1) AAS
オススメのgitクライアント教えて
source treeはなんかuiの一つ一つがデカくて肌に合わなかった
476: (ﾜｯﾁｮｲ 01ce-gBoT) 06/18(水)02:39 ID:QsB71xf70(1) AAS
自分はlazygitとVSCodeだな
477: (ﾜｯﾁｮｲ 75da-lPQl) 06/18(水)08:16 ID:6RiwAFGc0(1) AAS
うちではSourceTreeというやつを使ってるよ
478: (ﾜｯﾁｮｲ f689-dilZ) 06/18(水)09:02 ID:7Ghn3yO50(1) AAS
使いにくいやつね
479: (ﾜｯﾁｮｲ 5944-gBoT) 06/18(水)18:04 ID:c2eS9NyS0(1) AAS
lazygitかSourcetreeだな。
480: (ﾜｯﾁｮｲ 128d-JTAW) 06/19(木)20:10 ID:dNWjhAfr0(1) AAS
わかばちゃんの中の人
外部ﾘﾝｸ:x.com
481(1): (ﾜｯﾁｮｲ c57c-jgBs) 06/21(土)23:55 ID:Rsg0aBc50(1) AAS
VSCodeの拡張機能で提供されてる Git Graphが 使いやすいね
482: (ﾌﾞｰｲﾓ MM6b-FTUu) 06/22(日)00:39 ID:L6Wg3CMhM(1) AAS
あれいいよね、見やすい
ハッシュ手打ちの人がんばってw
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
その辺はチームの方針次第だね
リポジトリで分けるのかブランチで分けるのか、個人専用かチーム用か、機能ごとか開発単位ごとか、公開範囲やレビューの手順や粒度をどうするか
マージやプルはとにかく、レビューは機能単位で小分けにやった方が良いとは思う（個人の意見
上下前次1-新書関写板覧索設栞歴
あと 27 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.020s