X

Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
2020/11/21(土) 21:36:11.84
>>352
俺が聞いてるのは「どうやって担当を決めるか」なんだわ

ファイルをなるべく分けていたとして、例えば10個に別れていたとして
何人まで同時に作業できるというのか？

その担当を決める方法を言ってみなさいということ


俺の最終的な答えは「だからコンフリクトは絶対起きるんだよ」なのでよろしくｗ
2020/11/21(土) 21:38:55.68
ソース振りかけるんやったらコーンフレークちゃうがな
2020/11/21(土) 22:44:10.72
>>353
各人の開発負担が均等になるよう、お前はソース1〜5、お前は6〜10てな風に決めるだけ
コーディング部隊のリーダーの仕事の一つだと思うが
2020/11/21(土) 23:04:56.37
>>355
質問に答えてほしいんだが

> 風に決めるだけ
その「決める」をどうやって決めるかを聞いてる

上のテトリスのソースコードが10個に分かれていたとして

仮にこれにが古いテトリスの仕様で↓ボタンで回転するとして
これを右回転、左回転のボタンに分けるという仕様変更を行うとする
というとき、

> お前はソース1〜5、お前は6〜10
お前が担当者を決める立場だとして
どちらが担当するのか、どうやって決めるの？
もしくは、どうやって決めてるの？
2020/11/21(土) 23:22:10.89
必要最低限の箇所だけ修正しないからそういうことになる
2020/11/21(土) 23:36:29.67
>>356
しつこいなあ
頭割りなんだから何だっていいんだよ
名字の頭文字順、席が近い順、身長順、その日出勤してきた順、くじ引き…お好きにどうぞ
2020/11/22(日) 00:18:41.22
コンフリクト起こさないように無理くりやるって完全にアンチパターンだし、
バージョン管理ツール使う意味ねーわ。
2020/11/22(日) 00:30:02.65
コーンフレークやな
2020/11/22(日) 00:56:10.40
>>358
しつこいも何も答えてないからね
つまりお前はソースコードを見ないで担当者決めるんだろ？

どこを修正するのかわからないのに、どうやって担当者決めるんだ？
まさか1つのファイルだけで修正が終わるとでも思ってるのか？
複数の人が同じファイルを修正するときどうするんだよ？
それを早く言ってくれよ
2020/11/22(日) 01:53:16.16
早く済ませたいならコーンフレークちゃうか
2020/11/22(日) 05:07:27.00
チョコクリスピーやろ
2020/11/22(日) 06:47:03.08
オールブランやな
2020/11/22(日) 09:17:20.44
担当者なんてredmineみて各自勝手にチケットとっていくだけだろ？
修正なんて大抵は1ファイル数行だ

機能追加ならもうちょい規模が大きいがそれは凍結するだろう

複数の人が無秩序に同じファイルを修正するケースが思いつかない
VB.NETみたいに1ファイルに1万行あるようなケースならともかく
普通の言語なら数十行だろう

どれだけ大規模なら衝突しちゃうんだい？
2020/11/22(日) 09:38:45.34
なんも関係してない複数プロジェクトのソースマージは結構神経を使うからなあ、どうだろう・・・。
2020/11/22(日) 09:49:00.30
同じ場所を複数人で修正するパターンって
要するに共通で使うようなフレームワークに相当する部分が未完成ってことでしょ？
368仕様書無しさん
垢版 |
2020/11/22(日) 10:05:26.06
1ファイル1万行の糞コードならどんなVCSを使っても無駄だ
2020/11/22(日) 10:06:35.23
低能がうじゃうじゃいるスレだな
2020/11/22(日) 10:26:04.90
>>365
> どれだけ大規模なら衝突しちゃうんだい？

大規模かどうかは関係ない。同じような箇所を修正すれば衝突する
お前、チケット見た段階でソースコードの同じ箇所を修正しないって
どうやってわかるんだ？ありえない話をお前はしてるよな
2020/11/22(日) 10:30:29.24
>>367
ソースコードが単一責任の原則を守れてないとか色々ある
最初から完璧に設計されていて、小さくモジュール化されていて
変更が入るたびに、その内容に応じて設計もちゃんと再構成していれば
コンフリクトが起きる可能性は低くなる

