[過去ログ] Git 19 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
736: (ワッチョイ 9710-VWGQ) [age] 2023/08/16(水)08:43 ID:0OeOngjW0(1) AAS
Git v2.42.0-rc2
737: (ワッチョイ ab7b-SLZP) 2023/08/16(水)09:18 ID:shyXhCG/0(2/3) AAS
>>735
使う必要がないと分からないのはお前の問題
738: (ワッチョイ 4ecf-eQmn) 2023/08/16(水)09:28 ID:x0p4Dvkt0(1) AAS
>>734
なんとかバケツの方はどうなったのよ?
とりあえず作ってあるとこまで仕様のテキストでもコードでもあるものリポジトリで公開してみてよ
みんなで見よう
739(1): (ワッチョイ ab7b-SLZP) 2023/08/16(水)09:34 ID:shyXhCG/0(3/3) AAS
ああそういえばsvnもブランチは切れるぞ
ただ集中型だから各ディレクトリになり、gitとは形式が異なるが、それ用に環境作ってあれば何ら問題ない
だからブランチが使えるだけでgitに移行する理由にはならないし、そう思えるのなら見識が狭すぎる
740: (ワッチョイ 4e8f-oWN7) 2023/08/16(水)11:44 ID:G7CQiFLH0(2/2) AAS
色々理由はあると思うけど、
- アセットなどのバイナリファイル主体だからいちいちブランチを切り替える意味があまりない
- ファイルのロックが簡単
- 非プログラマでもgitよりは扱いやすい
だいたいこの辺りじゃね?
バケツ野郎じゃないけど、何でもかんでもgitでやればいいと言うのはどうかと思うぞ
741: (ワッチョイ cb79-jQXM) 2023/08/16(水)20:42 ID:jMAEN3UU0(1) AAS
アーティストはコマンド直接は使わんし管理ツール作り直すのもめんどいし
742(1): (ワッチョイ cebb-+ayc) 2023/08/17(木)02:13 ID:/c9h87BG0(1/2) AAS
>>739
ブランチ切れるかどうかなんて問題にしてないよ
ブランチをどのように活用できるかの問題
お前まともに git 使ったことないだろ
743(2): (ワッチョイ ab7b-SLZP) 2023/08/17(木)08:31 ID:zl6mWfwu0(1/4) AAS
>>742
gitを使えば全てが解決して幸せになれると信じるgit統一教信者乙
そりゃお前がsvnのブランチモデルを活用出来ないだけ
git使うだけでリリースが1ヶ月早められるのなら、みんなgit使ってるよ
連中にとってメリットがないからgitを使わないだけという事実をきちんと受け止めた方がいい
そもそも俺はブランチで効率が上がるのはマネジメント不足なだけで本末転倒だとも思うが
(巻き戻し《≒ブランチの破棄》が行われない限りブランチで効率が上がることはないと思ってる
逆に言えばマネジメントがまともに出来ないレベルの連中でもそこそこの開発効率を得られる点ではブランチは有効だが、
会社の場合は既に有能か無能か分かってる連中に仕事を配分するから、そこまで酷くなることはない)
伝わらないかもしれないが、「最終的に『必ず』マージすると分かっている作業なら、
最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ
つまり、形式としてはsvnの方がgitより理論効率は高いことになる
(実際に出来るかどうかはまた別だが)
多分な、(オープンソース等)ある程度rejectする前提ならgitのように気軽にブランチ丸ごと捨てられる構造が便利だが、
(プロプライエタリ等)最終的に全員のコードをマージする前提で仕事配分してたら、svnでも、ブランチ無くても、大して問題ないって事だと思う
744: (ワッチョイ cebb-+ayc) 2023/08/17(木)08:43 ID:/c9h87BG0(2/2) AAS
>>743
git 使ったことないのが丸わかりの意見でw
745(1): (ワッチョイ 4ecf-vKG+) 2023/08/17(木)09:43 ID:ri4IcwiZ0(1/3) AAS
>最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ
同じファイルを触ってたらわけわかんなくなるな。
その場合VSSみたいにファイル単位でロックする仕組みが必要かな。
746: (ワントンキン MM17-epl3) 2023/08/17(木)10:28 ID:O9IbbVomM(1) AAS
>>743
このスレ立てた人だよね?
日常の進捗履歴記録ツールWitBucket(仮称)検討中
2chスレ:tech
否定しないなら同じ人って判断するけど、とりえあず顛末だけでも書かないとここで何言っても
他の人からは「投げっぱなしのテキトーな人」って目で見られて誰も聞く耳持ってくれないと思うよ?
747: (ワッチョイ 275f-nIJd) 2023/08/17(木)10:29 ID:40tRnXUX0(1) AAS
みんな分かってるから触れなくていいっての
マジで
748: (ワッチョイ ab7b-SLZP) 2023/08/17(木)12:11 ID:zl6mWfwu0(2/4) AAS
>>745
> 同じファイルを触ってたらわけわかんなくなるな。
その通りだが、それがどれだけあるかという話なのと、アナログに回避出来るという事。
理解してくれてると思うが、俺が言ってるのは、最終的にFast-Forwardマージしていくのなら、
最初からそのラインを辿るように変更していくのが最大効率だということ。
そしてこれは難しいことでもない。会社で仕事を差配する側なら当然全員出来る。
(逆に言えば、ブランチはまともなマネジメントが出来ないレベルでも何とかなるようにした。
だからある意味初心者ほどブランチの恩恵にあやかれる。多分git信者がブランチにこだわるのはこれ)
同一ファイルを同時に変更するにはブランチが必要だが、これは単純に、
・同時には変更せず、シリアルに変更する。
だってgitでマージしたら結果的に見た目はそうなるのだし、絶対に「同時に」変更する必要があるわけではない。
・そもそも「仕事」で配分してる会社ってあるのか?
Javaのように1クラス1ファイルのように小分けしてて「担当モジュール」制度なら自動的にシリアル化する。
・「仕事」=「仕様変更/追加」単位で仕事を配分し、全員がどのファイルをどう変更してもいい、最適な箇所を自由に変更しろ
というのは理想的ではあるが、実際は出来ないと思う。
よく知りもしないファイル/モジュールを変更するとバグる(または、潜在バグを埋め込む)ものだから。
担当モジュール制は、実際の所、より非力なチームでも通用する方法であって、
(プロプライエタリまたは少人数等で)実力をお互いに把握出来てる状態ならこれが完全に機能する。(からほぼ全社このシステムのはず)
だからsvnでもブランチ無くても関係ないんだと思うぜ。
(まあgitでも問題ないが、現時点で問題なく機能してるsvnから移行する理由がない)
gitはこの辺linuxに全振りだから、linuxには最適だが、それ以外には大してメリットもない。
ちなみにsvnのブランチなら、他人の作業状態もそれなりに見える。だから遅れてる部分も丸見えではある。
gitの場合は完成品を納品するシステムだから、遅れてる奴が黙ってたら全く検知出来ない。
勿論この辺はgitではなく上位戦略で回避すべき案件ではあるが、実際に問題になることもあるとは思う。
749: (ワッチョイ 4e8f-oWN7) 2023/08/17(木)12:18 ID:oGbYN+EC0(1/2) AAS
gitを分かってないから、svnの優位点語るのに頓珍漢なことしか言えないんだろうな
svnも分かってるかどうか(実際の現場でどのように使われるかに関して)も怪しい
750(1): (ワッチョイ 4ecf-vKG+) 2023/08/17(木)12:52 ID:ri4IcwiZ0(2/3) AAS
ようはトピックブランチを使わずにmasterに直接commit/pushするようなやり方だろ。
ひとり開発でならよくやるな。
751: (ブーイモ MMba-+ayc) 2023/08/17(木)13:03 ID:d5O4VVsaM(1) AAS
svn で共同開発したことがあったら、あんな嘘は書けないので、svn なんて全く知らなくて、git を叩きたいから良く知らない svn 持ち上げてるだけだろ
752: (JP 0H7f-YOEV) 2023/08/17(木)15:50 ID:BJu8USc1H(1) AAS
長文くんはやたらとゴミバケツを無視しようとしてるけど「そのスレ立てたのは俺じゃない」とすら言わずに無視してるから,実質認めてるね
753: (ワッチョイ ab7b-SLZP) 2023/08/17(木)15:55 ID:zl6mWfwu0(3/4) AAS
>>750
つまり「ひとり開発」ではその方法が最大効率だと自明なわけだ
そして「効率」だけを問題にするなら、実は多人数でも同様で、
各自ができるだけ干渉せず、別々にアップデートするだけの、「それぞれが『ひとり開発』状態」に持ち込むのが最大効率だ
これをアナログに目指すなら、綺麗にソースを分離し、各機能を追加/変更する際には別々のファイルに当たるようにすればいい
つまりJava方式も一つのやり方だよ
こういう事前準備を一切せず(出来ず)、デタラメな場合でも、
ブランチだマージだの力業で解決出来るようにした意味はあるが、(=擬似的に「ひとり開発」状態に持ち込める)
元々無くても困らない(ように事前準備出来る)奴にとっては大した意味はないんだよ
754(1): (ワッチョイ 4ecf-vKG+) 2023/08/17(木)17:46 ID:ri4IcwiZ0(3/3) AAS
>各自ができるだけ干渉せず、別々にアップデートするだけの、「それぞれが『ひとり開発』状態」に持ち込むのが最大効率だ
トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすることを言っているならわかるが。
755: (ワッチョイ 9a4f-tKjX) 2023/08/17(木)18:05 ID:H7X3UE9D0(1) AAS
バケツ君はCI知らないだけだな
756: (ワッチョイ 4ef2-qIXs) 2023/08/17(木)19:39 ID:Fh9vwJEA0(1) AAS
1回でもちゃんとGit使ってみれば良いのに
普通に便利なツールだから皆使ってんのよ
757: (ワッチョイ 0ee4-dacP) 2023/08/17(木)20:52 ID:LN2mo1dt0(1) AAS
少し前のスレ見てた人なら知ってるかもしれないけど、一応使ってなにかやろうとしてたよ
ただreflogを永続的な管理情報だと勘違いしたりとか、思い込みが激し過ぎて自分で修正できないタイプみたい
758: (ワッチョイ ab7b-SLZP) 2023/08/17(木)21:02 ID:zl6mWfwu0(4/4) AAS
>>754
> トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすること
は
> (=擬似的に「ひとり開発」状態に持ち込める)
と表現してる。
最大効率(=余分な作業が一切ない)のは、
・一人で全部シリアルに変更した場合、とこれに準じた
・ブランチを切ってマージした場合に一切競合が無かった場合
だよ。だからブランチはマネジメントが行き届かない場合に効率の低下を防ぐ方策であって、
効率を上げる方策ではないし、十分にマネジメント出来てれば必要ない。
ゲーム開発連中はこれが分かってるからgit(というか君らによるとブランチなのか?)にメリットがないから移行しない。
ただgitのような分散型の場合、本質的にテスト効率が半分なので、
(つまり、ローカルリポジトリの作業でテストした後、マージ後にもう一度同じテストを流す必要がある)
集中型(masterに直接commitしていく場合も同じ)に比べて最終コード(により近い状態)でのテストの積み上がりが遅い。
連中が気にしてるのはこの辺かも。
(まあgitでも誰かしら本体にcommitしたら常にrebaseし直すルールで運用すれば同じにはなるが)
759: (ワッチョイ 4e8f-oWN7) 2023/08/17(木)21:15 ID:oGbYN+EC0(2/2) AAS
君らよくバケツくんの言ってることについていけるな
俺には彼が何を言いたいのかさっぱりわからん
そもそも必要もないカッコ書き多用するから読む気もしない
現場にいたら即切るレベルだよ
760: (ワッチョイ cebb-+ayc) 2023/08/18(金)01:12 ID:mGP0mIml0(1/2) AAS
長文君は参考書斜め読みして理解できなくて、でも格好良い言葉使いたいので
意味も分からずに「マージ」だの「トピックブランチ」だのカタカナ用語言ってるだけなので、理解できないのは当然。
用語が矛盾だらけ。
761: (アウアウウー Sac7-CyVu) 2023/08/18(金)04:37 ID:pbc8FSyxa(1) AAS
CircleCI, Github Actions を知らないの?
Ruby on Rails で、知らなかったら就職できない
762: (ワッチョイ 03f0-ki9m) 2023/08/18(金)06:01 ID:0N1EMKz10(1) AAS
gitはlfsとかsubmoduleが後付けなのかしっくりしない感じがする。
クライアントの使い方を調べないと問題が解決出来ない事が多くてつれえわ。
763(2): (ワッチョイ ab7b-SLZP) 2023/08/18(金)09:14 ID:DqVFTH2M0(1/4) AAS
gitなんてただの入れ物なのだから、それに過度にこだわるお前らは「名刺整理に精出してる営業」と同じだ。
名刺整理なんて必要な名刺がスパッと出てくれば何でもいい。
本来の問題はその先、顔/性格/要求事項等を思い出し、どう営業するかの算段を立てることだ。
名刺が出てきて満足してたら駄目だろ。
gitやsvnも同じで、過去のコードを確認したいときにスパッと出てくれば何でもいいんだよ。
本来はそのコードをどう改変して製品にしていくかであってね。
お前らは「ぼくのすごいせいりじゅつ!!!」で満足してるから、本来の問題が理解出来ない。
ゲーム会社なんて90年代(=git《2005》以前)からやってるところも多いし、
gitなんか使わずとも何とでもなるノウハウと経験を持ってる。
順当に考えて、お前らより技術も経験も能力も上だ。
その彼等が積極的に移行しないのは、単純に、メリットがないからだ。
gitを使えば全ての問題はたちどころに解決して幸せになれる!!!と信じて疑わないgit信者には理解出来ないとは思うが。
多分な、お前らはgitを使ってしかいないから、
使わなかったときに何が問題で、どういう解決方法があるかを知らないんだよ。
それで、「gitすごいんですよ!!!」と営業かけられても、「間に合ってます」でしかない。
解決済みの問題を「オレオレ流に解決したからこっち使え!!!」と言われてもウザイだけだろ。
AIによるコード生成にウキョウキョ言ってる連中の方がお前らより数万倍賢いと思うよ。
gitをいくらこねくり回しても、本質的な問題はどうにもならんだろ。
(まあこれがLinus曰く「最も興味がないものだと見なしていた」なのだろうけど。
ただまあ、読み返してみると、Linusのgitに対する見方は妥当だな。
少なくとお前らみたいにgitが普遍的に使える完成品だとは勘違いしてない。
外部リンク:ezoeryou.github.io
764: (ワッチョイ df63-rF9L) 2023/08/18(金)11:38 ID:P2hKBqqY0(1) AAS
バケツくん、元気にしていたんだね。
おじさん、心配していたんだよ。
765: (ワッチョイ cebb-+ayc) 2023/08/18(金)14:52 ID:mGP0mIml0(2/2) AAS
自転車に乗れなかったやつが、人間ずっと昔から歩いてきてるんだから自転車に何か乗る必要はないってグダグダ説教してたのとそっくりで趣深い。
すっぱい葡萄ってやつか。
上下前次1-新書関写板覧索設栞歴
あと 237 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.013s