X

Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
2020/11/17(火) 08:41:25.94
GUIの利点は一覧性が高いことだから、過去のcommitの確認の時とかには使ってる
2020/11/17(火) 10:03:53.19
普段はvscodeやtortiseGit
特にIDE連携は便利でいいね
2020/11/17(火) 14:44:15.25
>>303
GUI使ってるけどみんな使ってるGUIアプリが違うからコマンドで説明した方が多くの人に通じるだろ
コマンドが共通言語みたいなもんよ
2020/11/17(火) 20:12:49.04
>>299
納得した。それは間違いなく一手間減る。svnだとGUI側で過去コミットログ引っ張って来て連続自動コミットするしか方法が無い。
2020/11/17(火) 20:16:06.47
svnでもgitでも操作方法はたくさん資料があるんだけど
運用方法はないんだよね
309仕様書無しさん
垢版 |
2020/11/17(火) 20:25:29.78
git-flow
2020/11/17(火) 20:28:13.52
ムチムチ
2020/11/17(火) 20:42:12.46
https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf

お好きなものをどうぞ
2020/11/17(火) 21:00:11.68
>>307
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Keeping a Branch in Sync

svnだとtrunkとの同期とtrunkへの書き戻しはコマンド1つで自動で出来るが、ただコミットログは一つにまとまる。feature branchを作って、それをtrunkヘ戻す時にあえて複数のコミットだったかの様に戻す必要性は無いって思想なんだな（もし見たい場合は開発当時のfeature branchの履歴見てねって事）gitだと開発当時の履歴見てねって出来ないから履歴ごとmerge必要なのか。
2020/11/17(火) 22:19:57.83
svnを使ってた頃は、svnの使い方が全くわからなかった
間違ったとき修正が大変でこんなんでどうコミットしていけば良いんだよと思ってた
開発がすごくやりづらかった

svnの使い方がわかってないだけかと思っていたが
gitになってからやりたいことができるようになったので
svnというツールが悪かったんだなぁと気づいた
2020/11/17(火) 22:28:57.74
巻き戻しの大変さに違いがあるもんか
315仕様書無しさん
垢版 |
2020/11/19(木) 06:46:40.76
やっぱり、こういうのは、ちゃんと管理者にやらせなきゃダメだな。
専任の管理者を決めて、コミットだのプッシュだのマージだのは
すべてそいつにやらせるべし。
技術者には一切触らせちゃいけない。

そういう管理こそ、新人にでもやらせればいいんだ。
316仕様書無しさん
垢版 |
2020/11/19(木) 07:29:18.47
マージ担当（笑）がいる会社って都市伝説じゃないの？
2020/11/19(木) 08:33:06.54
コミットを専任の担当者が？
マジで？
2020/11/19(木) 10:16:16.83
コメット担当者ってwww
2020/11/19(木) 10:29:43.14
俺はコメント担当者だった
2020/11/19(木) 10:31:57.09
コメットさん
2020/11/19(木) 11:04:34.45
60代がわいてでたぞー
2020/11/19(木) 11:04:40.58
こんにちはGitHub普及担当の皆さん
2020/11/19(木) 11:06:56.58
パワーをメテオに！！
2020/11/19(木) 11:10:50.51
キングベヒーモスさん
2020/11/19(木) 12:27:57.37
>>316
あるよ
インテグレーションチームて呼んでた
マージして動作確認するチーム
2020/11/19(木) 13:15:00.86
>>316
ソース管理担当者はいたよ
マージだけじゃなくてコミット含めて全部その人を通さないと出来ない

あと何でも仕様を知ってる仕様担当者、コーディングで困った人助ける担当者、新しい派遣の席を作る椅子担当者もいた
派遣をエレベーターの下から上に案内するだけの奴もいたけどあれはただの多重派遣か
2020/11/19(木) 13:47:13.39
マージする担当者を置くのは意味分かるけどコミットの担当者は理解不能だな
2020/11/19(木) 13:50:29.23
コミットするのに判子集めるの？
2020/11/19(木) 14:17:28.30
責任者ってことだよ
バグをリリースしたら全部コミットの担当者の責任になる
330仕様書無しさん
垢版 |
2020/11/19(木) 14:20:10.95
責任のなすりつけ合い乙
2020/11/19(木) 14:27:57.80
最低な職場やな
332仕様書無しさん
垢版 |
2020/11/19(木) 19:10:47.14
そう、責任者をちゃんと決めないから、
責任のなすりつけ合いになるんだ。

