Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
2020/10/17(土) 15:57:09.67
そもそもマージってソース管理ソフトの役割じゃないよね
というか元ソースを変更しようとしている人を検知して欲しいんだわ
エディタレベルで連動してくれよ
96仕様書無しさん
垢版 |
2020/10/17(土) 16:00:54.70
SVNしか使えない老害が一人で粘着してるだけ
2020/10/17(土) 16:04:30.74
>>95
自動マージはソース管理ソフトの役割だぞ
98仕様書無しさん
垢版 |
2020/10/17(土) 16:13:16.35
>>94
マージトラッキングならかなり前からある
2020/10/17(土) 17:01:40.21
githubの話は？
2020/10/18(日) 10:23:39.51
>>88
>>92
無くてもヘーキで即、開発終わりました
gitやgithubは1人開発には不要だから、unitテストで自動化くらいしておきなさい
ソースコード嫌いなのは判ったからw

1〜3名くらいの人数限られているpjだとgit構築するより svn+Junitとかの方が納期通りの進捗に有用だから
2020/10/18(日) 10:25:55.89
つかNTTDの政策投資銀行案件に性能試験参加したがgitと名のつくものは使用しておりませんでした。
svnで十分だそう。
2020/10/18(日) 10:40:41.17
githubも組み込んでCIまわすっていうのはある程度の人数超えたら有効かもしれんが
1人でやるなら構築に時間かかりすぎて無駄じゃないの？
年単位で担当するならともかく普通は３か月でしょ？
開発環境構築するだけで３か月終わっちゃうよ
2020/10/18(日) 10:41:45.62
ワイも役所仕事でgithubは使った事ないな
イケイケのWEB系だけやで
WEB系と言うても業務系じゃなくてネットショッピングとか本物のWEB系ね
104仕様書無しさん
垢版 |
2020/10/18(日) 12:12:30.05
SVN使うメリットがないので使わない
105仕様書無しさん
垢版 |
2020/10/18(日) 12:20:01.54
ここの老害はSVNで十分と言ってるだけ

SVNが特別gitと比べて簡単なわけでもなく
高速でもなければ便利でもない
だから廃れた
106仕様書無しさん
垢版 |
2020/10/18(日) 12:24:44.50
老害なんてその内消えるから気にすんな
2020/10/18(日) 12:40:30.61
廃れるも何も
使ってるのおまえらだけだよ
2020/10/18(日) 13:51:59.86
もうこれ単なる老害スレだなこれ
2020/10/18(日) 14:55:58.23
git使ってほしいヤツがgithubスレで騒いでgit使わせようとする
ギトハラ
110仕様書無しさん
垢版 |
2020/10/18(日) 15:14:04.84
引退してくれればそれで良い
2020/10/18(日) 15:31:31.86
おっさんだがgitが普及して本当に楽になった
2020/10/18(日) 15:57:54.46
チームにgit使えない老人が一人いたら本当に迷惑なんだよな
113仕様書無しさん
垢版 |
2020/10/18(日) 16:26:19.97
逆張り厨って脳障害あんの？やっぱり
病気だろこれ
2020/10/18(日) 16:29:23.94
新しいこと覚える気のない奴ってこの業界向いてないだろ
2020/10/18(日) 17:34:27.57
>>105
高速とか必要無いでしょw
そもそもアンタの仕事、そんなに早くないし

一つ画面と周辺モジュールとかしばらく全部ロックっちゃう無能だから誰も共有しませんてw
2020/10/18(日) 17:37:49.46
でもさsvnとvssで20年近く前からある機能をgitに置き換えただけで今さら何か特別視するアンタ達ってw
相当遅れてないか？
git担当って富士通で2年目新人の仕事だったぞw
2020/10/18(日) 17:47:04.32
何でもかんでも共有化だからスキル詐称が1人混じってると3カ月目にはロックだらけになって、手を付けられない部品が増えて来るだけで、モジュールクラス単位で切り離しが始まると。

今のプロジェクトとかどうせ銀行案件でもプログラマ4〜5人しかレギュラーいないんだから貴重なプログラマリソースを1人やらせてないで、gitにしろhubにしろテスター辺りから1人持って来て管理だけやらせればイイ。

ただ仕事の時間をgitに逃げてるようなプログラマだから、成果量は大した事無いし、さほど使えないのは承知だけどな。

