[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
474(2): (ﾜｯﾁｮｲ 4602-+ld4) 2023/03/30(木)20:36 ID:NHxtu0BL0(1) AAS
複数人が同一ブランチで作業していて、それぞれ異なるファイルを修正しているのですが、
一人がプッシュすると、他の人がそれをプルしてくる際にマージのコミットが発生します。
ff-onlyの設定だと、複数人の作業ではいつもプルに失敗します。
Gitでは複数人での作業はこういうものなのでしょうか。
475(1): (ﾜｯﾁｮｲ 2ecf-uluY) 2023/03/30(木)21:17 ID:jlqIRhmm0(1) AAS
そういうもんだけどその複数人たる他の人達はそのことについてあなたになんて言ってるのさ
476(1): (ﾜｯﾁｮｲ aebb-zPPn) 2023/03/30(木)23:49 ID:n9cKQeMP0(1) AAS
>>474
普通は同じブランチ上で作業しない。
ブランチ切るのは無料なので各自が自分用の作業ブランチを切ってそこで作業する。ff-only の場合は特に。
ブランチ切らずに作業するのは hot fix とか超急いでる時だけ。
477(1): (ﾜｯﾁｮｲ e9e6-+ld4) 2023/03/31(金)09:11 ID:2bhkq+Nl0(1/3) AAS
>>475-476
一つの機能追加やバグ修正を、複数人で対応するようなケースなんですが、
こういう場合も一人一人ブランチを切って作業するものなんですか？
そうなると、ブランチでフェッチやプルが必要なケースってなくなってしまいそうですが。
478(1): (ﾌﾞｰｲﾓ MM85-gF7D) 2023/03/31(金)10:25 ID:JCq04AVFM(1) AAS
>>474
異なるファイルを編集しようが、すでに起こったコミット済みのファイル間で一貫性が保たれていないかもしれない状態かもしれないわけだしマージするしかなくない？
モジュールAとモジュールBはお互いの内部実装に依存しているが、AとBを変更した担当者がお互いの変更を知らないでコミットツリーが1本になっちゃっても困るでしょう。
見た目上マージを避ける方法としてはrebaseとかあるけど。
479: (ﾜｯﾁｮｲ e9e6-+ld4) 2023/03/31(金)10:58 ID:2bhkq+Nl0(2/3) AAS
>>478
プルのときにリベースをすると、マージコミットが発生しないようにできるんですね。
いろいろ勉強していたら、複数人での開発でマージコミットが履歴の上に何度も現れるのは目障り、
と同じような感想を持っているサイトがあり、リベースが紹介されていました。
480(1): (ﾌﾞｰｲﾓ MMb6-zPPn) 2023/03/31(金)12:50 ID:U5A6Rz77M(1/2) AAS
merge commit ない方が履歴を追いやすいので普段の小さな更新は rebase でやるのが一般的。
一方で長く別れていた異なる経歴のものを混ぜる場合には merge commit があった方が分かりやすいので merge にするべき。
481(1): (ﾌﾞｰｲﾓ MMb6-zPPn) 2023/03/31(金)12:57 ID:U5A6Rz77M(2/2) AAS
>>477
作業ブランチの共有をどのようにするかはチームごとのルールがあるので仲間に確認
プルリクエストを出して取り込んでもらうという運用もあるし、
共有ブランチにプッシュする運用なら、作業ブランチを共有ブランチの先頭に rebase した上でプッシュするのが一般的。
482: (ﾜｯﾁｮｲ e9e6-+ld4) 2023/03/31(金)13:39 ID:2bhkq+Nl0(3/3) AAS
>>480-481
>共有ブランチにプッシュする運用なら、作業ブランチを共有ブランチの先頭に rebase した上でプッシュするのが一般的
この運用だと、複数人での同一ブランチでの作業でも、履歴を1本化できるのですよね。
もちろん、他のブランチでの修正などをマージするときは、履歴として残していくつもりです。
483: (ｱｳｱｳｳｰ Sa23-4c3z) 2023/04/05(水)18:00 ID:H6gFlorFa(1) AAS
WindowsのSourcetree、起動するたびに右に1ピクセルずつ広がっていくんだけど、おま環？
484: (ｱｳｱｳｳｰ Sa23-mFyV) 2023/04/06(木)18:18 ID:un5AwFJZa(1) AAS
めっちゃ判りますωωω
485(1): (ﾜｯﾁｮｲ e1ba-P47T) 2023/04/08(土)16:07 ID:6pTBweNA0(1) AAS
Git初心者後輩のrebase童貞とreset童貞
卒業させてやった
486: (ﾜｯﾁｮｲ 4619-nMYw) 2023/04/09(日)19:33 ID:Hd1BGJ070(1) AAS
>>485
おめ。
次はSquashで大量コミットお化け童貞も捨てさせるチャンスだな。
487: (ｵｲｺﾗﾐﾈｵ MM29-hB6S) 2023/04/12(水)16:25 ID:JiChcRr/M(1) AAS
pushしてPRしてアーッって新境地へ
488: (ﾜｯﾁｮｲ 2710-sFbk) 2023/04/20(木)22:47 ID:02avdjdC0(1) AAS
開発用ML見てたら、git replay ってのを作ってる人がいる模様。
外部ﾘﾝｸ:public-inbox.org
489: (ﾜｯﾁｮｲ c5e6-FGqy) 2023/04/26(水)19:09 ID:nF7JL/l90(1) AAS
マージして削除したブランチって、ログの樹形図を見ても、
そのブランチが何という名前だったのかは基本的にわからないものですか？
490: (ﾜｯﾁｮｲ 7910-MClS) [age] 2023/04/26(水)19:49 ID:diGGhm110(1) AAS
Git v2.40.1
491(1): (ﾜｯﾁｮｲ 7579-WXYX) 2023/04/26(水)19:58 ID:EZG/OKKF0(1) AAS
マージコミットのメッセージがあればそれを信用するしかない
492(2): (ﾜｯﾁｮｲ c5e6-FGqy) 2023/04/27(木)09:18 ID:4Ldu38ha0(1) AAS
>>491
そういうものなんですか。
Subversionのときは、ブランチの作成自体が1つのコミットで、
ブランチの名前や、どういう作業を始めるのかをログに残しておけたけど、
そのへんの感覚も違うんですね。
493: (ｽｰｯﾌﾟ Sd0a-3RjN) 2023/04/27(木)10:53 ID:SsZf7nuSd(1) AAS
>>492
だからマージの時にどのブランチからどのブランチにマージしたのかデブォルトでコミットログに残るでしょ
494(1): (ﾜｯﾁｮｲ e6bb-QZyk) 2023/04/27(木)21:42 ID:yMUedyDf0(1/2) AAS
>>492
subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、
git はブランチが軽くて余計な容量を食わないので百でも千でも好きなだけ切れる。しょっちゅう作ったり消したりできるし、ずっと残しておく事もできる。
そのせいでブランチに対する考え方が違う。必要ならなんで消したの？ みたいになる。
495: (ﾜｯﾁｮｲ c55f-ASru) 2023/04/27(木)21:51 ID:aeCa0uwW0(1) AAS
>>494
> subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、
んなこたーない。
外部ﾘﾝｸ[html]:tortoisesvn.net
> つまり、リポジトリの完全なコピーを作成する代わりに、指定したツリーやリビジョンを指す内部リンクを作成します。そのため、ブランチやタグの作成は、非常に高速で、リポジトリに追加スペースをほとんど使用しません。
ダメなのはマージの追跡が後付けで非効率なところ。
496: (ﾜｯﾁｮｲ e6bb-QZyk) 2023/04/27(木)22:14 ID:yMUedyDf0(2/2) AAS
いい加減なこと言ってないで、実プロジェクトで git と svn のブランチを使い比べてみろ。
497: (ｵｲｺﾗﾐﾈｵ MMb5-brYh) 2023/04/28(金)05:15 ID:PA/2QVhjM(1) AAS
Error: explorer.exe not found in PATH の修正来たわ
please note that the latest snapshot has the fix
外部ﾘﾝｸ[html]:wingit.blob.core.windows.net
498: (ﾌﾞｰｲﾓ MM0a-QZyk) 2023/04/28(金)15:09 ID:dkx3B1sjM(1) AAS
svn 屋がいくら cheap copy でコピーが速いって自慢しても、git のブランチ作成はそもそも zero copy なんで比べものにならないんだよな。
設計思想の根本的な違い。
499(1): (ﾜｯﾁｮｲ c55f-ASru) 2023/04/28(金)15:30 ID:dDRImt5V0(1/2) AAS
別に Subversion を擁護するわけでも自慢するわけでもないんだけど、少なくともブランチ作成に限れば
どちらも一瞬なんで何を見て「ディスク容量とかで制限されてた」「比べものにならない」とか言ってるのか
わからない。 Subversion 嫌い過ぎなだけなんじゃないかと。
マージはクソなのでそこも含めての話なら「ブランチの使用が重くて」はわかる。
500(2): (ﾌﾞｰｲﾓ MM0a-QZyk) 2023/04/28(金)17:05 ID:8y/8q1m4M(1) AAS
>>499
そこまで言うのなら大きめのプロジェクト、例えば linux のソースコードくらいのやつに git と svn で100個ずつブランチを切って作業時間を比べてみ。当然だが作業コピーも作って1回ずつ作業しろよ。
どっちも一瞬かどうか、自分で体験すれば納得いくだろ。
ディスク容量の話は昔の容量が小さかったころの経験なので、最近の大容量だと問題ないかもだから撤回しとく。
501(1): (ﾜｯﾁｮｲ c55f-ASru) 2023/04/28(金)17:47 ID:dDRImt5V0(2/2) AAS
>>500
え？ブランチ作るごとに作業コピー作るってのが意味わからんのだけど？
そんなことしたらどっちでも作業コピー作る時間が圧倒的ネックになって比較の意味も無くなりそうだし。
502(1): (ﾜｯﾁｮｲ ffbb-E3WC) 2023/04/29(土)10:58 ID:Toi7lz0e0(1/3) AAS
>>501
使ってないこと丸わかりの馬鹿コメントだな。svnスレに帰れ。
お前は作業もしないのにブランチ切るの？
圧倒的ネックなのは svn だけ。git を巻き込むな
503(1): (ﾜｯﾁｮｲ 975f-By2c) 2023/04/29(土)11:49 ID:YEumeQ4R0(1/2) AAS
>>502
どういうことなの・・・
git branch x でブランチ作るにあたって作業コピーなんか作らないし、
svn copy ^/trunk ^/branches/x -m "..." でブランチ作ってもそれは同じでしょ。
なんで「当然だが作業コピーも作って」なんて話になるんだ？
上下前次1-新書関写板覧索設栞歴
あと 499 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.019s