Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
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
> そのブランチ上には細かい単位でコミットログが残っている。

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

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

意味があるところだけ残してレビュー依頼しろ
2020/11/05(木) 12:15:40.41
>>193
？？？
「中央に持っていく」だけならpushでしょ？
rebaseは「細かい単位でコミットログが残っている」ようにするためだけの操作ですよ
分散型であることとは関係無い
2020/11/05(木) 12:32:32.18
>>194
ある程度まとめてレビュー依頼するなら、まとめたブランチで依頼すればいいだけ。と言うか、修正単位でブランチ切れば良いだけ。気に入らないならいくらでもブランチ切り直せば良いだけ。

なのでsvnでrebaseの機能欠落と言う訳じゃ無く、あまり必要性が無いと言う主張。
2020/11/05(木) 12:39:20.54
>>195
そうなんだけど、実運用で考えると、svn方式で何ら問題は(ほぼ)無いと思うって話し。

そもそもsvnだと分散して無いから細かいコミットも全部中央に残ってるから、どれをまとめようとか考える必要も無い。
レビューとか相手の立場でまとめたいならブランチ切って纏めれば良いが、細かいコミットもどこかのブランチには必ず残る。
2020/11/05(木) 13:02:47.25
>>196
> ある程度まとめてレビュー依頼するなら、まとめたブランチで依頼すればいいだけ。

そのまとめたブランチの中に>>194みたいなコミットが多数含まれていたら
レビューできねーだろ。まさかクソ長いコード全部見ろと？
2020/11/05(木) 13:07:15.14
> そもそもsvnだと分散して無いから細かいコミットも全部中央に残ってるから、どれをまとめようとか考える必要も無い。

「気に入らないならいくらでもブランチ切り直せば良いだけ。」
でしたっけ？大量の気に入らないブランチが大量に残ってますね。大量にｗ

「全部中央に残ってる」って言ったのはお前だからな
2020/11/05(木) 13:14:34.55
>>199
大量に気に入らないブランチが残ってる？
それで良いんだよ。何なら個人名とか入ったpersonalなブランチ切っても良いし、それがsvn。
2020/11/05(木) 13:15:39.97
>>200
本流にマージされないゴミブランチが残ってることで何の意味があるの？
手段と目的を履き違えているな
ソースコード管理ツールというのはボツ案を残す場所ではない
2020/11/05(木) 13:20:34.66
ついでに補足すると削除してスッキリする事も出来る。ただログには残るので復元は可能。昔のリポジトリでドキュメントが入ってるから今見たら80万コミット超えてるが運用上何も困っていない。
2020/11/05(木) 13:57:35.44
gitの話しかしてないな
Githubの話ししろ
メロンパンのスレで
メロンの話ししてるようなもんだぞ
2020/11/05(木) 14:59:56.30
やっぱりコーンフレークやないか
2020/11/05(木) 20:01:16.89
>>202
電気がない暮らしをしてる人は、電気がなくても困ってないと言うもんなんだよｗ
2020/11/05(木) 21:23:15.95
>>205
だからそれがあるなら知りたいんだよな。まあ便利なインフラが安いのは理解出来るが。
2020/11/05(木) 22:02:34.60
>>206
↓これに対するお前の反論は「俺はそんなものない世界で生きてるから不要」だろ？

184 自分：仕様書無しさん[sage] 投稿日：2020/11/04(水) 11:19:50.02
>>182
> rebaseの恩恵ってコミットした単位でログが見やすいってだけで、実質は対して変わらないと思うんだが、むしろそれが重要になるケースを知りたい。

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

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

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

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

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

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


このようにrebaseされてないと意味のある単位が分断されてしまって
レビューや再利用するときに大変になる
2020/11/06(金) 00:26:49.99
>>207
いや、1、2、3のどれも重要だとは思う。但し、svnで運用する場合は1、2、3のどれもmergeを使っても結構簡単に実現出来る（実現出来るし、そう言う設計思想だと思っている）。

例えばtortoiseSVNだとmerge元の細いリビジョンをチェックボックスで選択していけば、複数コミットを纏めてコミット出来て対した手間も無い。但し、何個も残したいコミットがあるものをtrunkへマージするのは、残したいログ個数分だけコミットが必要になってしまうが、しかし、そもそも、マージ元のブランチには開発時のコミットログが必ず残っているので、後で必要になってから開発時のブランチを見に行く事も可能なので、実開発ではあまり気を使う価値が経験上無かった。