個人的にはsvn、redmine、winmergeで十分。
差分リビジョン表示されればOKですわ。
2020/10/18(日) 17:51:27.97
こんなとこで使えと言わなければならないほど使われていないのが現状で
採用している企業が常識だー勉強しろーと数年わめいて名前だけは定着したけどうちの会社では使ってない
ジットって間違えて読んでる人たまにいるよね
119仕様書無しさん
垢版 |
2020/10/18(日) 20:31:09.00
言語もCOBOLで十分とか言いそう
2020/10/18(日) 20:43:51.00
二年目の新人が正しくマージできるなら大したもんだ
怖くてみな逃げているというのに
2020/10/18(日) 21:36:24.76
マージはマージする技術云々じゃないからな
コードをマージ可能な適切な修正内容にするのは難しい
初心者は一気に大量の修正を多なって、無関係な修正も多数入れ込むから
マージが怖いとかじゃなくて、適切な修正を行うのが難しい
122仕様書無しさん
垢版 |
2020/10/18(日) 23:25:06.56
そのうちVisualSourceShredderでも十分とか言い出しそう
2020/10/19(月) 00:38:38.24
>>119
事務処理やるのにCOBOL以上にやれる言語は皆無だよ
2020/10/19(月) 07:32:12.30
>>119
COBOLが適切な場面もある
言語の選び方は２種類ある

・案件に応じて適切な言語を選ぶ
・自分が得意な言語でごり押しする
125仕様書無しさん
垢版 |
2020/10/19(月) 08:46:03.14
COBOLでできる事は他言語も可能だから選ばれない

レガシーシステムの保守だけで関係ある言語
2020/10/19(月) 09:04:55.77
唯一無二と証明されるCOBOL
2020/10/19(月) 09:24:58.86
必死にCOBOLワールド設定してマウント取ろうとしてるサマが草
2020/10/19(月) 09:48:28.40
必死のgitワールド in GitHubスレ
2020/10/19(月) 09:50:40.93
COBOLが得意な場面で他の言語が出てくる余地があるのかな？

例えば単純計算の大量バッチ処理
むしろ何でも「出来ます」的な言語じゃやらせる意味がない

そもそもCOBOLは特定分野で最速なのがメリット
Javaみたいな汎用言語はその器用さゆえに速度を犠牲にしてるんだよ
速度的に対抗できるのはCぐらいじゃないか
130仕様書無しさん
垢版 |
2020/10/19(月) 09:54:15.97
COBOL vs Git

ファイッ！
2020/10/19(月) 12:04:03.84
>>129
> COBOLが得意な場面で他の言語が出てくる余地があるのかな？


動作環境買わんとアカン時点で終了
Windowsだけで動作するC#、VB.net コスパ最強だろ
2020/10/19(月) 14:11:27.35
>>123
COBOLの最大のライバルはSQL
2020/10/19(月) 20:23:52.40
Web系の人間は世界が狭いので若造が多いので
LinuxでJavaでGitな世界だけが標準だと思い込んでる（Java部分は何かWeb系っぽい歴史の浅い軽薄な言語に置き換え可）
そして詳しいはずのGitも個人レベルでしか使ったことがなく、安易にpush -fしてトラブル起こす
2020/10/19(月) 20:45:01.42
>>133
レッテル貼りしようとしても無駄だよ
2020/10/19(月) 20:51:54.91
>>133
お前push -fしてトラブル起こしただろｗ
136仕様書無しさん
垢版 |
2020/10/19(月) 21:00:17.34
これだから老害はw
2020/10/19(月) 21:07:19.87
新人なんでGithubを使わない共同開発とか想像も出来ない
Githubなしでコードレビューとか自動テストとか
どうやってたの？
そういうの無しの暗黒時代だったわけ？
138仕様書無しさん
垢版 |
2020/10/19(月) 21:12:08.21
GitHubなら保護されたブランチの設定がある
特定ブランチのforce pushやブランチの削除を防止できる

必要があってforce pushする場合も--force-with-leaseの方がオヌヌメ
リモートに未知のコミットがある場合はpushに失敗するのでより安全