つまりこれはソースコード完璧ならコンフリクトは発生しないと言ってるのと
同じことなので、完璧なソースコードなんて現実にはありえないってことで論破できる
2020/11/22(日) 11:35:10.25
>>365
本当にチーム開発したことあんの？
2020/11/22(日) 12:06:21.32
チーム開発してると手の遅いやつが文句言い出すけど
定期的に手元のソースを最新にしてからそういうことを言ってほしい
2020/11/22(日) 13:55:56.33
おまえたちって本当に末端のゴミPGなんだな・・・呆れたよ・・・

四半期の会計期間ごとに大規模システムの改修計画の予算がおりて
別々のチームが同じソースの改修を同時進行で進めるケースとかに参画したことがないんだな

道端の犬のクソにたかるウジ虫を見ている気分になる
2020/11/22(日) 14:42:59.77
あいつSESかよ
技術者じゃないじゃん
376仕様書無しさん
垢版 |
2020/11/22(日) 14:52:58.06
采配がヘタなだけじゃん。
そんなのをSVNやギットのせいにすんなや。
2020/11/22(日) 14:55:16.50
何かを修正する時に、ソースコード単位で采配なんてできないって話だぞ
2020/11/22(日) 15:13:13.73
数千人規模だと逆にソース管理失敗って聞いたことないよね
2020/11/22(日) 15:37:43.67
>>376
上から采配が落ちてくるならそうだろうね。
それならバージョン管理ツールに神経使う必要もないだろうね。
380仕様書無しさん
垢版 |
2020/11/22(日) 15:58:19.83
上から采配が落ちてこないんなら、それは上がサボってるだけのことで、
まあ下手以前に論外だな。
2020/11/22(日) 16:32:19.38
これバージョン管理ツールであって平行開発の為のツールじゃないよね
2020/11/22(日) 16:35:23.76
並行開発しないチーム開発なんてありえんだろ。なんでこんなに愚かなの？
2020/11/22(日) 17:06:31.86
ファイルごとに担当者決めるなんて非現実的だってまだ理解できないのかよ
2020/11/22(日) 18:36:39.97
並行開発しないチーム開発なんてありえないのに適したツールがない
2020/11/22(日) 19:08:31.80
分散の場合は同期とるのが余計に面倒に思えるんだがどうやってるん？
git入門とかでググっても老人PGが疑問に思う一番重要なところが説明されてない。
git屋はエスパーPGばかりで以心伝心なん？

それともlinusみたいにおまえのコードはマージしてやんねぇとかケンカばかりしてるん？
386仕様書無しさん
垢版 |
2020/11/22(日) 19:31:04.09
>>385
gitは小さな変更だけを含むfeatureブランチのチームでレビューしてからマージを繰り返すスタイルがよく使われる
Git FlowとかGitHub Flowとか
でか過ぎるとレビューしづらくなるし、コンフリクトの影響も大きくなるからだ

このスタイルで開発しても、featureブランチが作られた順番にマージされるとは限らん
ブランチの内容が上流より古くなってしまったら、rebaseを使ってfeatureブランチを最新版から生えてる状態にする

git fetchしてorgin/developを最新にする
次に
git checkout feature/hoge
git rebase origin/develop

とすればfeatureブランチが最新コミットから生えてる状態になる

多分図で見た方が分かりやすいから
ググったり、慣れるまではGUIでrebaseがおすすめ

rebase時にsquashやfixupによるコミットの結合も活用すれば、あとあと履歴が見やすくなるし、rebase時にコンフリクト解消する回数が少なくなる
2020/11/22(日) 21:12:06.81
ブランチ開発してるときに元の関数のインターフェース変わったりしたら
なんぼリベースしようがマージしようが解消できんと思うのだが
2020/11/22(日) 21:36:50.88
やっぱコーンフレークやないか
2020/11/22(日) 21:45:36.11
>385
そう。
クソコード入れるより喧嘩する方が正しい。
2020/11/22(日) 22:10:47.99
> gitは小さな変更だけを含むfeatureブランチのチームでレビューしてからマージを繰り返すスタイルがよく使われる

これが知りたかったんだよね。
git、git言うからどれだけ効率がいい開発手法なのかと思ったら全くの逆で、非効率で泥臭い方法だったか。

内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで、
分散管理のせいでマージ、レビューするまで分からないとかデメリットがでかすぎる。

OSSの開発が遅くバグが放置される理由、forkしまくる理由はすべてgitのせいだな。
391仕様書無しさん
垢版 |
2020/11/22(日) 22:25:29.68
gitは糞ってこき下ろすだけの
代案無しの野党みたいな奴しか居ねえな
2020/11/22(日) 22:48:29.29
gitのブランチのマージは怖い
2020/11/22(日) 22:53:39.66
>>390
>内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで
それがすぐできるならまあどんなバージョン管理しても問題ないだろ。
多分お前はできてないだろうが。