書いてて思ったが、少し気になるのがtrunkへマージする人が開発した人と違う場合、trunkだけ見てると開発者の名前が登場しない事かな。
209仕様書無しさん
垢版 |
2020/11/06(金) 07:21:05.38
SVNの作者はなぜブランチをコピーとして実装するのがいい考えだと思ったのか

trunk, branches, tagsを使う標準に従ってない変な構成のリポジトリをgitに移行するのが難しい
2020/11/06(金) 07:50:12.59
GitとGihubの違い説明できないバカおる？
最近ガチで居たので気になった
2020/11/06(金) 10:42:41.97
このスレにいっぱいおるぞ。
むしろだれもGithubの話ししとらん。
2020/11/06(金) 10:46:10.49
>>208
あのさぁ「svnでも頑張ればできる」って言ってる時点で
ダメだってわかってるの？

お前が言ってるのって、ディレクトリ管理でもやれるって言ってるのと同じだよ
ああ、具体的に言ってやろうか？ 新しくブランチを作るのが1秒未満でできなければ苦痛
ブランチを切り替えるのが3秒でできなければ苦痛
ネットワークつないでないと作業できないのは大きな苦痛
2020/11/06(金) 11:26:24.94
svnの欠点はサーバーに大量のゴミコミットログが残ってることだな
宝探ししたいんじゃねーんだから
ゴミがたくさんあるのはデメリットでしかない
2020/11/06(金) 11:44:10.22
Githubについて話したいことがあるなら、話してもいいんだよ？
はい、みんな注目！
これから>210や>211がGithubについて皆が聴く価値のある話をするよ！
2020/11/06(金) 11:54:03.65
GitHub Actionsってオープンソースは全く制限無いの？
2020/11/06(金) 17:04:13.59
Githubにはライブラリ利用者としてお世話になっているけど、自分でソースコードをアップロードとか、他人のソースをコミットとかやったことない。
2020/11/06(金) 18:42:07.11
よくわからないからコマッタ
218仕様書無しさん
垢版 |
2020/11/06(金) 20:16:04.04
くまったくまった
2020/11/06(金) 23:50:06.90
しねばこまることはなくなるよ
2020/11/07(土) 06:39:38.71
COBOLと専用エディタの使い方だけ覚えていれば飯が食えた昔と違い、
今は山のように覚えることがあり、しかもどんどん増えていき終わることがない
こんな無理ゲーやってられない
自分はGithub以前にまずGitの使い方が覚えられなくて詰んでる
2020/11/07(土) 06:50:33.56
おれは最初にジットって教わったから間違えてジットって言ってしまって困る
2020/11/07(土) 09:38:19.33
>>220
基礎ができてないからそうなる
2020/11/07(土) 11:56:07.30
>>222
基礎つーても新しい技術の基礎だから世界が違う
木造平屋建て専門大工が超高層ビルを建てようとするようなもんだ
時代の境目に生きる者はつらい
2020/11/07(土) 13:09:29.15
>>223
そこまで大袈裟な違いではなくて、ずっとノコギリだけ使ってた人がチェーンソーの使い方が分からん、覚えられんと言ってるだけじゃね
2020/11/07(土) 13:23:16.40
Gitのオプションの多さに目が回る
あんな旧態依然としたコマンドラインツールのオプションを覚えるために
成長の止まった脳細胞を使いたくない
226仕様書無しさん
垢版 |
2020/11/07(土) 13:52:45.80
老害は言い訳ばっかり
やらない理由を作るのだけは優秀だな
2020/11/07(土) 13:56:18.39
>>226
やったうえで言ってるんだよ
言語覚える前にGitで詰んでる
2020/11/07(土) 15:40:44.09
>>225
普段使っている中でそんな大量のオプション使う必要あるか？
2020/11/07(土) 16:03:45.66
オプションなんて必要になった時点で調べればよい
どんなオプションがあるかだけなんとなく頭に入れておけばいい
2020/11/07(土) 17:05:45.45
今時の開発環境はgit対応してるだろ
日常で使う数少ないコマンドさえ覚えられないならGUIで操作するところから入ればいいのに
2020/11/07(土) 17:20:16.63
コマンドだるいならsourcetree使いなさい
2020/11/07(土) 17:35:50.87
歳のせいにするな、自分が無能なだけだろ
俺は40代だが普通にgitもGitHubも使ってる
GitHubの俺のリポジトリで一番スターが多いのは200オーバーな
2020/11/07(土) 19:10:56.21
評価してやるからURL貼ってみろ
2020/11/08(日) 11:05:35.42
>>227
gitでヒィヒィ言ってるのに言語が理解できるとは思えない
2020/11/08(日) 12:42:38.96
言語は必須
Gitは便利ツール
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況