そもそも普通のワークフローならメインのブランチを直接触らないはず
先にプルリクエスト作れよ
139仕様書無しさん
垢版 |
2020/10/19(月) 21:19:00.16
ジジイになると最新のもの受けつなくなるからな
2020/10/19(月) 21:36:06.72
>>135
なんでわかった！？
141仕様書無しさん
垢版 |
2020/10/19(月) 21:38:36.99
push -fごときで何やらかしたんだ？
2020/10/20(火) 00:11:49.67
>>131
何億もする汎用機は不要！（月額レンタル代の話な）
たかだか１０００万円買い切りのサーバーで何でも出来る！！
しかも技術者はPC界隈から集める事ができる！！！
オープン系はどれだけ画期的だったことか
そりゃ汎用機も落ち目になるよね

全国的な企業ですら十分こなせるほど性能も高くなってきたオープン系に
せいぜい数か月の素人を突っ込んで世界規模のトラブルを起こす
それが現代のITなんだよ

鯖寿司だって素人が握ったら人を殺す
2020/10/20(火) 00:12:29.37
push -fでトラブルを起こした事がない奴は素人
2020/10/20(火) 00:54:46.85
1行修正のプルリクが来た
→ うーん、これはちょっとまずいからこうしてほしいなぁ（1行の修正を俺が訂正）
→ 相手、俺の言うとおりに修正する

これ書いたの実質俺じゃん？ｗｗｗ
みたいなのってどうしたらいいんだろう
2020/10/20(火) 01:02:23.03
>>144
レビュアーを評価するシステムがないとすると、
誰もレビュアーをやりたがらなくなり
コードの品質にも影響がでるので、
ちゃんとレビュアーも評価する様なシステムを
作るように提言するといいと思う
2020/10/20(火) 01:54:58.69
>>145
いや、別に評価とかどうでもいいんだけどねｗ
そもそも俺のプロジェクトだし

相手のコントリビューションもありがたいんです。
でも、これ事実上俺が書いたことになってるじゃんｗｗｗってのが
相手はただ俺の言った通りに書いただけ

まあIssue来たって考えれば、修正コードの提案付きだから
それよりかはいいんだけどさ。コードマージすればcontributorsが増えるし
2020/10/20(火) 02:43:01.99
>>146
コメントに実質俺が書いたって書いとけばいいんじゃないの
2020/10/20(火) 02:49:35.35
>>146
ああ、OSSの話ね
自分のコードが他人のものになったみたいで微妙みたいな話か

じゃあその1行修正された問題を
自分が認識してたかどうかで考えたら？

もし認識してなかったなら、そのPR送ってきた人は
問題を見つけてくれた人な訳で、
しかもその発生場所も特定し修正案も出してくれてるなら
問題のうち9割は片付けてくれてる人なんだよ

コードという表層は自分で書いたものかも知れんが
そこに至るまでのことを考えたら、単純にこれ俺の！
みたいな気分にはならなくなるんじゃね？

もしその問題を認識してたら、自分をせっついてくれた
マネージャーだと考えるとか
2020/10/20(火) 04:42:03.02
>>147
マージの担当の人が天才的人物で良くそれやってるわ
まわりが萎縮しちゃうから良くないよな
前の会社でも天才と言われてたらしい
2020/10/20(火) 05:17:58.83
>>148
> 自分のコードが他人のものになったみたいで微妙みたいな話か

いや逆だよｗ

他人のコードなのに、俺が全部指示したら俺のコードじゃんｗ
2020/10/20(火) 05:19:01.77
> もし認識してなかったなら、そのPR送ってきた人は
> 問題を見つけてくれた人な訳で、
> しかもその発生場所も特定し修正案も出してくれてるなら
> 問題のうち9割は片付けてくれてる人なんだよ

バグじゃないんだけどなｗ
2020/10/20(火) 05:22:56.25
相手「こうしたら便利じゃね？」
→俺「せやな。でもそれ問題あるから、こうしてね」
→相手「はい」
→相手がコミットしたことになるが、そのコードは俺が支持したものｗｗｗ
→さらに俺が近々同じ行を別の目的で書き換える予定ｗｗｗ
153仕様書無しさん
垢版 |
2020/10/20(火) 06:50:16.34
ギットなんて、ただのジジよけだろ？
2020/10/20(火) 08:55:14.02
相手：具体的な提案と解決策を提示
俺氏：「ちょっと変えて！」
相手：「OK」