まあ確かにfeatureを細かく切るってのは運用保守の段階なら良いが大幅な改変が必要な時には
無駄が多い。
2020/11/22(日) 23:01:15.70
>>391
いいえ、単にgit知らなくてググってもちゃんとした説明ないから質問しただけですよ。
古い集中管理型ならコーンフレークの遅延はなく、単体テストしてコミットしたのにちゃぶ台返しされるリスクも少ないでしょう？
だから分散管理で問題になるこの同期の遅延リスクをgitではどうやってるのという疑問でしたが、
泥臭くケンカしながら解決するということで疑問は解決しました。

というか代案も何も答えは明白ですよ。シンプルな設計、トップダウンでツリー状に機能が綺麗に分かれるような仕様要件なら分散管理は効率よく機能し、複雑な仕様設計ならgitかっけー的な運用したらプロジェクトはデスマーチ必至。そういうときはgitでも集中管理的な運用をする必要があるということですな。おそらくgitスレがIP表示なのはgitの運用方法でケンカした結果でしょう。
395仕様書無しさん
垢版 |
2020/11/22(日) 23:52:34.36
SVNは一つのブランチで闇鍋して
コミットしようとして初めてコンフリクトになるか
ロックという偽りの安心感を与える道具に頼るかだ

GitFlowもどきをSVNでやる事は普通ない
2020/11/23(月) 01:42:29.61
ボクが考えるgitの運用方法が一番正しいんだみたいな

ある程度複雑性や規模をもった要件に対しては分散管理は非効率でしかなく、
結局Linuxの例を出すまでもなく、OSS陣営の多くの開発がMSより10年遅れてると言われるのも頷ける。
今ではMSもgitに手を出すからブラウザ開発に失敗したり、Windows10はAppleのように互換性切り捨てだらけになってしまった。

縛りのない開放感なんて所詮、責任の放棄でしかないんだよ。
馬鹿な大臣がハンコを無くそうとしてるのと同じ。
2020/11/23(月) 02:07:26.56
>>395
gitflowってsvnの一般的な運用だとdevelopがtrunkってだけだな。featureもreleaseも古くからある運用そのもの。
hotfixって言うリリース後の修正は、svnだと、該当バージョンのreleaseブランチ延ばすんだがな。

>>396
それは結局、運用による。

結局、いつも車輪の再発明で、webのUIとかがちょっと新しいとかそれぐらいの違いしか無いのに誰かが騒ぎ出す。

そしてどんなモダンなシステムも最後の最後は通知が必要で、結局、最後はoutlookを開くのさ。
2020/11/23(月) 03:10:03.19
>>397
>>最後はoutlook
最後は電話

重要なメールをしたら必ず電話
この基本も知らない奴らが「その件なら1ヶ月も前にチケットにコメント書いてますけど」とか「slackに流してるのに、まだ対応してないとかふざけるな」とか平気で言う
「pullして無いのそっちですよね」
2020/11/23(月) 08:37:55.78
メールこそ正義
証跡をあとから編集できるslackや何言ってたかわからない電話のやりとりなど業務連絡のうちにはいらない
400仕様書無しさん
垢版 |
2020/11/23(月) 08:41:58.23
まあおれだったら、素直に会社に行くんだけどね。
401仕様書無しさん
垢版 |
2020/11/23(月) 08:56:45.56
SVN使っても変わらないは流石に老害の暴論
402仕様書無しさん
垢版 |
2020/11/23(月) 09:07:01.44
だからまあ、前にも言ったけど、こういうのは、
ちゃんと管理責任者を決めて、そいつにやらせなきゃダメだよ。
そいつはsvnでもギットでも日付フォルダでも好きにやればいい。

で、tortoiseなんて末端作業員のマシンに入れさせちゃダメ。
リポジトリURLは、会社のトップシークレットだと思わなきゃ。
403仕様書無しさん
垢版 |
2020/11/23(月) 09:17:17.70
同じくDVCSのMercurialはrebase機能あるけど
拡張機能が必要
できれば使ってほしくないみたいな感じ？

gitは最初からrebase可能
何をしようとしているか分かっているんだから
邪魔をするな！と言うリーナスの思想が現れている

