Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
261仕様書無しさん
垢版 |
2020/11/15(日) 00:20:49.00
SVN脳だとresetやrebaseがまず理解できない
2020/11/15(日) 05:51:22.35
svn+ローカルリポジトリ=git
と考えればsvn使いにもイメージしやすいと思うがなぁ
2020/11/15(日) 06:25:32.04
リポジトリが複数あるって気持ち悪くてダメだわ
やはり中央に一つであるべき
2020/11/15(日) 10:29:39.81
ソース管理の粒度ってどれぐらいでやってる？
・少しでも更新したら（ビルドができなくても）コミット
・ビルドエラーは関係なく、自分の中で区切りのよいところでコミット
・ビルドエラーが出ないところでコミット
・最小限の修正が終わるごとにコミット
・ある程度の修正群の１つのまとまりごとにコミット
・修正プロジェクトが完了するごとにコミット
・製品リリースごとにコミット

コミット（push）するタイミングってどうしてる？
2020/11/15(日) 11:46:41.95
粒度
2020/11/15(日) 12:00:46.81
>>263
分散管理ツールでも普通は中央レポを運用で指定してるもんだろ。大した問題じゃない。
てかいちいち中央と同期とるシステムのがめんどくセーわ
2020/11/15(日) 12:02:46.45
>>254
それは使えない方が馬鹿なんじゃなくて、教える方が馬鹿なだけ。
gitのコマンド全て教える必要なんてないし最低限必要なことはgitでなくても結局必要になる。
2020/11/15(日) 12:16:59.99
>>264
お前コミットメッセージ適当だろｗ

コードをながめたとき
いろんな修正がごっちゃになってると
わけわからなくなるだろ

意味がある単位に分けろ。
分離できるならなるべく分離しろ。
そして1コミット単位でリリース可能なようにしろ
2020/11/15(日) 12:19:58.66
だいたいコミットとpushのタイミングは別だ
pushとマージのタイミングも別だ

作業ブランチで小さくコミットしていって
最悪でも他の人に見せるとき、
区切りのいいときやCIにテストさせたいときにpushする
pushしても終わりじゃない。さらに修正を入れるのも普通
コミット追加して、rebaseして
作業ブランチはいくらでもgit push --forceしていい

そして作業ブランチが完成してテストもOKになったらマージするだろ
そうすりゃmasterブランチにそれら複数のコミットが取り込まれる
2020/11/15(日) 12:53:21.68
サーバのソースをリアルタイム修正してる（CTRL+Sで保存される先が本番サーバ）なんだけど
おまえらは違うの？
2020/11/15(日) 13:01:37.66
別ブランチが長く運用されてマスターと統合不可になってるのが嫌
2020/11/15(日) 13:23:02.89
管理ソフトが余計な管理増やしてる
2020/11/15(日) 20:34:16.02
>>264
ちなみに管理する側からすると毎日コミットしてって言ってる(gitならpush)。下手な進捗報告されるより一番手っ取り早くて確実。
274仕様書無しさん
垢版 |
2020/11/15(日) 21:13:56.18
>>270
そんなことして壊したらどうするんだ！
2020/11/15(日) 22:48:54.89
>>274
その緊張感がいいんじゃないか
自然とテストも増えるよ
修正して即テストが習慣になるし、ユーザーがいつどんな操作するかを考えながらコーディングするようになった
いいことばかり
2020/11/16(月) 03:20:35.20
> 修正して即テストが習慣になるし、

テスト実行するだけじゃダメだろｗ
バグってたら直せよ、時間をかけて
2020/11/16(月) 12:43:15.52
>>271
定期的にmasterからマージすりゃいいんじゃね？
2020/11/16(月) 13:51:29.67
>>271
svnだとrebaseができない（面倒くさすぎて事実上不可能）から
ブランチとマスターが剥離していっちゃうんだよね
2020/11/16(月) 14:45:25.62
乖離って言おうぜ
2020/11/16(月) 14:51:35.86
Ｇｉｔはローカルがすぐこわれて使いづらい
2020/11/16(月) 15:03:30.82
>>280
俺は壊れた事ないなぁ
何したら壊れたの？
2020/11/16(月) 15:35:01.64
ほかのブランチ見たらこわれた
チェックアウトしたらこわれた
ファイルセーブしたらこわれた
こわれまくり
2020/11/16(月) 15:36:35.50
自分で改行コード勝手に変換しといて管理外でファイルが変わってるから扱えないとかエラー吐きやがる
人間なら首絞めて殺してるところだ
2020/11/16(月) 16:02:07.51
何もしてないのに壊れた
2020/11/16(月) 16:06:02.03
svnは何をしてもなかなか壊れなかった