俺氏ほとんど何もしてないんじゃ・・・
2020/10/20(火) 09:04:07.88
マージボタンを押したよｗ
2020/10/20(火) 09:05:03.58
フォルダに入れたぞ
2020/10/24(土) 10:37:01.33
>>95
マージを人がやるからミスる
2020/10/24(土) 11:12:29.71
>>157
これからはもうエディタを監視してマージを全自動にするべきだと思うんだわ
リアルタイムマージにするか、それともエディタの背景に他人が編集中のソースがゴースト表示されるぐらいやって欲しい
せめてソースの編集を開始したら自動的にリードオンリーのロックをかけるようにして欲しいぐらいだ
ルールベースでロックかけると絶対アンロック忘れが発生するしな
xlsをファイル共有してる時のロック具合がちょうどいいぐらいだわ
2020/10/24(土) 13:25:17.86
>>158
Githubをちゃんと使えてるならソースを複数人が
同時編集してても問題ないと思わね？
2020/10/24(土) 14:18:58.08
マージが一番難しいよな
誰が何の目的で何やったのか判断して、前後関係が見極めてマージしないといけない
コメントが適当な奴がいると泣きたくなる
2020/10/24(土) 14:41:06.21
> 誰が何の目的で何やったのか判断して、前後関係が見極めて
それはマージと全く関係ない話
マージしなくても修正全てに当てはまること
162仕様書無しさん
垢版 |
2020/10/24(土) 14:47:13.43
ファストフォワードなら問題ない
163仕様書無しさん
垢版 |
2020/10/25(日) 20:37:11.64
github cli 使ってる？
2020/10/25(日) 20:41:45.74
使ってない
2020/10/25(日) 21:10:45.75
使ってる
2020/10/26(月) 20:41:22.77
>>160
>誰が何の目的で何やったのか
それをコミットログに書かないやつを死刑にするだけでいいだろ
2020/10/26(月) 20:59:45.53
>>160
プルリク見ろよ
2020/10/27(火) 18:09:37.33
こまめにprだしてこまめにマージすればいいだけじゃないのか
169仕様書無しさん
垢版 |
2020/10/28(水) 22:42:43.03
Gitない時代にコードレビュー自動テストどうやってたん？って書き込みあったけど
昔はコードレビューも自動テストも仕様書すらなかったからな
2020/10/28(水) 22:49:59.20
gitができたのは2005年だ
2020/10/28(水) 22:50:45.09
junitの登場は2002年
2020/10/28(水) 23:32:27.84
>>169
リーマンの頃に既にユニットテストはやってたが。
173仕様書無しさん
垢版 |
2020/10/29(木) 00:30:58.23
単体テストなんて昭和の頃にはやってた気がする
2020/10/29(木) 03:10:21.96
>>169
嘘つき
2020/10/29(木) 07:59:57.94
>>169
やり方知らなかっただけと言うオチで恥を晒してしまったね
2020/10/29(木) 09:07:09.39
>>169
いきなりgitになってからできた文化じゃないぞ
2020/10/29(木) 15:38:38.73
少なくともコードレビューはCOBOLの時代にやってた
自動テストもMSXでやってた
2020/10/29(木) 15:42:53.51
単体テストってさ
ビルドして実行が手軽に出来ない開発環境においては
滅茶苦茶有効だよな
「次のビルド予定時刻は２時間後です」みたいな規模の開発あるじゃん？
下手すりゃ１日１回とかね
それでも単体テストはやらせてくれる
そういう環境に放り込まれたら単体テストってむしろ手軽に実行できる存在なんだわ
2020/10/29(木) 15:50:33.19
>>160
＞マージが一番難しいよな
＞誰が何の目的で何やったのか判断して、前後関係が見極めてマージしないといけない
＞コメントが適当な奴がいると泣きたくなる

ブランチのマージはキツいかもね
2020/11/03(火) 11:48:44.40
業務で使う場合大抵のケースでsvnの方が直感的で使いやすい。gitはlinuxカーネル開発時にsvnだとパフォーマンスが出ないから開発された経緯があった記憶があるが、ssd登場によってもはやパフォーマンスも対した問題じゃ無くなると、もうsvnのうな中央管理で良いじゃんってなる気もする。
2020/11/03(火) 12:54:13.57
どうやってsvnでrebaseするの？
直感的かどうか以前に、重要な機能がsvnにはない
2020/11/03(火) 22:47:26.24
>>181
rebaseの恩恵ってコミットした単位でログが見やすいってだけで、実質は対して変わらないと思うんだが、むしろそれが重要になるケースを知りたい。

