Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
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は便利ツール
236仕様書無しさん
垢版 |
2020/11/09(月) 14:12:22.32
GitHub社みたいなショボい会社に会社の生命線を預けるのが意味不明
自社でGitHubっぽいサービス作れば良くね？
2020/11/09(月) 14:14:11.37
GitHubはMicrosoftに買収されますた
2020/11/09(月) 14:28:19.07
>>236
マイクロソフトがしょぼいってw
2020/11/09(月) 17:01:56.39
CIで時間がかかっていってGitHub Actionsに乗り換えてるんだけど
今更だがGitHub Actionsすごすぎね？

オープンソースなら無料なのに並列数20で制限なしとか
やっぱクラウド自社で運営してるMicrosoftは違うな
買収されてからかなり良くなってる
2020/11/09(月) 18:00:57.65
Azure DevOpsのパイプラインがよくできてたからノウハウがGitHubに生かされてるね
2020/11/09(月) 20:25:43.01
他のCIサービスだと、無料で大量のテストをやるのは気が引けるんだが
金持ちマイクロソフトなら遠慮しないですむ
2020/11/13(金) 23:03:57.08
どうせgithub使うんだから結局commit早くたってclone/push/pull/fetchでネットワークアクセスして遅いだろ。
まあgithubと言う名前だけどsvn-serverとしてそのまま動くからなぁ。結局、みんな分散分散言っといて中央リポジトリがシンプルで大好きなんだよな（笑）
2020/11/14(土) 08:00:00.83
分散も中央も両方できるからgitを使うんですよ。
gitは中央を捨てたわけじゃありません。両対応なんです。
それだけでもsvnより優れてるってわかるでしょう？
2020/11/14(土) 08:48:43.93
svnよりgitの方が多機能なのは誰でも知ってるし否定もしないしgithubは便利。ただgithubしか知らないのは微妙
2020/11/14(土) 11:03:52.47
svnで十分派の皆さんはとりあえずこの辺に目を通して、svnとgitの考え方の違いを知ってから文句言っていただきたい

https://qiita.com/kaityo256/items/81e7951a1ca2706955a4
2020/11/14(土) 11:57:54.54
自分のコミットでプロジェクトが滅茶苦茶になるかも
それを集中攻撃で責められるかもと思うと
恐くてコミットできません
2020/11/14(土) 11:59:40.90
gitを使えばプログラムの競合が起こらないと信じ込んでいた
新人でもない中堅ＰＧがいっぱいいた
2020/11/14(土) 12:58:07.48
>>247
そうか。だがそれはgitの問題ではないし、gitが優れていることに違いはないよな
2020/11/14(土) 15:31:57.22
gitのせいじゃないとか優れてるとか劣ってるとか
そういうのはいい

問題があるのを認識してないのが問題なんじゃ
250仕様書無しさん
垢版 |
2020/11/14(土) 18:03:44.43
そんな会社辞めて転職しろ
2020/11/14(土) 18:06:38.63
>>249
人の問題か、技術（git, github）の問題をかをはっきりさせてるだけ
2020/11/14(土) 18:24:34.54
すぐ人の問題に帰着しようとする脳が腐った論法は富士通のにおいがする
2020/11/14(土) 18:36:27.00
>>252
何があったか知らないけれど
社会のせい会社のせいにするのがキミだ
2020/11/14(土) 20:36:40.04
人の問題は人の問題で、そういう問題があるっていうのは事実でいいんだよ
うちの社員は馬鹿ばっかりだから、うちの会社では導入できません。というのも
導入できない立派な理由

だけどそれを、うちの社員は馬鹿だからgitは難しい。つまりgitは難しいという問題がある。
gitの問題だ。って問題をすり替えてはダメ。

問題をすり替えると、問題の解決策が変わってしまう。
うちの社員が馬鹿という問題だって理解していれば、
その馬鹿に勉強させるか、クビにして入れ替えるっていうのが解決策となる
問題をすり替えてしまうと、本当に解決しなければいけない問題が見えなくなってしまう
2020/11/14(土) 21:45:31.43
>>252
君は楽観的すぎる
Fだけじゃないんだよ
2020/11/14(土) 21:56:06.65
>>245
内容が微妙だった。mergeとか絶対にどっちでも変わらないし。
2020/11/14(土) 22:03:52.34
svn脳といえば、
・ブランチを作成するのに躊躇する
・マージしてからテストする
・古いコードでの上書きが頻繁に発生する
2020/11/14(土) 22:46:43.00
>>245
今ですらsvnとgitを併用してるやつの記事なんて信用できるのか？
2020/11/14(土) 22:47:13.37
git脳がsvnｗを使った場合というケースが抜けてる
2020/11/14(土) 23:26:32.62
>>258
今の話なの？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況