force pushをfeatureブランチ限定にしても、
rebaseをすると、それをする前のfeatureブランチの履歴が失われると言うデメリットはある
2020/11/23(月) 09:44:23.34
>>399
メールとSlack併用してる現場で言動一致しないリーダーがいるときに
「メールをエビデンスにしたい」一心でメールで重要事項を周知すると
出荷前のブタのように発狂するから怖い
2020/11/23(月) 09:47:55.60
>>397
おまえなんも知らんのだな・・・メール頼みは怖いぞ

商社をクビになった社員が顧客情報を持ち出して
商社のテンプレートで振込先変更の連絡を入れてきて
売上金をだまし取られた詐欺事件が横行している
2020/11/23(月) 11:37:36.80
内部の人間の問題はセキュリティだけじゃ何ともならんよ
出したときにID,パスワード,アドレスを全部消すか変更しとけよ
それでも別のアドレスで接触も可能
そんなもん人間の問題だし、捕まったなら追跡できたわけで完全な抜け穴だったわけでもない
抜かれても追えない、気が付かない方がよっぽど怖い
2020/11/23(月) 12:05:54.08
>>394
gitでも中央管理をすりゃいいだけだろ
分散管理が「できる」ってだけで、分散管理が必要のないケースでは分散しなきゃいいだけ
2020/11/23(月) 13:00:35.46
別にgitが管理してくれるわけじゃない
2020/11/23(月) 15:42:50.44
なるほど。だからgit使えるだけでマウンティング取る開発経験のない若いPGがgit使うと
デスマーチ、開発放棄になるのも当然だな
2020/11/23(月) 21:20:47.49
てかマージがうまくできないならpushすんな
ってのができるだけでもgitの価値あるだろ。
その辺、中央管理だといちいち普通の作業でも同期とるっていうのがクソ厄介。
ある程度コミットが整ったらpushっていう分散管理のが明らかにまともだわ。
411仕様書無しさん
垢版 |
2020/11/23(月) 21:26:45.02
SVNにはstashもない

stash相当の事は自分でパッチファイル作ってやる必要がある
めんどくさい
2020/11/23(月) 21:48:50.28
ハッキリ言ってsvn擁護派では無いが、

>>410
svnだろうが何だろうが行単位でコンフリクト発生してる状態じゃ相手先のブランチにpushなりcommitなり出来無いんじゃ？

>>411
パッチでも結局1コマンドで退避、復元出来るから対して問題ないのでは？svnだとローカルリポジトリの状態とか保持する必要無いからstashに対するモチベーション低いだけ？
2020/11/23(月) 21:53:10.09
GitHubありがとう！
わからないとこ検索したら凄い人見つけて真似して解決した
ありがとうGitHub！
2020/11/23(月) 22:01:17.67
ソースとってきて修正して戻す
っていうスパンが長すぎたら結局どうにもならんでしょ
迷惑かけない程度に手を速く動かせよ
2020/11/23(月) 22:07:08.79
>>412
svnだとコンフリクト起こしたらはっきりストッパーになるだろ。
まあそれがいいという人もいるかもだが、無駄なプレッシャーだったり効率悪くしたり、あんまいいことだと思わん。
2020/11/23(月) 23:23:56.95
>>415
本気で言ってる意味が理解出来ない。gitだと行単位でコンフリクト起こしても自動で解決してくれるとでも言いたいのか？？
2020/11/23(月) 23:31:11.07
バージョン管理システムに幻想を抱きすぎ
2020/11/23(月) 23:32:36.58
>>416
そのコミットは捨てといて他のところをいじるってのができるだろ。
コンフリクトがどれくらい致命的かわからんのだから一般にそのコミットを入れないで他をいじるってのが、
中央管理だとやりづらいってことだ。
一人で一点だけ見てればそういうことはないんだろうが。
2020/11/23(月) 23:54:47.57
コーンフロストなのかコーンフレークなのかどっちや
2020/11/24(火) 00:18:56.24
コーンフロスティやろ
421仕様書無しさん
垢版 |
2020/11/24(火) 00:36:57.89
gitなんて大した技術がいるものでも無かろうに
未だに触ってないのはよっぽど頭の固いやつだけだ
2020/11/24(火) 01:11:49.88
ドキュメントのバージョン管理ツールください
末端にはマイナーバージョン3つくらい違うやつしかこない
2020/11/24(火) 01:15:01.14
>>422
降ってきたドキュメントの整理したいって意図？
ドキュメント作る側で管理してないとほとんど恩恵無いんじゃないの
2020/11/24(火) 05:35:50.23
つ えんぴつ