svnは分散して作業するって概念が無いから、必ずどこかmerge元のツリーに細かいコミットログが残ってるから、仮に細かく見たければそっちを見に行けば良い。逆にtrunkのログはスッキリして見やすいし。

gitだと個人やチーム単位のリポジトリで開発進むが、svnは分散して無いからsvnのコミットログさえ見とけば全ての状況を必ず把握出来るし。
183仕様書無しさん
垢版 |
2020/11/04(水) 10:22:16.97
>>182
>gitだと個人やチーム単位のリポジトリで開発進むが、

なんでpushしないの？また猿未満のチームの話？
2020/11/04(水) 11:19:50.02
>>182
> rebaseの恩恵ってコミットした単位でログが見やすいってだけで、実質は対して変わらないと思うんだが、むしろそれが重要になるケースを知りたい。

1. 他の人にレビューをお願いする時、または自分がレビューする時

　それぞれのコミットが意味のある単位で小さくまとめていればレビューしやすくなる

2. コミット単位で取捨選択できるようになる

　このコミットはOKだけど、こっちはいらないとか変更が大きすぎるので後に回そうとか言える
　必要なコミットだけ抜き出してプルリク作ってと言える

3. 他のバージョンやブランチに再利用しやすくなる

　最新バージョンで当てたパッチ＝コミットを旧バージョンにも適用したいから
　そのコミットだけ抜き出す（cherry-pick）がしやすい


このようにrebaseされてないと意味のある単位が分断されてしまって
レビューや再利用するときに大変になる
2020/11/04(水) 11:36:35.01
よくある話だが、ある機能を追加するためにコードを修正していた。
その機能追加作業を開始して数日後、直接関係ないバグを発見した。
依存性があるためそのバグを修正しないことには機能追加ができない。

このバグは他でも影響しそうだから、早くリリースしたいし
機能追加の修正に含めてしまっては、レビューの量が増えてしまう

だからすでに機能追加のコミットはいくつかあるが
バグ修正を先にリリースし、そのあとに機能を追加したように歴史を修正する

素早いリリースとレビューの負担が減るという大きな恩恵がある
2020/11/04(水) 11:38:44.15
>>182
> svnは分散して無いから
別の（顧客の）プロジェクトは、分散させないといかんよ
2020/11/04(水) 19:32:03.88
>>184
rebaseやるやつでそこまでコミット粒度をしっかり考えてる奴なんて見たことないがな。
2020/11/04(水) 20:52:31.67
>>187
俺がやってるが？
ってか、普段から適宜git rebaseでmasterからの修正に直したり
git add -pとかで適切なコミットに入れておかないと
マージするときにコンフリクト起こしまくって大変だろ
開発中はあちこち修正しなきゃいけなくて理想通りの順番で作業なんてできない
だから小さくコミットして入れ替えたり統合するわけだが
svnじゃ面倒でやってられんよ
2020/11/04(水) 21:52:57.52
>>188
馬鹿か？それ実質コンフリクトしてるわけだから意味ないだろ。
2020/11/04(水) 21:56:17.10
それコーンフレークやないかい
2020/11/05(木) 07:31:01.43
>>189
コンフリクトしてないことにたいして、
実質コンフリクトとはどういう意味ですか？ｗ
2020/11/05(木) 07:46:00.75
それコーンフレークやろ
2020/11/05(木) 09:39:49.00
>>184
なるほど、でもレビューの話しとかってtrunkへマージする前の話しだから、svnだと開発用のブランチで済んでいる前提。

そのブランチ上には細かい単位でコミットログが残っている。

分散的なgitだと各拠点でそれが済まされている可能性があるのでその痕跡を中央に持っていくためにrebase必要だが、svnだとシンプルに全員が中央で作業してるから、そもそも不要かなと。
2020/11/05(木) 12:12:13.01
>>193
> そのブランチ上には細かい単位でコミットログが残っている。

- ○の修正
- ○の修正にバグが有った訂正
- △の修正
- ○の修正は筋が悪かったので◎として実装し直し
- □の修正
- △の修正にバグがあったので訂正

みたいな細かいログ見てもレビューできないし
途中の試行錯誤なんて見ても意味がない

意味があるところだけ残してレビュー依頼しろ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況