Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
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
今の話なの？
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から再度ブランチ切って自分のコミットを・・・」の自分のコミットを
少なくできるから楽になる
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況