ギットはそういう傾向がさらに強い。
ギットさえあれば管理者が要らないぐらいに思われてるようで。
ルール厨なんてのが涌くのがその証拠。
2020/11/19(木) 19:15:41.13
これどうするんですか？みたいに
ちょっとずつ質問や確認のふりして
相手をだまくらかしつつ要求範囲を広げていくのは
ＳＥの必須技術といえよう
334仕様書無しさん
垢版 |
2020/11/19(木) 19:49:34.69
責任者はやりたくないけど自分の合意無しに何かやるとキレて足引っ張りモードに変形して
そういう時だけ生き生きと活動するアニマルだらけの動物園
2020/11/19(木) 20:22:32.36
>>332
管理者「ルールを作るで！」
2020/11/19(木) 22:17:49.43
わいがルールや！
2020/11/19(木) 22:22:08.10
非正規のルールは俺が決める by 派遣王 竹中
2020/11/19(木) 23:39:19.33
git我慢の子であつた
2020/11/21(土) 18:46:59.52
>>326-327
githubをFreeで利用してる貧乏ゴミカス企業かな
「Team以上で利用して毎月xxドル払うのが嫌だ」っていう貧乏奴がいて
全員同じアカウントでチェックアウトとかコミットとかしてた

誰がコミットしたか分からんからコメントルールとかできたが守られないままデグレが起きたんで
責任者を用意してそいつにマージを全部投げてたら、そいつが出て来なくなってリリース遅れますってあったわ
2020/11/21(土) 19:25:43.27
コンフリクトの修正を恐れるやつは大抵コード内容を理解していない。
2020/11/21(土) 20:18:56.90
そもそもコンフリクトというものが起きることが理解できない
ソースごとに担当を割り振るもんじゃないのか？
2020/11/21(土) 20:24:30.86
>>341
いや、機能ごとに割り当てだろ
2020/11/21(土) 20:26:16.20
それコーンフレークとちゃうか
2020/11/21(土) 20:28:13.90
>>341
ソースごとって？

一つのプロジェクトを二人以上の人が担当することなんて当たり前だろ？
その人たちが同時に２つ以上の機能を開発することも当たり前だろ？
そうすりゃ共通部分に同時に手を入れることだってあるだろ
コンフリクトがおきないと思ってる方がおかしい

ちなみに一人で開発してても、同時に複数の機能を作ったりすることはあるからな
特に開発中に気づいたバグ修正を先にリリースするとか

そうすりゃ、開発中に気づく、つまり今開発してる内容とバグが有る場所が近いわけで
その場所はコンフリクトする可能性が高くなる
2020/11/21(土) 20:35:02.51
そないやったらコーンフレークちゃうか…
2020/11/21(土) 20:57:05.06
>>342
そうか？
普通はソースごとに割り振りだろ
一つのソースに複数人が手を入れるなんておかしい

ソフトの要件を決める
↓
ソースごとの要件を決める
↓
ソースごとの担当を決める
2020/11/21(土) 21:10:45.19
>>346
> 普通はソースごとに割り振りだろ

だからソースってなんだよ？

具体的な例として、C言語、テトリスでググって検索して出てきたこれ
ソースコードが1ファイルしかない
https://github.com/kaneyann/Tetris
（ちなみに俺は関係者でもないし現在のコードも仕様も知らん）

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

と同時に他の人が一番下に落ちたときの膠着時間
すぐに固定されてしまうのを数秒間左右に動かせるように変更するとする

この２つの対応を同時にやるとき、
お前はどうやって担当を決めるんだよ？
2020/11/21(土) 21:14:33.38
>>347
ソースが一つなら担当は一人に決まってるだろ
2020/11/21(土) 21:16:09.10
>>348
つまりお前は同時に開発ができないって言ってるんだよ
現実的じゃない
大規模なゲームで一人で開発してるなんてあり得るか、アホが
2020/11/21(土) 21:20:59.95
コーンフロストやろ
2020/11/21(土) 21:23:06.17
例えば初期化処理とか複数人が一つのファイルを編集する部分だよね
2020/11/21(土) 21:32:19.46
複数人が開発するんだったらなるべくファイルわけるでしょ
大勢が同じファイルを編集するとかってソース管理ソフト使っててもできれば避けたい
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ブランチの履歴が失われると言うデメリットはある
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況