イケてるエンジニアを装いたい人間の不誠実な態度が
Ｇｉｔの進歩を遅らせてきたにちがいない
2020/11/16(月) 16:43:44.61
壊れないかどうかじゃなくて、
開発しやすいかどうかだ。重要な点は。

svnは開発が苦痛で仕方なかった。
ソースコードを書く時に間違えないことが前提になってる
「これでいいかなー、エンター・・・あー、あれ忘れてたー！」
という苦痛がsvnには常につきまとってた
2020/11/16(月) 17:28:59.60
svnはまるでCTRL+Sのように頼れるやつだった
gitはフォルダ丸ごとコピーと同じノリ
2020/11/16(月) 17:57:16.39
gitはフォルダ丸ごとコピーと同じノリとは
どういうことをしてるの？
2020/11/16(月) 18:12:58.10
仕組みを理解する頭がなく、
ふんわり感覚で理解したつもりになってます、
という告白だろ
2020/11/16(月) 20:11:57.07
>>236
マイクロソフトがしょぼい会社？？？
2020/11/16(月) 20:54:04.30
>>278
コンフリクトして無い限りsvnでも1コマンドだと思うんだけどな。rebaseの方が楽な気はするけど
2020/11/16(月) 21:00:28.63
>>280
分かる。操作ミスなんだろうけど、調べるのも面倒だしローカルgitが絶対に健全なのかどうかを(チームメンバと同一状態かいなかを)確認する手段が無いから結局cloneしちゃう。
2020/11/16(月) 21:02:14.97
コーンフレークやないか
294仕様書無しさん
垢版 |
2020/11/16(月) 21:39:45.00
>>292
git checkout master
git reset --hard origin/master
すれば楽になれるのに
2020/11/16(月) 21:46:14.76
>>291
> コンフリクトして無い限りsvnでも1コマンドだと思うんだけどな。rebaseの方が楽な気はするけど

複数人で作業してるなら、細かくメンテナンス（マスターに追尾）しない限り
コンフリクトは必ずと行っていいほど発生するよ

細かくメンテナンスしてればコンフリクトは発生しないけど
svnじゃそれは事実上無理
2020/11/16(月) 23:32:58.37
>>295
trunkへのコミットを自分のブランチにマージするだけじゃない？ソフトが自動で差分見てマージしてくれてコンフリクト起こった所だけ専用のdiffソフトが出てマージの仕方を選ぶだけ。気持ち悪くなったらtrunkから再度ブランチ切って自分のコミットを古いブランチから選択してマージしても良いし、複数コミットまとめても良いし。gitだとコンフリクトしてももっと楽？
2020/11/16(月) 23:36:36.51
>>294
経験的にそんなぐらいじゃ治らんな。自分の操作が相当適当って事かも知れないけど。
2020/11/17(火) 00:08:17.74
>>296
どっちからどっちにマージしようが
自分の変更と相手（master）の変更で同じ箇所をいじってればコンフリクトになるんだよ
コンフリクトの数が少なければ修正は楽
だからこまめに修正しないといけないが、それはこまめにtrunkをマージしてればいいってわけじゃない
そんな変更が多数入ったブランチなんてレビューできねーだろ

自分の担当の開発でここをこう書き換えました。
そして開発中にtrunkが更新されたのでマージしてこう書き換えました。
みたいな話をされても困る
trunkの更新の話なんて関係ないんだから

最新のコードからの修正という形にしないとレビューが困難になる
2020/11/17(火) 00:11:06.47
>>206
> 気持ち悪くなったらtrunkから再度ブランチ切って自分のコミットを古いブランチから選択してマージしても良いし、
それがrebase。簡単なやつなら1コマンドですぐ終わる。

> 複数コミットまとめても良いし。
それもrebase。作業中にコミットをまとめておくことで
「trunkから再度ブランチ切って自分のコミットを・・・」の自分のコミットを
少なくできるから楽になる
2020/11/17(火) 00:48:41.72
>>297
それってcloneするのとほぼ同義だぞ
やったことないでしょ？
2020/11/17(火) 03:58:05.93
それコーンフロストやないか
302仕様書無しさん
垢版 |
2020/11/17(火) 07:59:52.76
>>297
git fetchした？
2020/11/17(火) 08:03:19.59
みんな当たり前のようにコンソールコマンドベースで話してるが
ＧＵＩ使ってないのか
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
コーンフレークやな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。