つ ノート
2020/11/24(火) 09:36:52.71
>>413
パクられた人 「おい、ドロボー。カネ払え。」
2020/11/24(火) 13:45:06.93
最新バージョンを編集してくれと言われたから、コミットハッシュはどれですかと聞いたのに、
とにかく最新バージョンをいじれの一点張りの馬鹿がいたりする。
自分らの使ってるものなのに何もわからんって輩が巷には多い。
2020/11/24(火) 14:06:15.13
最新バージョンをいじればいいんじゃないか
特定に何の情報が足りなかったんだ
2020/11/24(火) 17:06:48.56
>>426
最新バージョンという情報で十分だろ
2020/11/24(火) 17:24:10.92
>>421
何使おうが他人の勝手だろう。
既に触っているべきだとか原理主義的で脳みそカッチカチだなw　リアルで馬鹿すぎw
2020/11/24(火) 17:28:43.49
>>426
おまえもわかってないじゃないか
2020/11/24(火) 17:31:04.05
俺も最新バージョンで良いと思うが、最初に言質をとっておかないと
「あとでそんなこと言った記憶はない」って暴れだして面倒だろ
2020/11/24(火) 17:39:15.38
社内でめんどくさすぎる
2020/11/24(火) 17:39:37.42
天才 「できましたー」

バカ 「最新、最新のやつ編集しといて」

天才 「branchが最新だったので編集しましたー」

バカ 「はあ？masterの最新のつもりで言ったんだよ！」

天才 「なら最初からそう言えよ( ﾟдﾟ)､ﾍﾟｯ」
2020/11/24(火) 18:56:12.09
>>433
チェリーピックで大体対応できるだろ
2020/11/24(火) 19:20:13.46
>>434
馬鹿
2020/11/24(火) 19:21:29.53
エスパー要素が必要になるよな
2020/11/24(火) 19:28:07.79
>>433
特定のbranchとmasterが逆の方がありそうじゃね?
2020/11/24(火) 19:30:59.16
>>434
賢いな
439仕様書無しさん
垢版 |
2020/11/24(火) 19:41:01.37
チェリーピックって何か響きがやらしい
https://i.imgur.com/6jvYwHM.jpg
2020/11/24(火) 21:26:36.79
>>439
やらしい事に現実世界だとあと一歩と言う所でなかなかチェリーピックし放題にはなら無いもんなぁ
2020/11/25(水) 02:59:49.80
masterじゃなくてmainですわよご主人様♪
2020/11/25(水) 07:55:55.19
え？


ﾔﾊﾞｲﾔﾂｷﾀ・・・？
2020/11/25(水) 17:05:20.71
>>431
開発スピードが速いと毎日幾つもコミットがあるので
コミットハッシュなんか決まるわけないだろ
2020/11/25(水) 17:06:33.69
だいたい同じコミットハッシュなんか複数のブランチに存在する
コミットハッシュを聞いても最新バージョンにはならない
2020/11/26(木) 12:52:49.88
なぜSQLiteはソースコード管理にGitを使わないのか？
https://www.sqlite.org/whynotgit.html
2020/11/26(木) 12:58:31.66
おまえが使える技を全員が使えるなら使ってる
おまえしか使わないものを全員は使わない
447仕様書無しさん
垢版 |
2020/11/26(木) 14:32:18.88
>>445
This article is not advocating that you switch your projects away from Git.
You can use whatever version control system you want.
If you are perfectly happy with Git, then by all means keep using Git.
But, if you are wondering if there isn't something better, then maybe try to understand the perspectives presented below.
Use the insights thus obtained to find or write a different and better version control system, or to just make improvements to Git itself.
2020/11/26(木) 15:20:06.44
>>447
社交辞令みたいなもんじゃん。
なに慌ててるの？ｗ
ひょっとしてバレたら困ることでも書いてあったのかな？ｗｗ
2020/11/26(木) 15:27:16.73
>>443
じゃあ入れるタイミングテキトーでいいんすね？って聞くと大抵文句言い出すんだが。
2020/11/26(木) 16:20:18.66
>>449
それgitの問題か？
2020/11/26(木) 18:32:41.86
> to understand the perspectives presented below.
肝心の理由もここにかいてくださいな…
452仕様書無しさん
垢版 |
2020/11/26(木) 19:10:47.04
フォッシルかギットか？
って話なのでSVNとかCVSとかVSSは問題外
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況